As I go down the rabbit hole, I think I have a Z-wave device acting up. I see off calls from Node-red in the maker API log, but the light switch is still on and no notations in the log for those being turned off. And it is 4 different light switches that this is randomly happening.
Any ideas what might be causing this?
Only affecting some nodes.
I'm assuming its a websocket error.
But the websocket is working fine (it tests ok from a browser).
Weird.
Weird, can you post Node-RED log to see the error? log location depend on the Node-RED install type (docker, .deb, source, etc..)
Do you have more than one config node? (to explain different behavior, not the error) Or all your devices are bound to the same config node?
Same config node. Its on a Raspian OS Pi.
Off to bed now (really really late here!) will check logs tomorrow. Thank you!
2 Likes
Also......how to update the Hubitat nodes to get the new HSM one? I went into pallet management and can't find any option to update the nodes set. It just says they are already installed.
In the Nodes tab (not Install) you have a button if update is available (update to 1.2.0)
3 Likes
Moving rules from RMto NR and wanted to make sure this is the best/correct/easiest way to translate temp differences on NR.
RM
NR
That should work.
Just one thing to bear in mind. When I was initially setting up my thermostat flow, math I was doing with temperatures wasn't working correctly. Turned out I had to convert the temperature from a string to a number (you can do that using a JSONata expression in a change node).
While you aren't doing math in this sequence, just keep it mind should you need to in the future.
1 Like
I'm curious what math you're using in your thermostat flow. I've got a lot going on in mine with controlling 16 different thermostats in different areas of the house, but I'm always looking for ideas to improve it. 
Nothing that complicated. My thermostat (Honeywell T6) only permits a bias adjustment of 3F. Which is piddling, So I control heating/cooling by turning it on and off based on the average temperature/rel. hum. of either my upstairs or downstairs.
As an aside for the email you could use the "node-red-node-email" node and save a round trip back to HE.
1 Like
I dont see any errors in the debug panel on the right. Here's the node-red-log (not sure if there is another specific error log anywhere?)....
I found if I go into one of these sensors and change the attribute (to something other than motion) and then back again, the error goes away with a "deploy". Otherwise it just sits there with the error showing even if I refresh the webpage.
Probably that error occurs when the config node was deployed with websocket option (which we don't see here). We should see something similar to
7 Jul 10:28:12 - [info] [hubitat config:b870e340.a010f8] Websocket connected
7 Jul 10:28:15 - [error] [hubitat config:b870e340.a010f8] Websocket error: {"errno":"ETIMEDOUT","code":"ETIMEDOUT","syscall":"connect","address":"192.168.2.50","port":80}
7 Jul 10:28:15 - [info] [hubitat config:b870e340.a010f8] Websocket closed
You can increase the line number with -n option. ex:
node-red-log -n 150
Or if you deploy FULL. do you have the same behavior?
Yeah it's a weird behavior, I will take a look to the code in the next days to see if I can found something
Yep the status doesn't rely on the UI part. Only the backend update it
1 Like
I am running a custom dashboard on a tablet (html/javascript/css based) which uses websocket and several dashboards running in iFrames. I have noticed a few times a "waiting for websocket" message in the bottom left corner of the browser when testing that. So I'm wondering if the load on the hub from that is preventing Node-RED from opening the websocket in some cases? But then after a while it will re-allow it? I'm not very techi on this 
so it's just a hunch. I don't know whether maybe the number of active sockets (websockets/dashboards) are limited on the hub?
Yes, deploy method doesn't seem to make any difference based on my testing so far.
Yes it's a good track to investigate 
I'm quite busy right now, but I can test it in the next days
Even more weird is that I'm finding the node is still actually working....the Xiaomi motion sensors are continuing to send motion triggers (active/inactive) through the node despite the 'WS Error' message.
Almost the same kind of problem:
To simplify things and stop bothering people with my basic knowledge of node-red, I uninstalled node.js and node-red (and previous version of mosquitto) and emptied all the caches and hidden subdirectories (obviously more my skills here) of my node-red host (windows 7).
I then reinstalled the latest of everything and put my basic hubitat/node-red flow.
So far, so good, all is working without that mess (lot of old mqtt and modbus nodes).
All is working except that I receive a full long message into my command-prompt window. Maybe it's legit ? Some kind of errors but the link between hubitat and my node-red is working... So, errors but no problems...
I have for now 13 devices: 7 modbus devices monitored to HE and 6 virtual devices monitord by NR.
Despite the "errors", the data are collected in both ways regularly, with consistent values.
1 Like
A few other "dummy" questions please for the NR experts 
-
I realised that global context data/variables are not persistent across reboots/restarts etc. What's the best/easiest way to manage this to ensure that these variables in NR are available and reliable? (eg. run nodes on-startup I suppose)
-
Related to that, what do you do to synchronise anything needed in NR when HE hub restarts? Is there a way to trigger a node on HE hub restart (using the location service from HE)? I didn't find it. Or would have to use a switch?
-
And related to that synchronisation, what methods for managing global/local variables in HE <-> NR?
They dont look like errors to me. More like Javascript being displayed. I'm getting errors reproted in the graphics display against HE nodes (although they do still seem to run ok).
Sweet dashboard by the way. Nice job!
1 Like
