If it isn't auto updating, and only updates on save/reload, then the webhook/POST is not working correctly. Focus your efforts there. Maybe the POST URL is inorrect? Or if you are running node-red inside of something else (like docker or Home Assistant) then maybe the port is correct/open/or forwarded?
1 Like
I would be tempted to build a function node saving the count either to a separate context variable per topic or a single array or object with an entry per topic. If I built it that way I would probably go the object route, include the time/date in epoch time and then reset the counter if it has been longer than some preset interval as that would indicate the battery got replaced.
2 Likes
If device node work as expected, then be sure to enable the checkbox to allow mode events to be sent by MakerAPI
Not sure to understand what is strange or what behavior do you expect
I have a custom logger function that make this logic here. Maybe is what you talk about?
Can you post an example of log that you refer to?
This may work. I haven't used it and it's over 2 years old, but seems simple enough.
1 Like
I think that node counts messages per unit time.
Going to Terminal of Raspberry Pi that is running Node Red and entering node-red-log, I get this:
It seems to happen when I change the device that a node refers to and erase the previously-entered Name field for that node so that it auto-populates with name of device.
It's no big deal and doesn't seem to affect performance; just unusual.
It counts messages per unit if payload is not numeric, but metrics per topic if payload is numeric.
Test flow below:
[{"id":"62fafc23.4b323c","type":"Metric per Topic","z":"46fabc1a.2d7c94","name":"Per Topic","units":"minutes","interval":"1","alignToClock":true,"generator":"internal","x":628.3333435058594,"y":959.0000839233398,"wires":[["917f4c16.973478"],["4f219f72.4d6968"]]},{"id":"a4070ce9.6b226","type":"inject","z":"46fabc1a.2d7c94","name":"Count 2","props":[{"p":"payload.att1","v":"one","vt":"str"},{"p":"payload.att2","v":"two","vt":"str"},{"p":"payload.att3","v":"three","vt":"str"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"Test Count2","x":265.3333435058594,"y":959.6666870117188,"wires":[["a01e964f.2632c"]]},{"id":"60e04fd1.764a4","type":"Metric per Topic","z":"46fabc1a.2d7c94","name":"Per Message","units":"minutes","interval":"1","alignToClock":true,"generator":"internal","x":601.6666259765625,"y":867.6666870117188,"wires":[["17131011.f1c19"],["7b1e9d01.7289e4"]]},{"id":"a01e964f.2632c","type":"change","z":"46fabc1a.2d7c94","name":"","rules":[{"t":"delete","p":"payload","pt":"msg"},{"t":"set","p":"payload","pt":"msg","to":"1","tot":"num"}],"action":"","property":"","from":"","to":"","reg":false,"x":463.33331298828125,"y":958.0000610351562,"wires":[["62fafc23.4b323c"]]},{"id":"d216576b.3e2dc","type":"inject","z":"46fabc1a.2d7c94","name":"Count 1","props":[{"p":"payload.att1","v":"one","vt":"str"},{"p":"payload.att2","v":"two","vt":"str"},{"p":"payload.att3","v":"three","vt":"str"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"Test Count1","x":275.6666564941406,"y":833.6667098999023,"wires":[["60e04fd1.764a4","a01e964f.2632c"]]},{"id":"17131011.f1c19","type":"debug","z":"46fabc1a.2d7c94","name":"debugCount1Out1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":823.6665954589844,"y":838.6667098999023,"wires":[]},{"id":"7b1e9d01.7289e4","type":"debug","z":"46fabc1a.2d7c94","name":"debugCount1Out2","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":824.6665954589844,"y":891.6667098999023,"wires":[]},{"id":"917f4c16.973478","type":"debug","z":"46fabc1a.2d7c94","name":"debugCount2Out1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":825.6665954589844,"y":928.6667098999023,"wires":[]},{"id":"4f219f72.4d6968","type":"debug","z":"46fabc1a.2d7c94","name":"debugCount2Out2","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":828.6665954589844,"y":983.6667098999023,"wires":[]}]
2 Likes
I am looking for suggestions on how to gather color info from a hubitat controlled bulb in Node Red.
The bulb in Hubitat tracks the color as 3 separate component (HSL). When I change the color in Hubitat, Node Red only gets the components that change.
I have tried using a join node, but that only works if all 3 have changed. With the join node I can get [49,100,100] for cyan and then if I change the saturation and level, but not hue I get [,35,89] whereas if I change the hue, I get [24,,]
I leaning toward just storing the 3 components in a local context variable, taking the output of the join variable and if an entry is null adding it back based on the context variable. That feels clunky somehow and was wondering if there is a cleaner way.
I am trying to have an automation based on when HE is restarted (NOT rebooted - using http://HUB_IP:8080/hub/reboot). Does anyone know of an event that is published to the HE node on restart? (NOTE: systemStart happens in both cases, so I cannot base it on that event)
Long story: I have a NR flow that receives HE log events via the unsupported websocket (logsocket). When the hub is rebooted, the websocket node remains connected. However, if HE is restarted, the websocket node shows that it is connected but does not receive any data. I have a weekly scheduled flow that reboots the hub and everything works fine. However, I have been having an issue where HE periodically restarts. I have not been able to nail down what is causing this - logs are clean, system resource usage does not appear to be abnormal etc. Currently, I am monitoring the log data and if the last entry was received > 90 minutes ago, I get an alert and have a NR flow that I can kick of manually that restarts the NR flows (and reconnects the WS node). I would like to automate this process hence the need to figure out an event that happens only on restarts and not reboot.
@fblackburn @erktrek @aaiyar - any ideas on this?
EDIT: I have seen the zigbeeOn event in the HE location system events log - this looks like it happens only when the HE is restarted as I don't see this entry when the weekly reboot happens but I don't know if the HE location node sees this (don't want to "test" it as I have only 1 hub 
)
Why do you need to distinguish between a restart and a reboot? Couldn't you just restart the flow in either case? I know it's not the most elegant solution but if it works...
Yep - that was going to be my fallback if there was no other solution.
1 Like
Hmmmm... @rakeshg One way would be to create a reboot subflow with 2 sequences.. first sequence sends a reboot and sets a variable (and would be triggered by the input). The second sequence waits for a systemStart and when it occurs checks to see if the variable has been set - if so you know it's been told to reboot. If not you know it's a hub crash. Could have 2 outputs one going to manual reboot, the other going to inadvertent reboot..
Or something like that...
edit: you don't really need a subflow for that, just 2 sequences and use a global variable. My over-engineering at work again... on the other hand if you are having the hub reboot in various flows then maybe a subflow would be okay.
3 Likes
Ah ok, then yes it's unusual but expected
technical reason:
Node-Red (core code, not Hubitat nodes) interpret name property when logging. If defined, then use it, otherwise, use node ID
But Hubitat nodes auto-populate name feature doesn't use name property. That's why you will see only ID when name is not explicitly filled.
I can confirm, there is no impact on performance 
I was just thinking the same and then saw your edit! I’m going to mod my existing flow to add the GV and then reset it from the systemStart event flows. If it is not set, then do the NR flow restart… sounds pretty straightforward - thanks for the idea!
2 Likes
One difference between reboot (Linux reboot) and restart (JVM and platform restart) is that during a reboot the hub stops responding to pings momentarily until the Ethernet interface is brought up and tcp/ip stack is loaded.
So, if you use a ping node in conjunction with the systemStart location event, you can distinguish between reboot and restart.
2 Likes
Thanks for the suggestion. It was simpler to use @erktrek 's suggestion and use a GV to distinguish between scheduled vs random restart events. As it turns out, I was able to use use a couple of change and switch nodes and plug them into existing flows and hopefully it all works 
2 Likes
So starting yesterday (maybe because of new hubitat release???) my working node-red stopped receiving events.
Any suggestions on how to debug this?
Anyone else experiencing issues?
I only updated one hub yesterday but NR seems to be working okay. Did you reboot Node-RED? I am going to upgrade the other 2 hubs and will report back if I have any issues.
1 Like
Updated both of mine to the latest release (2.2.8.145) yesterday, and I haven't had any issues with my NR sequences.
Any suggestions on how to debug this?
Check your Hubitat configuration node(s) and confirm that:
- The IP address for your hubs match what is NR.
- The MakerAPI application ID is correct for the instance being used with NR.
- The webhook configuration in NR matches what is MakerAPI.
- The security token matches the token in MakerAPI.
1 Like
