I moved my garage door hubduino to a different hub, and did this by uploading a changed sketch from the IDE via WiFi to the eap8266. I doubted that it would work, but did well!
I have noticed lately that with the garage door function and HomeKit, when I slide the “switch” in HomeKit to open the garage door, the switch stays up on the screen and I have to manually swipe down, and then up again to get the door to close. It may be a iOS change with 13, as it didn’t do this with iOS12 HomeKit. I believe that I also updated the hubduino code to the latest, but memory is foggy in that one. I seem to have so much tech that I am chasing these days, I am forgetting where I was on one project to the next!
Looking to control 2 or 3 relays/leds from the same child device using st_anything_relays_buttons.
I tried to follow the code changes you did for the timed_relay_pair but have been unsuccessful in determining the changes need to the ex_switch libraries.
I am not following what your goal is. Can you please elaborate? Trying to control three relays from one child device is definitely non-standard... What is the use-case?
That doesn’t really fit within the current design of HubDuino/ST_Anything. You could definitely write something custom. One way would be to use the sketch’s callback() function to “sniff” the data each time the relay is turned on or off. Then write whatever custom logic you’d like to control another GPIO pin however you’d like. No need to expose that extra pin to Hubitat at all, if it is just to indicate a status.
That one was a little different. But you could use that one as a starting point if you want. You’d just need to rework the logic. However, there is no simple way for the logic to be changed by the child device. It is possible, but not trivial. If you’re a programmer you should be able to make it happen.
Thoughts on using a Hubduino relay to control a heat-n-glo fireplace? If I connect these two low/no voltage wires, it fires up - they connect through to a wall switch (with no mains). Benefit of Hubduino is I can build in a timer into the code so it can’t be on more than 30 mins at a time for safety concerns. Was going to run it in series so the wall switch will end up being a master “off”. I did see on ST forum that folks did this with a dry contact device - isn’t a relay accomplishing the same thing? Switch operated fireplace -- Best option and price for a dry contact relay whether z-wave or zigbee - Connected Things - SmartThings Community
For the wemos, solder the pins to the board, they stack together, add an old micro usb phone charger, connect your heater control wires to the relay terminals.
Yes, a traditional mechanical relay is typically just a pair of dry contacts. I like your ideas regarding safety. Leaving the original switch in is a great idea for a manual disconnect. I also like the idea of using the Timed Relay device which allows you to specify the 'on time'.
HubDuino should be able to handle this fairly easily. The Wemos D1 Mini hardware recommended by @kuzenkohome would make a nice small package.
Thanks! I have a LinkNode r4 sitting around, so I'll just use it. Is there another ready-made option? Looks like the Wemos D1 Mini needs some soldering and a relay.
Don’t those boards need to be flashed with Tasmota firmware to be controllable via HE? I ended up with about 60 browser tabs open researching what to get! Ended up going for a wemos d1 mini and a relay shield because there’s no tricky tasmota rabbit hole to fall down
Use Hubduino, it works great, and the developer Dan ogiewon is very helpful and responsive.
If the micro-controller is supported by the Arduino IDE, you can flash Hubduino on it. Most of these Chinese boards are based on the ESP8266 chip. I have Huduino running on wifi outlets, wifi inwall switches, sonoffs, nodemcu and wemos type boards.
Tasmota is a great general purpose, "one size fits all" product, but it is also very generic, and doesn't have as tight of an integration with Hubitat yet, as compared to Hubduino. But other developers on this forum are working to more tightly integrate Tasmota.
Hubduino on the other hand is purpose built for integration with Hubitat.
Did some more wifi maintenance this morning. Rebooted APs and changed around some wifi channels, etc. Sure enough, the ESP8266 dropped off the wifi and required a power cycle before it would rejoin the wifi network.
I'm going to have to figure out some way to make it more resilient to network changes. Running out there and pulling the power plug will get old fast. (Note to self: Maybe I should have put a power switch/reset button on the job box. )
Granted, I rarely ever change wifi channels, so if that is what killed it - that shouldn't be an issue in the future. But if it was just rebooting the wifi access point that killed it, that is a problem.
Maybe it needs some code such that if wifi status <> connected for X minutes, do a hardware reset...
One more thing... On the switch driver, you need to populate the "switch" state variable if you want them to work in Hubitat dashboards. I updated mine, but since it is on my alarm siren I haven't had a chance to test it. The dashboard tile looks right, though, and I'll test it tomorrow.
The "switch" attribute is correctly updated via the parse() routine. I do not update the attribute in the on() and off() commands as their purpose is to send the command to the micrcontroller. Only when the microcontroller sends back a response should the attribute update. I prefer to not assume the command got to the microcontroller.
What is the use-case?
)
