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



I see the cause that Dan referenced in Servo.cpp. Angles are clipped to the range 0-180.

The suggestion to include the 1.5 multiplier in the Child Servo looks like the easiest solution. It could also be accomplished with more effort in EX_Servo.cpp or Servo.cpp. None of these solutions would be usable for general distribution.

@ogiewon, how do you paste code snippets with the format in your last post?


Paste the code into the editor window, then highlight/select all of it, and then click the "Preformatted Text" menu item, that looks like "</>".


The change suggested to the Child servo routine works on my test servo is does report the correct angle.



In the garage doors example, is the PIN_DOORCONTROL_CONTACT_# to be connected to a physical momentary switch to activate the garage door relay or a contact sensor to indicate whether a door is open or closed?


The door control needs two pins. One for a contact sensor (input) and one for a relay (output).

The contact sensor is used to know if the door is open or closed.

The relay is used to momentarily “press the garage door button” to open or close the door.

Here is an example of pin definitions from one of the MEGA examples.

//Garage Door Pins 
#define PIN_DOORCONTROL_CONTACT_1 35  //SmartThings Capability "Door Control" 
#define PIN_DOORCONTROL_RELAY_1   36  //SmartThings Capability "Door Control"


That's what I suspected, just wanted to be sure.



Works great Thanks Dan!


@ogiewon Have you ever looked at the accuracy of any of the temperature sensor implementations on Hubduino/ST_Anything? Are any if them consistently within 1 degree F of actual?


There are a lot of Temperature sensors supported. I have never tried to compare their accuracy. The Dallas Semiconductor DS18B20 sensors are usually highly regarded. I do not see much variability from sensor to sensor. The DHT11's arent all that great. The DHT22's are better, but I have had a couple fail through the years. There are a bunch of I2C sensors that I added not too long ago. I just don't know how accurate they are. You can adjust the offset for each child device to help make them all read the same.


I think I see what you are saying to try. Where is the conversion done? Is it inherent in the hub firmware?


Which conversion would that be? Changing the units of Pressure? That would need to be done in the Child Pressure driver's parse() routine, in the same manner that my Child Temperature driver handles F to C, and C to F conversions.


That's what I want to do. Change from hpa the inhg. I see those entries in the temp conversions in the dh. I am confused as to where the math is done.


Give this Child Pressure Measurement driver version a try and let me know if it works. If it does, I will update my GitHub repo.

 *  Child Pressure Measurement
 *  https://raw.githubusercontent.com/DanielOgorchock/ST_Anything/master/HubDuino/Drivers/child-pressure-measurement.groovy
 *  Copyright 2018 Daniel Ogorchock
 *  Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
 *  in compliance with the License. You may obtain a copy of the License at:
 *      http://www.apache.org/licenses/LICENSE-2.0
 *  Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
 *  on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
 *  for the specific language governing permissions and limitations under the License.
 *  Change History:
 *    Date        Who            What
 *    ----        ---            ----
 *    2018-07-01  Dan Ogorchock  Original Creation
 *    2018-09-22  Dan Ogorchock  Added preference for debug logging
 *    2018-11-10  Dan Ogorchock  Corrected Pressure Measurement attribute name
 *    2019-03-10  Dan Ogorchock  Added user preference for unit conversion
