I have not use Home Assistant. I was messing with the Lutron Node red but can't imagine that doing anything. Thanks
Anyone tried conbee2 / deconz with Node Red on a Pi?
As I have plenty of time on my hands, I've ordered a conbee2 just to have a play around with. Initially the plan is to move over my Hue Bulbs from the HUE bridge to deconz just to see how well it works, but if that is successful I might see how well it would work with all my other Zigbee stuff too. I like the fact that the Conbee can apparantly be moved easily from one hardware system to another if need be and I understand the deconz can utilise the power on behaviour of the HUE bulbs in the same way the HUE bridge does.
But I don't know if deconz has the same issues with Zigbee bulbs being "dodgy" repeaters when on the same network as other Zigbee devices.
With Node-RED... No. In general yes. I have the ConBee, ConBee2 and RaspBee. DeCONZ is a good system and device support is growing constantly. Item to note however is the Phoscon interface is really narrow in scope so most devices are presented as Lamps... So even if a device pairs and works it's going to "look" like a lamp as that is the focus.... it gets annoying.
Don't know. I haven't seen reports/issues about it.
1 Like
What's the desired end game with this? To be able to MQTT to Hue stuff? Remove the Hue Bridge from the equation (i see people want to do this all the time but never understand why)? Something else?
I've been looking, admittedly not very much as time hasn't allowed, to see if I could get Hue stuff subscribed to MQTT events
In terms of end game, I guess the ideal is to have all my Zigbee devices on DeConz so everything is running on one system.
At the moment I have Node Red on a Pi running all my logic, my bulbs on Hue and the rest of my Zigbee devices on Hubitat. I have no Zwave devices now. If I can get them altogether on a single system I think that will be much cleaner and easier to backup and/or move from one hardware system to another.
1 Like
I don't like all my eggs in one basket.
I would be happy to, providing the system can be easily backed up and replicated which I think this would be.
I do think the backup/restore of deCONZ is easier. Myself I'd do inventory and validate my devices before going to too much migration work. I'd hate to find out mid-way that a critical device wouldn't work and have to then revert back. I find it curious why people want to get away from the Hue bridge though. I've never had problems with it. It just works.
I have no problem with it per se, it's just that I'd prefer to have all devices under one roof if possible providing it doesn't compromise performance and features. That is what I'm going to test.
1 Like
Bad zigbee repeaters are bad zigbee repeaters on ALL hubs/sticks. Switching systems does not fix or help that at all.
Segregating them on their own zigbee mesh, removing other devices on the same mesh to lower total zigbee traffic and thus (hopefully) not trigger the route table memory overrun/dump, or replace the badly behaving devices are the only things you can do.
1 Like
I want to thank Mike for this post. I'm just getting started with NR, and the first thing I've been trying to do is get a simple motion lighting sequence to work. I'd been following the basic examples given earlier in this thread, as well as the online tutorial they are mostly based on. I kept having the problem where if I don't stop moving within the timeout period, the lights would just turn off.
I fully understood the reason: The timer was started by an "active" event, but if I don't stop moving, my motion sensor never sends a subsequent "active" or "inactive" event to reset the timer. I had a fair idea of what I needed to do to fix it, but seeing this post made me see a solution, even if it's a little different from yours. In my case, I haven't done it through a Function node. I just did it with a Change node, setting msg.payload to "stop".
Here's my working sequence. I haven't added any conditions yet (eg. lux or mode), but this has been a good learning experience. This seems to work as I want it to for now.
ps. I can't quite understand why everybody else didn't come up against this same issue. Is it because of the way our motion sensors work? Do some sensors repeatedly send "active" events if motion doesn't stop? I'm using an Iris V2 Motion Sensor.
1 Like
if so, then using the "RBE" (Report by Exception) node will accommodate that as it will only send its payload if the value of some property changes.
So if your sensor keeps sending "active" "active" "active" it stops the flow dead in it's tracks unless it goes "inactive"
In my case, it doesn't repeatedly send "active" events.
This has been reported earlier in this (very long) thread.
Many, maybe most, motion sensors go back inactive and then active again. Some, like yours, don't. So those need different logic.
I have both styles in my house, and have node-red flows for each style. I could share a flow example if you want.
2 Likes
OK. At least now I know I wasn't really doing anything wrong; I was just dealing with a different device behavior.
I was actually thinking that Node-RED probably deserves its own category by now 
This thread is pretty monstrous already. (And I wouldn't be surprised if this has already been suggested, too!)
Sure! Since I'm just getting started, I'm open to seeing alternative ways of doing things
Here you go. It is more or less the same as yours above.
This one uses an Ecolink motion sensor. Those stay active continuously if motion does not end within the timeout (which is a super long 4 minutes by default).
The basic idea is that you don't start the OFF timer until it goes inactive. And you STOP the delayed off timer if motion becomes active again.
It checks the current status of the lights, and doesn't try to turn them on/off if already on/off. Could also be done with a change node to set the msg.command, an RBE node, and a single command node. I find two separate paths cleaner/easier to read though.
It also will not allow the lights to turn off if the TV is turned on. Just ignore the "Roku TV Arcade" and next "on/off" node for your case.
1 Like
Cool. Looks like I ended up with pretty much the same design. I realized after posting, that a couple of my node names probable weren't the best/clearest, so I changed them and re-organized things a little. Here's how my sequence looks now:
2 Likes
If your flows use the device nodes to get device status from HE to NR, you may have gone through some of the evolution that I have in how to use them. At first I used them strictly to get a single attributes status. This meant that when I cared about multiple statuses like a bulb’s switch state and a bulb’s brightness state, I had 2 separate nodes.
For playing roles in various flows this is often worthwhile, but if you are trying to collect a lot of data (for MQTT or Tables or InfluxDB), this can get quite tiresome and if you get it at NR startup/deploy it can really hammer your HE with requests. Thus, I was excited to start using the all entry for the attributes field of the node. This way I can get all the attribute information in one place.
The drawback I found however is that an all attributes device node sends 2 different formats of information depending if it was triggered or if an event occurred with the device. When triggered it sends an object containing an object for each of the device’s attributes. This is an example for my 2 attribute Floor Lamp Bulb:
Whereas an event triggered output has a payload with an object with details of the attribute that changed. Here is an example of the switch in that bulb changing:
Thus, to get all of this information, I had to set one node to not send events and have it triggerable via injection and set one node to send events but not to have it triggered. As a result a sample flow looked a bit like this:
And since I wanted to put all of the information into my database, I had to build 2 separate processes to handle the 2 types of inputs. The one getting the multi-object input as shown in the first image had to parse out N-number of individual inputs
So I decided what I really wanted was to be able always get single object status/event, but still have access to the multi-object if I ever wanted it. To do this I created a function node that pairs nicely with a device node that can be triggered manually, but that also sends events. Here is the flow from above with that function node:
If anyone is interested here is that function node ready to be imported:
[{"id":"18e80edf.fadfd1","type":"link out","z":"27566e75.091d22","name":"Do stuff with Multi-Attribute Objects","links":[],"x":820,"y":200,"wires":[],"l":true},{"id":"22cbbbf2.21e404","type":"link out","z":"27566e75.091d22","name":"Do stuff with Single Attribute Objects","links":[],"x":830,"y":160,"wires":[],"l":true},{"id":"719c2698.0d8118","type":"function","z":"27566e75.091d22","name":"Split 2 types of device node outputs","func":"var singleAttributeData = false\nvar foundType\nfor (let [key, value] of Object.entries(msg.payload)) {\n foundtype= typeof(value)\n if ((foundtype==\"string\")||(foundtype==\"number\")||(foundtype==\"boolean\")){\n singleAttributeData =true\n }\n}\nif (singleAttributeData){\n node.send([msg,null])\n} else\n{\n node.send([null,msg])\n //interate through the objects in the input\n for (let [key, value] of Object.entries(msg.payload))\n { \n msg.payload = value\n node.send([msg,null])\n node.done()\n \n }\n}\nreturn","outputs":2,"noerr":0,"x":480,"y":160,"wires":[["22cbbbf2.21e404"],["18e80edf.fadfd1"]]},{"id":"65749fae.88073","type":"link in","z":"27566e75.091d22","name":"Get Input from Device Node","links":[],"x":180,"y":160,"wires":[["719c2698.0d8118"]],"l":true}]
Not that anyone is waiting for it with bated breath, but I am also working to redo my earlier post where I shared a few function nodes that I might be helpful if you are sending HE info to MQTT or InfluxDB. I messed up the formatting on the old one and so prevented anyone from using the code.
No matter what you would need 2 different parsers, but couldn't you have just run the single node that spits out triggered and event payloads into a switch node, and did a quick "has key" check on msg.payload.value to pick the path taken?
Not a big or real functional difference. Just asking.
I was replying when I saw your revision with the screenshot. You are correct I think your switch node solution works equally well.
