[Release] HubDuino v1.1.9 - Hubitat to Arduino / ESP8266 / ESP32 / ThingShield Integration (ST_Anything)

That's because I'm an idiot and didn't write what I meant. :smile:

The ALARM driver needs to update the switch parameters, or you can't use it on Hubitat dashboards - there is no alarm/siren device dashboard template, so switch is really the next closest.

But I understand your point above as well. I did modify my copy of the ALARM driver to populate the switch values when the Hubitat digital buttons are pressed.

I will tinker some more, as maybe you are right and it should really be done on the parse. Basically instead of just passing the received event value on, it needs to check the value of the event (siren, strobe, both=on, everything else=off) and then populate the switch variables in addition to passing the event - an easy change.

1 Like

That's a very good point. I wonder why that is missing from the templates? Probably due to lack of demand thus far. Tagging @bravenel and @chuck.schwer to see if they have any comment/feedback on whether or not a new Dashboard Template for the Alarm Capability should be added. Seems like a good idea to me.

2 Likes

Me too. Otherwise to shut off your alarm siren you either need to only activate it through HSM (and then use the hsm dashboard tiles), or make a virtual switch and and RM rule (or maybe the mirror app) to expose it on the dashboard as a switch.

What else are you using your siren for?

Mainly HSM. :smile:

But I also like to use the switch functionality to test the alarm periodically. That's actually how I ran across this limitation.

The other issue is that once you acknowledge/clear HSM you can't see what triggered it without digging through logs. So sometimes it is handy to silence the alarm, but not ack HSM, while you figure out what happened.

If you are notifying through HSM, you shouldn't have to investigate at all. You can know exactly what caused the alert using %device% and %value% in the HSM notifications.

I'm not pulling out my phone and looking at notifications when my alarm goes off at 1am though.

I'm jumping out of bed, visually looking around to see if there is an intruder/water leak/smoke, and then trying to silence the blaring siren ASAP. lol

I see your point, though.

After looking at the debug messages for the child alarm, I did go back and make it set the switch states via the parse messages. In my case all I get is "alarm" or "off", so it was pretty easy...

In the parse section:

    // Update switch states
    if (value == "off") {
        sendEvent(name: "switch", value: "off")
    } else {
        sendEvent(name: "switch", value: "on")
    }
1 Like

I am at about the 500 message mark and before I get back to reading, I would like to ask a question or two.
I have resurrected a couple of esp32 and esp8266 boards that had some temperature measurement sensors that I used with HomeAssistant. What I was used to was assigning pins for data, clock etc. With some DS18B20, I am just not clear on what I need to edit in the sketches. I do have the IP address stuff and it complies and joins with HE. I did not add all the drivers to HE but it looked like I should.

To use a DS18B20 temperature sensor, you would make sure you have a device created in the sketch as follows:

 static st::PS_DS18B20_Temperature sensor2(F("temperature1"), 15, 0, PIN_TEMPERATURE_1, false, 10, 1); 

This is directly from the ST_Anything_Multiples_ESP8266WiFi.ino example sketch, which is where you should start for an ESP8266 based board.

At the top of the corresponding .cpp and .h files for each device, you will find the documentation for that device. For example:

//******************************************************************************************
//  File: PS_DS18B20_Temperature.cpp
//  Author: Dan G Ogorchock
//
//  Summary:  PS_DS18B20_Temperature is a class which implements both the SmartThings "Temperature Measurement" capability.
//			  It inherits from the st::PollingSensor class.  The current version uses a digital pin to measure the 
//			  temperature from a Dallas Semiconductor One Wire DS18B20 series sensor. 
//
//			  Create an instance of this class in your sketch's global variable section
//			  For Example:  st::PS_DS18B20_Temperature sensor1(F("temperature1"), 120, 0, PIN_TEMPERATURE, false); (for a single sensor)
//                          st::PS_DS18B20_Temperature sensor1(F("temperature"), 120, 0, PIN_TEMPERATURE, false, 10, 3); (for 3 sensors)
//
//			  st::PS_DS18B20_Temperature() constructor requires the following arguments
//				- String &name - REQUIRED - the name of the object - either "temperature1" for a single sensor, or "temperature" for multiple sensors
//				- long interval - REQUIRED - the polling interval in seconds
//				- long offset - REQUIRED - the polling interval offset in seconds - used to prevent all polling sensors from executing at the same time
//				- byte pin - REQUIRED - the Arduino Pin to be used for the One-Wire DS18B20 sensor conenction
//				- bool In_C - OPTIONAL - true = Report Celsius, false = Report Farenheit (Farentheit is the default)
//				- byte resolution - OPTIONAL - DS18B20 sensor resolution in bits.  9, 10, 11, or 12.  Defaults to 10 for decent accuracy and performance
//				- byte num_sensors - OPTIONAL - number of OneWire DS18B20 sensors attached to OneWire bus - Defaults to 1
//				- byte sensorStartingNum - OPTIONAL - Starting number for sending temperature sensor data when using multiple sensors on one pin - Defaults to 1
//

Hopefully this will help clear things up a bit.

Basically, start with one of the example sketches. Then add/remove devices within the sketch's setup() routine as you see fit for your application. You can look through some of the other ST_Anything_Multiuples... sketches for examples of how other devices are used. The ST_Anything_Multiples_EthernetW5500.ino has a tone of example devices, due to the Arduino MEGA's high GPIO count.

1 Like

