Node-RED nodes for hubitat

[nutcracker]

You'd think raspberrypi.local would work... clearly not. I'm not doing anything fancy network wise... I'll stick to using IP for now - safer!

[leeonestop]

How about just http://ipaddress:1880/hubitat/webhook. it works for me? Mine looks like this?

http://192.168.1.???:1880/hubitat/webhook_

[nutcracker]

Yes using the IP works fine...

[leeonestop]

Glad you got it working.

[tmichael]

Thanks to these nodes I have gone deep into the NR rabbit hole. I just posted on their forum about a dashboard that I have created with devices via Hubitat, Zigbee2MQTT, Hombridge, Harmony NR node. The post is at:

Examples of Smart Home Dashboard

But here is what each tab looks like:

[aaiyar]

@fblackburn

I've run into an issue with the device node not properly updating when a device attribute is changed. The issue could be the Hubitat virtual driver that I wrote (probably) or with the device node, Anyway here's the problem:

I created a device with a virtual temperature & humidity driver. The device node receives updates to both temperature and humidity when the device in Hubitat is changed.

If I change the driver of this device to a new virtual driver that has temperature, humidity, and dewpoint (added as an attribute), then updates to temperature/humidity are seen by the device node just fine. But no updates to the dewpoint attribute are received/shown by the device node.

On the other hand, if I create a brand-new virtual device with the same virtual driver (temp/hum/dewpoint), then updates to all three made on the Hubitat side are received by the device node. Also, if I remove the device from MakerAPI, and then add it back, then updates to all three are received.

Couple questions:

1. Is this expected behavior? Meaning once a device is created with a set of capabilities/attributes, then the device node will ignore any new capabilities/attributes added later via driver change?

2. Have I configured my Node-RED incorrectly? To clarify, when the new driver (temp/hum/dp) is used on the existing virtual device, temperature and humidity updates continue to be received - so there's issue with the MakerAPI config.

I've attached the virtual device driver below, in case the issue is with an incorrect driver:

metadata {
    definition (name: "Virtual Temperature/Humidity/Dewpoint Sensor", namespace: "aaa", author: "Ashok Aiyar") {
        capability "Sensor"
        capability "Relative Humidity Measurement"
        capability "Temperature Measurement"
        command "setRelativeHumidity", ["Number"]
        command "setTemperature", ["Number"]
        command "setDewpoint", ["Number"]        
        attribute "dewpoint", "number"
    }
    preferences {
        input name: "txtEnable", type: "bool", title: "Enable descriptionText logging", defaultValue: true
    }
}

def installed() {
    setRelativeHumidity(50)
    setTemperature(70)
    setDewpoint(50)
}

def initialize() {
    installed()
}

def updated() {
    installed()
}

def setRelativeHumidity(rh) {
    def descriptionText = "${device.displayName} Relative Humidity is ${rh}%"
    if (txtEnable) log.info "${descriptionText}"
    sendEvent(name: "humidity", value: rh, descriptionText: descriptionText, unit: "RH%")
}

def setTemperature(temp) {
    def descriptionText = "${device.displayName} Temperature is ${temp}°F"
    if (txtEnable) log.info "${descriptionText}"
    sendEvent(name: "temperature", value: temp, descriptionText: descriptionText, unit: "°F")
}

def setDewpoint(dp) {
    def descriptionText = "${device.displayName} Dewpoint is ${dp}°F"
    if (txtEnable) log.info "${descriptionText}"
    sendEvent(name: "dewpoint", value: dp, descriptionText: descriptionText, unit: "°F")
}

[JasonJoel]

@aaiyar

Is this expected behavior? Meaning once a device is created with a set of capabilities/attributes, then the device node will ignore any new capabilities/attributes added later via driver change?

I would expect that to be true until maker api is restart, the device is added/removed from maker api, or node-red is restarted.

Could be wrong though?

EDIT: Oops, didn't see @fblackburn was already responding. Should have waited for his official answer instead of chiming in with my thoughts. lol

[aaiyar]

@JasonJoel

I would expect that to be true until maker api is restart, the device is added/removed from maker api,

Thanks this is what I see. Didn't try restarting node-red. So it is expected behavior - good! I was concerned that I had messed something up.

[fblackburn]

@aaiyar

On the other hand, if I create a brand-new virtual device with the same virtual driver (temp/hum/dewpoint), then updates to all three made on the Hubitat side are received by the device node.

Because after adding the virtual device in HE, you add a new device node in NR and deployment triggered a cache rebuild

@aaiyar

1. Is this expected behavior? Meaning once a device is created with a set of capabilities/attributes, then the device node will ignore any new capabilities/attributes added later via driver change?

Yes, you will probably see a javascript error in the NR log file. The best I can do, is catch this error and print a formatted error message. I would require some effort to support new attribute

@aaiyar

2. Have I configured my Node-RED incorrectly? To clarify, when the new driver (temp/hum/dp) is used on the existing virtual device, temperature and humidity updates continue to be received - so there's issue with the MakerAPI config.

No everything is fine, but you need to restart flow to rebuild the global cache. Or use this flow to rebuild cache without restart

When a new device is added or updated the global cache must be refreshed. Adding a new device node will trigger it, so it's why nobody see this. But if you update an attribute of existing device its more problematic

[aaiyar]

@fblackburn

No everything is fine, but you need to restart flow to rebuild the global cache

Thank you - that makes sense!

[fblackburn]

@JasonJoel

EDIT: Oops, didn't see @fblackburn was already responding. Should have waited for his official answer instead of chiming in with my thoughts. lol

I feel like a snail when I answer a question, trying to translate what I want to said, write, delete, write, fix, then finally not sure about what I'm writing, then testing, rewrite and finally click on reply ... but I re-read myself and I don't even understand what I have written, so edit my message and do the same steps again...

Anyways not surprising that everyone had time to reply before me

[aaiyar]

@fblackburn

Anyways not surprising that everyone had time to reply before me

But please know that you are very much appreciated. All the automations in my house wouldn't exist without node-red-contrib-hubitat.

So, merci beaucoup!

[JasonJoel]

Well, you speak English much better than I speak French. So... You win.

[fblackburn]

1.6.0 released

• config: allow to change nodes color according their configuration
• command: fix command error message
• Include first post example in the plugin (Import->Examples -> node-red-contrib-hubitat)
• rewrite README and include technical implementation details

Happy Valentine's weekend with your automation

[TechMedX]

Thanks for the update, can't wait to "play with it"

But seriously, is there a way to "store" a variable in NR in such a way that it's value appears on the flow like say a temp sensor? Right now I pipe the data into a virtual device and display that, seems crude.

[JasonJoel]

You can add a debug node, and config the debug node to show what you want on the node status.

yields this (an MQTT value in this case)

[TechMedX]

Thanks! but could you enlarge that a bit?

[JasonJoel]

Better?

[JasonJoel]

All kidding aside, the original ones didn't look very big on my screen to me. lol

But I'm getting older and make everything bigger than I used to.

[aaiyar]

So apparently bravenel has been investigating/evaluating node-red.

Rule machine 4.0 is too hard to use (Part II)

Each time you do what? When I work on one of the built-in apps, I can change the source code and not touch the device selections -- they stay in place. Only if I make a fundamental change, like going from a single device to multiple, or changing from a motion sensor to a contact sensor, do I have to reselect anything. So, 99% of the time it's just work on the code and then test. That's how regression testing works also for app changes. There are two things about RM that people complain ab…