Only selecting a single device is okay for me too as long as it can be done dynamically - we can most likely parse things prior to that to get multi-device behavior. Matching would not have to be done in the node itself (or did I miss something?)
I was thinking the same, could possibly do a split node or something to break everything into single messages if only 1-1 matching is available.
1 Like
I am working via NR to consolidate all of my device status info into MQTT (and InfluxDB for analysis). I am doing this to account for Hubitat devices, Homebridge devices and ZigBee2MQTT devices. Working with the Hubitat device nodes, before all became an attribute option, I could get current status when NR starts (at the cost of hammering my HE) and then get ongoing status as things change with one device node per attribute. This is a little messy but the complexity can be hidden in subnodes.
With the addition of the option of selecting all attributes in the device node, it appears that I get the same info upon initially triggering that node.
-
Does it also emit events for any change to any of the attributes of that device?
It seems to -
Does the output change format?
It seems to. When triggered, the payload seems be a set of objects each of which is the equivalent to the payload of a node configured to a specific attribute, but when an event happens on HE and is sent through, the payload seems to be just like the output of a node configured
-
Does either approach (one NR node per attribute or 1 all attributes node per device) a larger strain on HE Maker Api?
-
If there is a difference, is that only true of a NR to HE request or is it equally true of receiving events from HE?
Yeah the words were wrong. My enough was only on local network
Being on local network is not a reason to remove all piece of security.
You don't want necessary be bulletproof against Internet, but only against your son who is trying to spoof and remove the parent controlling.
There's a lot of use cases I guess and I don't really care.
The point is only being compatible with what Node-RED offers (and how to mitigate Basic auth attacks)
To get ZigBee2MQTT up and running on an RPI 4, would a USB stick like this one work? I ask because I have one sitting in a bin right here at my desk. The thought of just bypassing the middle man (HE) is intriguing
I don't see any mention of "CC2531" in the specs for the dongle, so I'd suspect "no" 
#embrace_mqtt
Oh I didn't think about this use case.. the device node would be much more complicated to be dynamic.
We will need to keep state of all devices on start and restarting node-red when new device is added to Maker API 
But you can do it similar with request and event node (with variables)
I was thinking about this kind of use case:
- dimming (or send off command) when you open light after and specified hour
Event -> filter(capabilities switch?) -> switch (is after 23h?) -> delay(30 min) -> Command(turn off with msg.deviceId)
With only command node with dynamic deviceId you could do it too. Not according to the current state of the device, but sending the same command to all command with upstairs-* prefix. You only need to use the request-split-command nodes
There are maybe some tradeoffs on performance (requesting all devices), but, IMO, for bulk action it's a nice workaround
Aah now I understand what you wanted to say by full/partial/regex name matching. Well, not using ID add the issues mentioned above (init + rename + new devices), it's mainly a sync/cache problem
1 Like
I'm not 100% sure it is worth the trouble to make dynamic device inputs to the nodes - for many of the reasons you list. Especially as there are workarounds that exist today using the request and event nodes.
But that's just my opinion.
If it was there, I would likely find a use for it, if it isn't I know how to work around it.
2 Likes
Yes
You're right about the inconsistency of the payload (triggered by message vs events)
There are two reasons:
- keep compatibility: the All attribute has always exist, it was Undefined. The feature was only to send all attributes on message input, but the event logic has not changed
- Sending all attributes at each event would have hidden on which attribute the event occurs
I don't really like either to have inconsistency with the payload. Another solution would be to send only the attribute wrapped with the attribute changed (to keep the same payload format) ... But it's not ideal either 
Yes only on initialization. Each device node will query HE to know its state. But this process is mitigate with maximum to 4 simultaneous requests until all requests are done (tested with more than 200 (or 400) device nodes without issue)
Only for initialization, events are handled by the config node and dispatched to all other nodes. So it only impacts Node-RED (which is negligible)
2 Likes
I started investigating finite state machine. Never having used one before, I've got some queries. How does it work if there are multiple scenes for lighting, but they are not as simple as their example.
I've got some logic currently, not using finite state machine, that has certains lights on for lux, other lights come on for movement, and some of those same lights turn red if the garage door is open, and then if the TV is on, then they all turn a shade of blue. Then there are mode/presence stuff too. Is this too complex for finite state machine? Does fsm need to have simple logic going from one state to another, such as in the example above, ice -> water -> steam?
This is still happening and now more regularly. When it does, lights never turn on as a result of a button push or happen 10+ seconds later. Sometimes, I can get it fixed by doing a Node-Red-restart so that every device gets initialized but that's not a long-term solution as that takes minutes to go thru every device. In the meantime, automations don't work. The weird part is for the Device Node, it will show the current Device attribute value under the node but when I go to edit the node, it says "Choose device...." and the list for the dropdown is blank.
EDIT: Just watched the NR logs go thru and initialize every device and things started working normally again and less than 15 minutes later, the problem happened again and this showed in my NR logs.
The flows stop and then every device starts initializing again and all of my flows don't work until it's done. What could I have done to cause this?
I've not used a FSM before either, but I got one up and running a motion lighting flow. Once you've got the idea of transitions and states the method becomes clearer. Much easier than a complex RM app IMO.
Uses node-red-contrib-state-machine (node) - Node-RED. Flow based on https://www.reddit.com/r/homeassistant/comments/afk6cd/building_smarter_motion_lighting_nodered_finite/
1 Like
Hmmm. No ideas on my end. I haven't seen the same behavior. At least not to my knowledge (I haven't had to manually restart node-red or anything).
I'll try to look through my logs in the morning to double check though.
I think it might be this:
@fblackburn This is your sample flow from Github and it's set to Inject at every Deploy and then Get Devices All.
I know if I do this in Maker API, it will bog down my hub severely.
When I have been watching when this injected, there is a status of "Requesting" for minutes under the node.
I am not a ZigBee2MQTT expert by any means, but I am using it to be able to use my cheap ikea input devices that don't work with HE. I did buy and flash a CC2531 so I am on the most standard path for Z2M. That said, the key part of the configuration seems to be pointing to the right port. Since the device you referenced claims to put Zigbee on one port and Zwave on the other, I figure there is at least a 25% chance it would work.
I don't think the inconsistency is to bad as I already have a process to handle single objects and I would only have build small function to turn the combined initial output into a series of message with 1 each. so I would have 2 device nodes set to all (1 triggered on startup but not sending events; 1 sending events but not triggered by startup).
Just to verify, I take this to mean that I will actually decrease the load on HE by switching from 1 node per attribute (current config) to 1 node requesting all and then breaking it out into individual attributes in NR.
So I am doing this with 2 hubs and not seeing that behavior.. or maybe missing it somehow.
(noticed I made a mistake on the events - should be 2 events)
Edit: mmmm now seeing a long "requesting" for the top "Get Devices" which is my main hub.. took about 30 seconds to clear. I do have a bunch of devices on that hub though.
I'm wondering, if I was working on another flow and hitting deploy multiple times within a few minutes, would that have multiple simultaneous requests going to my hub?
Mine definitely says "Requesting" longer than 30 seconds. Same if I click "Get All Devices with Full Details" in Maker API
So things would get clogged up in the queue.. Don't think there is anyway clear a request once it's been sent is there?
How does it act if you don't do anything in NR for a while? - not that that is physically or psychologically possible mind you... 
Once request is finished, it seems to be ok. If I change the Inject node to not trigger on Deploy, that should avoid problem for that sample flow because it only queries All Devices first time then relies on events. @JasonJoel mentioned that in one of his posts and says the Get Devices All "hammers" the hub. My hub was definitely getting hammered; multiple times simultaneously I believe.
1 Like
