HubDuino v1.1.1 / ST_Anything v2.9.1 have been released. Major change is the addition of servo motor support.
WARNING: I have noticed a communications issue with Hubitat Elevation Firmware 1.1.0.120 when using the Arduino ThingShield. I am working with the Hubitat Engineering team to resolve the issue, but it may take a few days.
If you are using a ThingShield, please keep your hub at firmware 1.0.9.118 until this issue can be resolved.
@ogiewon Dan would you mind going into more detail on the issue? I didn't see this message until after I upgraded the firmware.
Hi, Dan. Thanks for the alert. FWIW, I also upgraded w/o seeing this. My only Arduino ThingShield on HE is the AD2 integration by @ritchierich and it seems to be in good shape. Tested various commands back and forth and they work, AFAIK.
Probably irrelevant to this problem, @ritchierich, but I did see this error in the live logs:
2018-06-25 11:03:41.876:errorjava.lang.NullPointerException: Cannot invoke method multiply() on null object on line 216 (parse)
Anything to be concerned about?
Yes, that is the exact same error I am seeing. It prevents data from the ThingShield from being processed by Hubitat. Data from Hubitat to the ThingShield is still working.
1 Like
Thanks @CAL.hub and @ogiewon. @Matthew FYI as you are also using a ThingShield, you may want to hold off on upgrading.
FWIW this particular line of code is the parsing the data:
def resultMap = zigbee.parseDescriptionAsMap(description)
@CAL.hub I noticed as a result of this error, the child alarm zones aren't updating since HE can no longer parse the data from the ThingShield. Look at your alarm device event history to verify you are also having the same issue.
Exactly. I have submitted this information, along with some detailed live log information to Chuck Schwer. Chuck is traveling today, so it may be another day or two before this is hopefully resolved. In the meantime, you can revert your Hub's firmware to the older version. Doing so restored everything to a working state again. (This is why I have a second hub just for development! 
)
I bought one too over Fathers Day weekend! I should have tested there first. 
1 Like
Confirming restoring the firmware does indeed solve this issue. @CAL.hub let me know if you need help restoring because as mentioned this issue does affect the alarm integration reporting individual zone faults. Hopefully @chuck.schwer will have a timely solution.
2 Likes
Thank you for the heads-up. I had already updated, but will revert back to 1.0.9 until this is resolved.
2 Likes
Luckily, I downloaded a backup just before upgrading. But, I think I'll stick with the update. My only dependencies on alarm--> Hubitat signals are just some insignificant notifications. As long as Hubitat can control the alarm, I can wait for a fix.
1 Like
@CAL.hub, @Matthew, @ritchierich
The latest 1.1.0.121 firmware has restored proper two-way communications for the ThingShield.
Enjoy!
Thank you @chuck.schwer for the quick fix!
5 Likes
HubDuino v1.1.2 / ST_Anything v2.9.2 have been released. Major change is the addition of I2C sensor support for the following devices:
- AM2320 Temperature and Humidity sensor
- BME280 Temperature, Humidity, and Pressure sensor
- BMP280 Temperature and Pressure sensor
- TCS34725 Color Illuminance sensor
- TSL2561 Illuminance sensor
- BH1750 Illuminance sensor
- MAX44009 Illuminance sensor
I have also added the ST_Anything_I2C_ESP8266WiFi.inoi example sketch to demonstrate these devices.
Note: The BME280 and BMP280 measure Pressure. I have utilized the new PressureMeasurement Capability in Hubitat for these sensors. Make sure you update your Parent Driver and and add the new Child Pressure Measurement driver. (Note: ST does not have a PressureMeasurement capability so two versions of this child driver are needed - one for Hubitat and one for ST. Therefore, I have finally decided to split the Child Device Drivers into two separate folders, one for Hubitat and one for ST. This will help prevent users from both systems from using the wrong drivers.)
I2C Useful Tips:
- Most of the sensors seem to want to use a maximum of 3.3V for Vin . Check your devices before wiring them up to make sure you’re using the correct voltage to avoid damaging them.
- The Arduino UNO and MEGA have hardware based I2C pins which are not user definable. Look up the pin-outs for these boards to determine where to connect your SDA and SCL wires. For these boards, you should not need to make any calls to Wire.begin() in your sketch.
- The ESP8266 does not have hardware I2C pins. You must select the pins you want to use in the SKETCH. Please refer to the ST_Anything_I2C_ESP8266WiFi example sketch to see how this is accomplished in YOUR SKETCH. The pins I have chosen (D3, D4) appear to work very well with my NodeMCU V1.0 board. YMMV.
Let me know if you have any questions or feedback regarding the use of these new sensors.
Dan
Can you please help me? I had the demo example working correctly and the changed the arduino code to my application and it all worked, but after some problems with IP addresses and getting my network setup again I removed and re-created the parent device. I now can't get hubitat to find the child devices, I think the arduino is fine as in the current states part of the parent driver it shows all the children I expect and their states change correctly. They are reported correctly in events also.
I've rebooted my hubitat and updated it's firmware, but I can't get the child devices back. Please suggest something to try. It was great when it all worked!
Thanks
Simon
Are you still using the original version of HubDuino code? Or have you switched to my newer Composite Driver code? If still the old code, I recommend you replace all of the old code with the new code in my GitHub repo for HubDuino.
I am only supporting the new code from now on. The two code bases are not compatible with each other. Delete all of the old driver and the app, and install all of the new drivers from
I had all the device driver code up to date. I've found the problem tonight, I'd changed the names of the devices in the arduino sketch, e.g. from
static st::IS_Motion sensor4(F("motion2"), PIN_MOTION_2, HIGH, false);
to
static st::IS_Motion sensor5(F("pir2"), PIN_MOTION_2, HIGH, false);
I hadn't realised that the names were important to the device drivers, now I've put that back the child devices are created correctly again.
Thanks for your work.
1 Like
Yes, the naming convention is very critical as that is how the Parent knows which Child device to create. The numbering is critical too, as each device must have a unique name+number combination. This is detailed in the ReadMe.
Glad you got things working.
Let me know if you have any questions. Always happy to help out!
Thanks, after posting, I figured out how to add the ESP8266 to ST, I had them with Konnected firmware. I never worked with Arduino app before, now I have other issues, HE is not receiving my ST data. After I get that fixed problaby I will be here asking stupid questions. Be prepared!
