Closed joe-ave closed 2 years ago
Thanks for the request. That is a really good point!
It seems that e.g. Shelly Plug can handle 16A, which is enough for smaller scale heaters and possibly chargers. Maybe first to test with could be Shelly generation 1 devices, covering Shelly Plug/Shelly Plug S . The same API specs are also used in Shelly 3EM relay, which is supported already by Arska .
Calling a HTTP get for relay switching is basically simple but we must plan also how to keep the UI and system simple and flexible - to add possibly additional relay types. The first 3 digits (e.g. 192.168.0) of the relay IP address could be taken from wifi address/subnet and only the last digit would be defined in channel definitions - so you would set channel type (e.g. Shelly Gen 1) and IP address (e.g. 77).
We will keep the list of supported switch types short, to keep the system simple. I ordered Shelly Plug for tests and will look at this in more detail.
Thank you for your effort!
Maybe the channel type should just be defined as ”Smart plug 1, 2...” and then the actual string to send for turning on and off should have an inputfield in the setup page?, then it would be more generic and could probably work with other brands and software like Tasmota for instance. And then you don’t need to create new channel types every time a new HTTP-get equipment pops up.
Thanks for your comment, much ideas appreciated!
That would be flexible (was also in my mind at some point) but on the other side possibly a long url in the settings requires more non-volatile memory. The configuration is stored in EEPROM memory of ESP32, which has 4kb limit (at least in a typical setup ESP32?). We are not yet very close to that limit (even with 8 channels), but that is one reason I'm (over) cautious about adding new strings to settings. It is hard to know how much you have to reserve space for URLs of future devices and space reservation is required for all channels .
If the channel type functionality is now rewritten, it is easier to add additional types later (needs a firmware upgrade though), maybe also Modbus relays and GPIO relays with editable GPIO numbers. But that flexible URL channel type could still be a future option if the memory consumption can be handled.
I think the eeprom of the esp32 is just emulated and actualy stored in the flash, probably because Arduino specific code should work more easily without the need of rewriting it so much. Preferences.h for the esp32 could maybe be a better alternative, looks like it books 20kb of the flash size by default.
Thanks @joe-ave for the info about Preferences.h ! After first look, it seems to be very promising, but replacing current Arduino-based storage functions requires some planning and testing.
I pushed the first version with Shelly Gen 1 support to devel branch (no binaries published yet). Requires still more testing but it seemed to work in the first tests with Shelly 3EM relay, which should have exactly the same (relay) API with Shelly Plug(S). Now there are 4 channel (switch) types defined:
Edit 24.9.8.2022: The new development version firmware is now published on the installation page.
The new devel branch version on the installation page has initial support for Shelly (gen1 & gen2) relays and Tasmota relays.
Great!, I´ll try to poke in Tasmota to a Nedis plugg ( localy avaliable ) this weekend and try it out.
Version 0.92.latest (on the installation page) has initial support for Shelly Gen 1 and Gen 2 relays as well as Tasmota relays. We have tested them with a very limited number of devices, so please (re)open the issue if any problems or issues. See the release notes.
Could it be possible to use http-get commands to control smartplugs directly like Shelly or other that support that type of commands?, as an option instead of the conventional gpio pins? Given that they are connected to the same router as the Arska-Node. https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Switch#switchset-example It could be easier to use for a wider audiance without the need of an electrician.