Do you have static IP addresses for Hubitat and the machine that your node-red instance is running on? If not, it could be that the IP address changed on either...
@rakeshg I do. The IP addresses haven't changed, they're static. Also, the web socket node works and the Hubitat config node seems ok since I get a device listing out of a new Device node.
Hmm - have you tried deleting and recreating the event node? Could be a coincidental but I think the timing of the internal hub "maintenance" is around 3:00 AM (from what I've read on here in the past). Not sure why it would mess with Node-red though - I do something similar where I log events to a database using Node-red.
I've done that as well as recreating the node-red container. It started working so I am not sure what caused it in the end and what solved it.
1 Like
I've had similar behavior. I "believe" it's related to multiple NR flow deploys. Two suggestions.
Restart NR.
Select the MakerAPI app for NR, open, select devices, toggle 1 on/off, update, done...
1 Like
Yes you can make sure that IP:port match your NodeRed instance in Hubitat Maker API configuration page (but since a simple restart fix it, it was clearly OK)
Yes, if you have any output in your container log. Moreover, if you are able to reproduce this bug, you can set logger in debug mode to have a lot of additional information.
If you use container, you can change logger in /data/settings.js (near to line 284)
It's not a good indicator because listing devices only use Maker API from NR -> HE, which is generally fine and easy to debug. When you receive an event, it's from HE -> NR , which can have different issues (i.e. firewall, wrong IP, mapping container/port, etc..)
Did you use websocket (not recommended) option in config node?
If no, to have a better simulation you can also test with a generic HTTP IN node and another Maker API instance to test if it still work
Glad you fix it, if it still happen, try to remember what did you do before it stop to work and let me know
It's not impossible (already happened in the past). Unfortunately, I cannot reproduce, it's maybe a specific combination of config/deploy/etc. I will take a special look at this piece of code
Thank you for your feedback
1 Like
@fblackburn thank you for your thorough answer. Hopefully, this won't happen again though I will monitor carefully. FYI, when I mentioned WS, I wasn't referring to the optional WS checkbox in the Hubitat node but the websocket node itself that I was using directly to make sure the rest of my flow was ok, when I couldn't make the Hubitat node working.
I'll check out that settings.js source file. I am surprised this isn't 'externalized' in a config file however.
Thanks again for your thoroughness. I'll let you know should it happen again
1 Like
Anyone able to help? I have a virtual switch that is exposed go Google that I use to turn a real switch on in node red, but I now want my virtual switch to adjust levels. How do configure node red to match the real switch level with that of the virtual switch ?
What values do you get from Google? You'd have to translate them over to your device.
Another thing you could try if both virtual and real switches are on HE maybe is to use the mirror app and bypass NR altogether.
1 Like
I like @erktrek’s suggestion of using the Mirror app in HE. If you want to do this in NR, then you do the following:
-
Set the virtual switch device node to use the attribute level. Send events should be selected.
-
Connect this to a change node that sets msg.arguments to msg.payload.value (i.e. the level of the virtual switch).
-
Connect this to a command node for the real switch. Choose the command setLevel and the arguments should be msg.arguments
(I am going by memory, so while the general gist of this is on track, the details maybe off. Hopefully, someone else corrects the details)
1 Like
To clarify, leave the Arguments field blank in the Edit Command screen because the previous Change Node is supplying that value
1 Like
It's a built-in app called Mirror. I think @mike.maxwell wrote it.
2 Likes
I have and plan to keep the vast majority of my bulbs (especially z-wave ones) controlled via Hubitat. I have a few zigbee bulbs that I have been experimenting with control through zigbee2mqtt. It supports 2 commands that it calls alerts that either one time or repeatedly flash by altering the brightness before returning to original setting.
Is there an existing way to do this in Hubitat or has anyone created a Node-Red flow that does this for Hubitat controlled bulbs?
If not, I can imagine how to build it in NR, but didn't want to reinvent the wheel if it is already around.
Another question where I think I know the answer, but wanted to ensure I wasn't missing anything.
Using the existing drivers (not wanting to roll my own), I have a bulb that has a "color fade time" preference that sets how long in seconds it takes to transition a color bulb from one color to a newly selected color.
Is there any way to change that preference from NR? (I don't think so.)
I am guessing that it could be rolled into a modified driver so that a setColor command could have a duration, just like a setLevel command does in most drivers, but I think that is the only way to expose it to NR.
@aaiyar I know you recommended the node-red-contrib-easing palette before. Could that do what @tmichael is looking to do?
2 Likes
@stephen_nutt is on the mark. You can replicate this behavior with the easing node.
If I were to using the easing node to go from color #02de53 to #d602b3, how would that work?
It seems like a great way to say ease from brightness 10 to brightness 80, but not sure how that would work with color.
You would have to convert from hexadecimal to separate HSL values. Then run the easing node on the desired values and then set color using HSL.
For example:
#02de53 is 142, 98%, 44%
#d602b3 is 310, 98%, 42%
So in this case, you basically only need to run the easing node on the Hue.
1 Like
So convert the Hex to HSL, ease the H and then convert back to Hex or any other color format that a device needs as an input.
I will try that. I wonder how it compares to the easing function built into Zigbee2MQTT that I am using with an Ikea Color Bulb.