metadata {
	definition (name: "Child Pressure Measurement", namespace: "ogiewon", author: "Daniel Ogorchock") {
		capability "PressureMeasurement"
		capability "Sensor"

		attribute "lastUpdated", "String"

    preferences {
        input "tempUnitConversion", "enum", title: "Pressure Unit Conversion - select hPa to mmHg, hPa to inHg, or no conversion", description: "", defaultValue: "1", required: true, multiple: false, options:[["1":"none"], ["2":"hPa to mm Hg"], ["3":"hPa to in Hg"]], displayDuringSetup: false
        input name: "logEnable", type: "bool", title: "Enable debug logging", defaultValue: true

	tiles(scale: 2) {
		multiAttributeTile(name: "pressureMeasurement", type: "generic", width: 6, height: 4, canChangeIcon: true) {
			tileAttribute("device.pressureMeasurement", key: "PRIMARY_CONTROL") {
				attributeState("pressureMeasurement", label: '${currentValue} ${unit}', unit: "hPa", defaultState: true)
 			tileAttribute("device.lastUpdated", key: "SECONDARY_CONTROL") {
    				attributeState("default", label:'    Last updated ${currentValue}',icon: "st.Health & Wellness.health9")

def logsOff(){
    log.warn "debug logging disabled..."

def parse(String description) {
    if (logEnable) log.debug "parse(${description}) called"
	def parts = description.split(" ")
    def name  = parts.length>0?parts[0].trim():null
    def value = parts.length>1?parts[1].trim():null
    def dispUnit = "hPa"
    if (name && value) {
        float tmpValue = Float.parseFloat(value)
        if (tempUnitConversion == "2") {
            //if (logEnable) log.debug "tempUnitConversion = ${tempUnitConversion}"
            tmpValue = tmpValue * 0.75006  //convert from hPa to mm Hg
            dispUnit = "mmHg"

        if (tempUnitConversion == "3") {
            //if (logEnable) log.debug "tempUnitConversion = ${tempUnitConversion}"
            tmpValue = tmpValue * 0.02953  //convert from hPa to in Hg
            dispUnit = "inHg"

        // Update device
        tmpValue = tmpValue.round(2)
        sendEvent(name: "pressure", value: tmpValue, unit: dispUnit)
        // Update lastUpdated date and time
        def nowDay = new Date().format("MMM dd", location.timeZone)
        def nowTime = new Date().format("h:mm a", location.timeZone)
        sendEvent(name: "lastUpdated", value: nowDay + " at " + nowTime, displayed: false)
    else {
    	log.error "Missing either name or value.  Cannot parse!"

def installed() {

def updated() {
    if (logEnable) runIn(1800,logsOff)


Looks like it works. Thanks !


I think I have this right. I have a mega2560 with a 5100 ethernet board. In the sketch it says that pins 11, 12, 13 are used with the UNO and the 5100. So they are fair game right?

I want to separate some of the DS18B20 sensors I have.

static st::PS_DS18B20_Temperature sensor1(F("temperature"), 20, 5, PIN_TEMPERATURE_1, false, 6, 6    );//The 6 is the number of sensors 
attached Increase for more.
static st::PS_DS18B20_Temperature sensor7(F("temperature"), 11, 5, 
PIN_TEMPERATURE_2, false, 6, 6    );//The 6 is the number of sensors 
 attached Increase for more.
static st::PS_DS18B20_Temperature sensor8(F("temperature"), 12, 5, 
PIN_TEMPERATURE_3, false, 6, 6    );//The 6 is the number of sensors 
attached Increase for more.



I just checked the code and currently, the PS_DS18B20_Temperature class does NOT support what you're attempting to do. Each group of 6 DS18B20 sensors will send "temperature1" through "temperature6" data. Instead of 1 through 6, 7 through 12, and 13 through 18.

I'll have to modify the code to allow you to specific a starting number. It might take me a day or two to squeeze this change in.


I was wondering about how they would be presented Whether it sould send temp1-temp6, temp7 .... or something else. so using the pins is OK then? I was thinking about using 10 -12 instead of 20, 11, 12 just to keep things in order.

I have some rewiring to do before I am ready to hook it all up, so no worries on the update.

Thanks alot!


Should be fine to use 11, 12, and 13 on a MEGA with a W5100 shield.

//"RESERVED" pins for W5100 Ethernet Shield - best to avoid
#define PIN_4_RESERVED 4 //reserved by W5100 Shield on both UNO and MEGA
#define PIN_1O_RESERVED 10 //reserved by W5100 Shield on both UNO and MEGA
#define PIN_11_RESERVED 11 //reserved by W5100 Shield on UNO
#define PIN_12_RESERVED 12 //reserved by W5100 Shield on UNO
#define PIN_13_RESERVED 13 //reserved by W5100 Shield on UNO
#define PIN_50_RESERVED 50 //reserved by W5100 Shield on MEGA
#define PIN_51_RESERVED 51 //reserved by W5100 Shield on MEGA
#define PIN_52_RESERVED 52 //reserved by W5100 Shield on MEGA
#define PIN_53_RESERVED 53 //reserved by W5100 Shield on MEGA


Thanks for the affirmation. I know how sometimes things can get . I don't know how you keep it all straight. Better you than me LOL


I have updated the PS_DS18B20_Temperature.h and .cpp files in my GitHub repository to support multiple groups of DS18B20 temperature sensors on multiple GPIO pins.

Pay attention to the new parameter at the end of the following list.

//			  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

Here is an example using three pins, each sampling 6 DS18B20 sensors, every 60 seconds with a 5 second polling gap between each group, using 10 bit accuracy. This should produce 18 temperature sensors, named "temperature1" through "temperature18".

Let me know if you have any questions. The code compiles fine and runs, however I do not have a bunch of DS18B20's to use for testing. Please let me know how it goes.

static st::PS_DS18B20_Temperature sensor1(F("temperature"), 60, 0, PIN_TEMPERATURE_1, false, 10, 6, 1);
static st::PS_DS18B20_Temperature sensor2(F("temperature"), 60, 5, PIN_TEMPERATURE_2, false, 10, 6, 7);
static st::PS_DS18B20_Temperature sensor3(F("temperature"), 60, 10, PIN_TEMPERATURE_3, false, 10, 6, 13);