Feature Request: IR, Probe Request and uMQTT Broker

[happytm]

I have been testing your firmware for few weeks. I have tried to include above features over at my fork for this firmware and it has been working reliably. My main goal here is to create very low power standalone sensor network and I am successful transferring data between sender & receiver esp devices within 220 milliseconds. I also used uMQTTbroker for connecting whole network to raspberry pi locally to use node-red for user interface. Please look at my fork and instead of using espcorerules.ino please use espcorerulesreceiver.ino on receiver side and espcorerulessender.ino file on sender side. I have modified code to set wifi mode to STATIONAP in wifi.ino file. Settings at sender code require to match ssid and wifi channel of receiver unit. Settings at receiver side require ssid & password for access point to connect the receiver to your home access point.I had to comment out some code to make it work so please use all files from my repo for testing.

If possible I request you to include these features in your firmware more efficiently and make it usable in rules engine. I am learning arduino programming so code is probably not very efficient.

My fork is at - https://github.com/happytm/ESPCoreRules

Thanks

[FanOfHue]

I'm currently busy working on a "TinyExtender" using ATTiny85, so time is limited. I've just installed your firmware on two ESP unit's and must say that it's fun to see how it works. Could definitely be used to improve the speed of the LSCDoor sensor project (now takes 3-5 seconds to get a message).

Downside is that is has no security at all. I have also looked at ESPNOW a while ago. That may be a better (more secure) approach, although it would need something like a gateway (two ESP modules with serial connection between) to connect the ESPNOW network to a normal Wifi network.

Need more time to study all this new stuff. But looks promising!

I also need to reconsider how to keep the ESPCoreRules lean and mean but also flexible enough. I'm thinking of moving some of the core stuff to special plugins as well. Also needs time.

[happytm]

Thank you.

Take your time.

Please take a look at https://github.com/enesbcs/EasyESPNow also for ESPNow. He is using ESPEasy code as a base.

[happytm]

I forgot to thank you about you efforts to work on ATTINY85 extender. ATTiny85 is my another favorite micro. If it can be also used as a door sensor it will be very useful. Following is a link to ATTiny85 example with IR as communication protocol for your reference:

https://gist.github.com/dquadros/2df488663eb1f59994d6d142f61ed3af

Thanks.

[FanOfHue]

ESP-NOW is now integrated into SmartNodeRules core. Running it for several days now and it seems stable. I decided not to include the "Wifi probe" hack because ESP-NOW seems much better.

ATTiny extender is also stable and doing it's testwork on a doorsensor. The doorsensor wakes the ESP for a minimum of 1.3 seconds. But the ESP will go into deepsleep after 300 mSeconds. Deepsleep will never really trigger because the ESP will be powered off completely after 1 second.

This makes total high current consuming for only 300 mSeconds.

[happytm]

Great and thank you.

[FanOfHue]

Regarding this initial request:

• Suggest to forget probe request and move to ESPNOW
• The IR part should be moved to a plugin, like with ESP Easy project
• How does uMQTT broker differ from PubSubClient that is included in ESP Easy and this project?

[happytm]

Thanks.

PubSubClient is just mqtt client as name suggest whereas uMQTT is mqtt broker also as name suggest.If implemented it serve as mqtt broker usually found on cloud or local machine.Following video explains well how it is useful:

https://www.youtube.com/watch?v=0K9q4IuB_oA&t=3s

Thanks again for ESPNow implementation.

[FanOfHue]

So far, i have only checked your code on the Wifi probe part. After a closer look, i make following observations:

• Your sender can use IR or Wifi probe to send sensor data, right?
• Your receiver can receive data from IR or the Wifi probe request
• The received can use MQTT, but it's only used to publish as client. It also does not use the rules engine for configuration and processing.

The uMQTT broker looks like something that could be used as an alternate message bus for standalone use of SmartNodeRules. I think it can replace the existing pubsubclient. I'm not using MQTT, only did some minor testing and that's why the pubsubclient code is still there. It may not even work because i only checked it once.

Are you dependent on using MQTT on the sensor? You could still use ESPEasy to bridge between SmartNodeRules/ESPNOW devices and use the MQTT within ESPEeasy to connect to Node-Red or other controllers.

Most of my limited time is currently spent on expanding my ESPNOW sensor network. It makes a nice add-on to my Hue system because Hue does not have doorsensors and the Hue PIR sensors are quite expensive (but still much better than anything i have used before). I will remain using Hue motionsensors for critical use and use the LSC PIR/doorsensors for less critical purposes, like the 'meterkast' light. Next will be the 'trapkast' light and the garden shed.