LSC Action device support/use status ?

[martinus]

Now that the new IR Gateway is in operation, it is time to start working on my LSC Action gadgets:

I just put R151 on the Smart Plug because it's just a bare switch, brings back memories:

R151.png (32.23 KiB) Viewed 12943 times

I also pulled some ESPNOW plugin from here
viewtopic.php?f=6&t=7179
and adapted it for ESP32 receiver. So Wifi and receiving ESPNOW can work simultaneously and you don't need a special serial gateway anymore. Could be a suitable candidate for the doorsensor

The PIR sensor seems useless to me. It only sends an active signal and when motion stops, nothing happens.

And now my main question:
Is anyone actively working on these devices? Would it make sense to spend plugin development time on these?

[martinus]

The first doorsensor is working towards an ESP32 peer node:

LCSEasy.png (27.1 KiB) Viewed 12870 times

Needed some tweaks to be able to set/scan/update the working channel of a peer node, but it seems to work now when channels change. Needed to store the active channel in flash because the ESP on the doorsensor is turned of after use. On peer connect failure, it will scan the wifi, find the new channel and store it. On the next boot it will use the stored channel.

Had to use a sofAP call to set the active channel for ESPNOW. There must be an easier way but i haven't found it yet. The sofAP is not used, but the call was required to change and set the channel on persistent config.

On the ESP32 i had to do another tweak. The softAP must be running persistently and i did not find a 'supported' way to do this with an existing ESPEasy setting.
Also here, the softAP interface must be active because the peer node sends to the softAP mac address. The softAP is not used for connecting and the SSID can be hidden with an unknown key if needed.

Learned a lot of new things last few days on ESPNOW in combination with ESP32.
All is working now but i would like to see things done in an easier way.
Seems all demos use the softAP interface and this seems the only way to have concurrent use of ESPNOW and Wifi (on ESP32).
Not a big deal, but things could have been easier IMHO.

[ManS-H]

Martinus,

Maybe a stupid question. I see you used R151, but what is the difference between the R145/147 builds and the R151 build?

[martinus]

Martinus,

Maybe a stupid question. I see you used R151, but what is the difference between the R145/147 builds and the R151 build?

From __ReleaseNotes.ino:

Code: Select all

// R150 03-09-2017 
// RAM savings: .arg("F(xxx) in plugins and lots of other places F()
// Added rules processing time logging

// R149 22-04-2017
// Changed root web page to same format as Mega

// R148 02-12-2016
// Fixed a bug in ADS1115 plugin (contributed by Shardan)
// Fixed a bug on R146 Ser2Net

// R147 27-11-2016
// Fixed a situation where a large message delay uses background processing without UPD handling, causing network issues.

// R146 20-11-2016
// Fixed a bug in PLUGIN_SERIAL/UDP calls where eventstruct data was not prepared
//   Ser2Net plugin RXWait would only work as expected on task 1

// R145 13-11-2016
// Removed controller specific code from the framework (Domoticz test routines)
// Fixed device table display

R151: I just removed some stuff to get it compiled without waisting to much time figuring out the differences. It runs with C001/P001 plugin.

[martinus]

The PIR sensor also converted to ESPEasy. It takes 497 milliseconds from Power On state to send out the final state message.
As received on ESP32:

Code: Select all

1477432 : Info  : EVENT: Clock#Time=Sun,12:11
1478984 : Info  : WD   : Uptime 25 ConnectFailures 0 FreeMem 196904 WiFiStatus 3
1490884 : Info  : EVENT: ESPNOW=PIR2Boot
1490899 : Info  : ACT  : sendtoudp 192.168.0.255,65501,PIR2Boot
1490901 : Info  : Command: sendtoudp
1490906 : Info  : ACT  : log PIR2Boot
1490908 : Info  : Command: log
1491084 : Info  : EVENT: ESPNOW=PIR2/497=0
1491099 : Info  : ACT  : sendtoudp 192.168.0.255,65501,PIR2/497=0
1491102 : Info  : Command: sendtoudp
1491107 : Info  : ACT  : log PIR2/497=0
1491109 : Info  : Command: log

But no MOTION OFF message or something similar. So you would have to set a timer inside ESPEasy to turn off the light...

[martinus]

Martinus,

Maybe a stupid question. I see you used R151, but what is the difference between the R145/147 builds and the R151 build?

Getting back on topic:
Is anyone actively working on these devices? Would it make sense to spend plugin development time on these?
Are you using any LSC stuff?

Personally i could live with some prototype level plugins without too much worries. So then development would be finished already at this stage.
For generic use it would require more work on both ESPEasy core and the plugins and they would have to be added to the official repo.
Also the current ESPNOW plugin may have to be converted to a controller plugin ?

But catching up on some other threads about LSC has not convinced me yet to spend more time.
I know that Gijs does not even own any of these devices so that doesn't help... (No Action store in Groningen???)

