Restarting NR to add debug solved the issue 
Maybe you can try this workaround for now
It seems that it will be not easy to find the issue, I'll try more debug/scenario this week
edit: I created a github issue
2 Likes
Thanks so much!
2 Likes
Let me know if I can help in any way... thanks
1 Like
Does a NR restart resolve the issue for you?
I wasn't able to exactly reproduce it, but I found a bug that might have caused it
I released a bug fix version 1.6.1 
I added debug logs too. Then if you still have issue, turn your NR log in debug (in settings.js) and send me the log with the timestamp when it happens 
2 Likes
With the original node, I don't think so. I had restarted Node-red a couple of days before I noticed the issue. I have not added debug to NR 
Thanks! Will update on my test instance of NR and see if it solves the issue. Quick question - how were you "faking" a Hubitat restart (I saw that in the GitHub issue I think).
Well ok, then keep me informed (you can use debug now and leave it some days)
Explained in this post 
note: with this example you will only receive systemStart event on event node. To receive it with location node too, you need to inject {"content": {"name": "systemStart", "deviceId": null}}
1 Like
I did a somewhat basic test. I updated the HE node in my test environment and submitted a "fake" systemStart event and it was published by the Event node and the Location node (though there were no values - just the event name).
I then copied the flows to my live environment (with the older version of the HE node), changed the IP address of the server and the debug node did not publish anything for systemStart but I can see other events coming from the Event node.
Let me know if you want me to actually restart the HE to make sure...
Unfortunately, the older version of HE nodes will not output very useful debug log in NR. Even more when debug is not activated.
In all case, you should upgrade your live environment to the latest nodes version (1.6.1) and activate debug (via settings.js file). Then after some days, make the same test and see if it still works
Note: just to be sure, in your screenshot, the events/location nodes are disabled and will not output anything
2 Likes
Just upgraded and will activate debug.
EDIT: The "debug" to be turned on is the one in the console setting, right?
Yep - I disabled the nodes after I did the test.
1 Like
Yes 
1 Like
Started playing around with node-red again. Just discovered homekit for node-red which is great for custom accessories but everything I deploy my HK accessory does not know it's state.
What's everyone's go to to trigger the event when red-node starts or after you hit deploy?
I think when I used deconz there was an option when the node starts, it fired off it's current state.
I would guess where people want a trigger on start (I rarely do, but sometimes) they would use an inject node set to trigger on start/load piped into the device node(s).
Could do a single inject if you wanted to, connected to a link out node. Then link in nodes where ever you want that trigger.
That's how it do mine, although I also set a random delay too after each link in node to distribute the command load going to the hub.
5 Likes
Thanks, that ended up being easier than I thought.
1 Like
@fblackburn, could this be added to the Device node? I'm not keen on reading every event from every device to find the few devices I care about digital/physical events. Seems a lot of overhead to me.
Quick question - is systemStart published when HE reboots or when it is shut down and then restarts? I have a routine that reboots the hub and there was no systemStart event in my logging database so I wanted to check before I activated debug. Thanks.
It has been added for the Device nodes for devices that support it - it's the "payload.type" property.. this used to be an issue with Maker API in older firmware versions not the HE Nodes.
Or am I missing something? This is the debug output from an older Aeotec Nano switch.. check out the "type" properties. I physically turned it off then using HE turned it on.
2/27/2021, 9:07:04 AMnode: 3d1a12f2.1d8f9e
Den Hall Light : msg.payload : Object
object
name: "switch"
value: "off"
displayName: "Den Hall Light"
deviceId: "xxxx"
descriptionText: "Den Hall Light switch is off"
unit: null
type: "physical"
data: null
currentValue: "off"
dataType: "ENUM"
values: array[2]
2/27/2021, 9:07:37 AMnode: 3d1a12f2.1d8f9e
Den Hall Light : msg.payload : Object
object
name: "switch"
value: "on"
displayName: "Den Hall Light"
deviceId: "xxxx"
descriptionText: "Den Hall Light switch is on"
unit: null
type: "digital"
data: null
currentValue: "on"
dataType: "ENUM"
values: array[2]
EDIT: Do you mean you want to be able to separate event triggers into "physical", "digital" or "both"? I think that may be going against the design goals of @fblackburn's nodes to keep things as generic as possible but not sure. Seems trivial enough to filter out with a switch node.
1 Like
Right.
- The device node already publishes type when available in the event
- If you want to filter on certain types just put a switch node after the device node, with msg.payload.type = what you want
Like:
3 Likes
I hadn't considered that. I'm on 2.2.3.135. Does that qualify as "older" in this context?
Just run a device node into a debug node in node-red and look. Really no need to guess on this - type is either there, or not.
2 Likes
That's how I came up with the request. OK, fine, it's not available w/o the platform update.
Watching all the issues with every update after 2.2.3.135 convinced me to just stay with it. So now I have to choose which devil I prefer to dance with.
Thanks, @erktrek and @JasonJoel
