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
You can write global variables (and other context stores) to the file system. That permits them to be persistent across reboots etc.
https://nodered.org/docs/user-guide/context
I also write sensor data to disk - so I can recreate NR dashboard graphs very easily after reboots.
3 Likes
I haven't used the config node, but doesn't that store/retrieve context ?
Yes.
You would use the location device (as you pointed out). And then a switch node that looks for msg.payload.name = systemStart
Here's an example:
systemStart
[{"id":"b835886d.b69298","type":"hubitat location","z":"3943b86.98c64c8","name":"Location","server":"a22e0ea9.276dc8","x":140,"y":420,"wires":[["6d344eb8.aed638"]]},{"id":"6d344eb8.aed638","type":"switch","z":"3943b86.98c64c8","name":"systemStart","property":"payload.name","propertyType":"msg","rules":[{"t":"eq","v":"systemStart","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":310,"y":420,"wires":[["6cd11e94.1ca66"]]},{"id":"a22e0ea9.276dc8","type":"hubitat config","z":"","name":"HubitatM","usetls":false,"host":"192.168.1.46","port":"80","appId":"1522","nodeRedServer":"http://192.168.1.4:1880","webhookPath":"/hubitat/webhook","autoRefresh":true,"useWebsocket":false}]
3 Likes
Which config node? The node-red-contrib-hubitat config node doesn't. AFAIK, the only way to define context storage location is via ~/.node-red/settings.js (as described in Working with context : Node-RED)
node-red-contrib-config ?
1 Like