My first post here. I recently purchased a Hubitat Elevate and have some history programming with the Arduino. At first I was not looking forward to some custom control and monitoring work I had planned but stumbled on the HubDuino. Amazing code that lives up to it's promises. To the developers I thank you and admire your craft here. I've never hooked an arduino to a network before and had some trouble with a 5100 module not getting an IP address (stayed 0.0.0.0) I think it had a weak ICMP connector. Read in the logs that the author Dan (ogiewon) had good results with the MEGA 2560 and the W5500 combo. I like the 2560 board and have a couple on the bench and ordered the w5500, Got it all up and running and it is fantastic. I am just on a breadboard with the standard config of 2 of each devices and testing the ones I want to use.

Now my questions and search for advice from fellow users and developers of the HubDuino:

  1. I'm new to the whole setup and want to leverage local control as I will be controlling a generator and often without the internet available. What rule machine do you recommend to tie together my various arduino functions and power controls. I will be monitoring AC and DC voltages and making presence and Time of day decisions along with voltages to start and stop my generator.
  2. I have no home automation hardware and want to get some light switch controls, AC outlet controls, and motion detectors. What will work well for me? I'm looking for brand and models that you have had success with.
  3. Are there any gotchas or sage words as I add additional Ethernet and/or WiFi arduinos to the mix? Can that be just as easy as the parent/child that I have experienced so far? If so I'm amazed.

What kind of generator? Reason I ask is it might make it easier if you use tooling already built (like Genmon GitHub - jgyates/genmon: Generac Generator Monitoring using a Raspberry Pi and WiFi) vs starting from scratch

I really like my Lutron Caseta smart switches, dimmers, fan controllers, and Pico remotes. To use Lutron Caseta, you also need the Caseta Smart Bridge Pro2. It communicates with the Lutron devices via Lutron's Clear Connect RF protocol, and with Hubitat via Telnet over the LAN. It is extremely reliable and performs great.

As for outlets and other sensors, I really like the Iris v2 Zigbee devices which can be purchased via ebay.

Motion Sensors. Be aware that battery powered Zigbee devices need a strong Zigbee mesh network, Be sure to add some AC-Powered Zigbee repeater devices like the outlets below.

Outlets (These make very good Zigbee repeaters. As a bonus, they are also Z-Wave Plus repeaters.)

Adding multiple HubDuino-based micro-controllers is very simple. Just be aware that you should not expect super-fast update rates from the Arduino to the Hubitat Hub. I usually recommend update rates no quicker than every 30 seconds. After all, temperatures, humidity levels, etc... dont really change all that quickly in your home. Digital inputs for things like Contact Sensors update immediately, but they typically do not change state all that often.

Brian,
Thanks for the link I will study it. I'm running a Champion 8.5 HSB. I live remote and have experience with Champion generators for the last 15 years and really like them. I wanted a smaller HSB gen to conserve on propane. I don't need air conditioners at my elevation. Here in NorCal there are now frequent summer and winter outages and propane delivery can get sketchy on long runs. The Champion 8.5 has about the lowest per day fuel consumption without the air conditioning loads that I could find. I'm really happy with the generator and my goal is to have a couple use cases:

  1. Home - I choose to shut if off at night and turn it on in the morning to conserve fuel and lower the noise. Loving the idea of doing this from my phone using HubDuino.
  2. Away - I would like it to run for 2 hours twice per day to keep batteries charged and freezers cold.
    Additional is monitoring of the starting battery voltage, temperatures, voltage on the utility and generator and current on the supply side of the transfer switch.

Ogiewon,
Thank you for this advice. Once again I have to thank you for some great thinking recorded in your software. I will shop for some of these devices. I have less than 2 hours of testing on this and am seeing 3 to 6 seconds delay on my laptop screen when I press the contact switch on my prototype board. This seems very acceptable. I'm getting faster response from the laptop and phone dashboards when I turn on or off a switch or relay on the MEGA, perhaps 1 second nominal. Also acceptable and fantastic. Really anything less than 1 minute for my use is fine. The serial monitor outputs are very helpful for developing my thoughts around this use.

Ogiewon,
Question as I move from the prototype board to my install. I ran and set up the 2 each sensors for experimenting and will not use many of them. When I remove sensors and add other sensors (e.g. eliminate water sensors and add more voltage sensors) does this code clean up the children in the HE or do I need to do something to sync the Arduino code with the HE? I could experiment but thought I might just cheat a bit with some advice

1 Like

You have two choices.

  1. You can simply delete the parent device, which will remove all of its child devices. Then re-add the parent device to Hubitat. The children defined in the sketch will be automatically created.

  2. You can modify the sketch to suit your needs. Then manually delete every child device (not the drivers!) that is no longer needed of the particular parent device, leaving behind the child devices that are defined in the sketch.

Either way works. #1 is often the faster and cleaner route, assuming you haven't included the child devices in a bunch of automations already.

Thank you. I think 1 is where I will head. I'm in development all around so no issues starting over. Your code is so nice.

1 Like

Question for you... Are you seeing the timings mentioned above (i.e. 3-6 secs) using the Hubitat Dashboard web page?

Within the Hubitat Elevation Hub's admin page, when viewing one of the child devices, you should see the status of a contact sensor update in less than a second.

Using the Dashboard, you will perceive a slightly longer delay due to the nature of how frequently the Dashboard app updates web clients.

Yes my observed times on response are all from the Hubitat web page dashboards as that will likely be my production use case. I want to monitor and control my standby generator from my phone.

I'm finding the builtin rule and notification apps to be a bit hard to unravel and tame. Is it worth toughing the learning curve out or have you all found better rule and notification tools for this platform of Hubduino and HE?