[happytm]

Martinus,

I have cobble together some code for my battery powered ESP8266 devices. There are 2 sketches called ProbeSender.ino and ProbeReceiver.ino. It is very power efficient (even better then ESPNow) and it uses Probe Request protocol to transfer data from battery power device to main controller which is mains powered.The receiver ( Main controller) receive sensor data via probe request from all battery powered devices on the local network just like ESPNow protocol and publish these sensor data using built in uMQTT broker.I use MQTT Dash android app at https://play.google.com/store/apps/deta ... h&hl=en_US to display all these data from whole network on my phone. MQTT Dash app also can send commands to main controller which is then sent to specific battery powered device via probe request. I am not a programmer but if you have some time can you please look into it and if possible implement it as a controller plugin in ESPEasy ? My code is at:

https://github.com/happytm/BatteryNode.

In test folder of my repo I have working examples for ESPCoreRules by user FanOfHue who has unfortunately left the forum.One example is for receiver (Main Gateway) and one for Sender (Battery powered ESP8266 device).

Thank you.

[jjansen]

Martinus, did you see this topic?
https://www.letscontrolit.com/forum/vie ... f=5&t=6955

[martinus]

Martinus, did you see this topic?
https://www.letscontrolit.com/forum/vie ... f=5&t=6955

Saw that one. But it looks like many posts are 'hijacked' by Tasmota users. I'd like to see if there's a need for ESPEasy. And if standard operation is sufficient or ESPNOW is really required. It has been working stable last few days, running on ESP32 receiver and ESPNOW, so the POC seems successful.

But is guess it's a very niche market, mostly taken by Tasmota already.

[martinus]

Martinus,

I have cobble together some code for my battery powered ESP8266 devices. There are 2 sketches called ProbeSender.ino and ProbeReceiver.ino. It is very power efficient (even better then ESPNow) and it uses Probe Request protocol to transfer data from battery power device to main controller which is mains powered.The receiver ( Main controller) receive sensor data via probe request from all battery powered devices on the local network just like ESPNow protocol and publish these sensor data using built in uMQTT broker.I use MQTT Dash android app at https://play.google.com/store/apps/deta ... h&hl=en_US to display all these data from whole network on my phone. MQTT Dash app also can send commands to main controller which is then sent to specific battery powered device via probe request. I am not a programmer but if you have some time can you please look into it and if possible implement it as a controller plugin in ESPEasy ? My code is at:

https://github.com/happytm/BatteryNode.

In test folder of my repo I have working examples for ESPCoreRules by user FanOfHue who has unfortunately left the forum.One example is for receiver (Main Gateway) and one for Sender (Battery powered ESP8266 device).

Thank you.

Just had a quick look at the code. This line worries me a bit:

Code: Select all

 wifi_set_macaddr(STATION_IF, sensorType);

Looks like your hacking the MAC address to send actual data. So it keeps changing? Wonder if Access Points like this that much. But it seems you have it working on a large scale though. I'll stick with ESPNOW for now, because the work has already been done and do not want to spend more time on ESP8266 stuff anymore. Currently working on the ESP32 based WordClock.

You would better raise a new thread for your solution and see if it gets any response. Then convince the ESPEasy devs...

[TD-er]

I wonder how well ESPnow performs if the "ESPnow gateway" node is connected to an AP with dynamic WiFi channel.
Problem is that ESPnow receiver should listen constantly on the same channel, but given there is only a single radio it is forced to use the same channel as used by the AP you connect to.

ESPnow is more like a "fire and forget", so it must be using the same MAC and channel to be this fast (less than 100 msec).
If it needs to search for the channel to use, it will be taking a lot longer.

[martinus]

I wonder how well ESPnow performs if the "ESPnow gateway" node is connected to an AP with dynamic WiFi channel.
Problem is that ESPnow receiver should listen constantly on the same channel, but given there is only a single radio it is forced to use the same channel as used by the AP you connect to.

ESPnow is more like a "fire and forget", so it must be using the same MAC and channel to be this fast (less than 100 msec).
If it needs to search for the channel to use, it will be taking a lot longer.

I solved this by checking the ESPNOW send result. If it fails the unit will automatically scan if the AP has changed channels. If it finds the AP on a different channel, this will be stored to flash for the next attempt. For the LSC devices this is the only way to store this as the ESP module is powered off after use. So can't use RTC mem. This approach will only take more time when a new channel needs to be set. The channel change count is also stored to flash so i can check if things are not getting out of hand. If your AP changes continiously, this approach is not recommended as it will wear out the flash. If it changes like once a day, it should last for years...

[TD-er]

As almost all access points only use channel 1, 6 or 11, you may also try those first before performing a scan.
It is probably a lot faster and still fast enough I guess.