MQTT state tracking and Lightswitch controller

Hi Folks

I’m trying to find some like minded people to get some ideas from, always best to mingle with those smarter I reckon.

I’ve been using a commercial product for 15 years, Homeseer which is out of the US. With it I’m using a bunch of arduinos, sms controller and amazon. I’ve been using MQTT for a while for “ancillary items” as they’ve been wifi, I’m not a huge fan of WIFI automation, it needs to be on blue cable.

Two quesitons.

  1. Jon’s arduino mega light switch controller. I flashed a mega here and tweaked the topics and it seems to work kinda ok, there was comment about button bounce previously and I think I’ve got some crappy cheap buttons that gave me bounce. I tweaked the debounce out to 100ms and then I found I’d intermittently have the arduino disconnect from the MQTT server. Has anyone built this device and have you had any issues with button bounce. I really do like this project, I think I’ll stick with it and do some more tweaking of the topics and payload format to suit my MQTT client on Homeseer.

  2. Arduino outputs. Is anyone driving relays using arduinos ? Not wifi units, Mega or UNOs ? WHat I’m interested in how are you tracking state changes ? Meaning if the mega/uno comes on line and the automation package has the relay on, does your automation system sync the device buy updating all of the topics for the device ?

I was thinking of modifying the lightcontroller to include switches as Jon mentioned but the only thing I cant work out is how I’d sync the switch status unless I modified the code for it to send all of the input topics to the Automation controller on boot…

My current Arduino plugin for Homeseer does all of the status tracking if you power cycle the arduino, just curious how other packages or peoples code might do this…

I’m leaning towards moving my I/O to MQTT as its open and I can modify code as I go but I’m just stumbling regarding tracking change of states on power cycling remote devices.

Pete

Hi Pete,

You can look into Schmitt triggers - and perform debouncing in hardware if you think that blocking code could cause other issues like dropping server connections. You can also use R-C circuits to get hardware debounce.

I do have a system that drives relays from a RaspberryPi but not Arduino. The Pi knows the state of the relay at all times. Any internal request gets published to MQTT and external requests from the automation system come in through MQTT . I don’t explicitly handle power cycle/ reconnect updates - they just get synced up the next time a transition occurs. I have about four different arduinos and a couple of Pi’s in my system and the effects of not syncing states on connection have really been negligible.

Hi James

I have been preferring the controller (head) end to know status rather than the distant I/O devices on reboot hence the retain flag on MQTT. Once the device power cycles and subscribes the latest status is sent back to it.

Appreciate your comments, there are many ways to do this :slight_smile:
Kind Regards…Peter