Would I need three in this case? Device, pushed or held and then which button?
This looks great. I tried putting it into a function node though and didn’t work. Any thoughts?
Try this:
const { event } = msg.payload;
if (event.device_id === "866" && event.attribute === "pushed" && event.value === "7") {
return msg;
}
(The original code was fine, too, there was just a misplaced }.)
It sounds like all you really need the function node to do is act like a switch node, passing along the incoming message of if some conditions are met, or doing nothing otherwise. That’s what the code above does. If the if condition is met, the incoming message is simply returned as the output of the function node. If it isn’t met, nothing happens (i.e., the function node doesn’t pass the message).
As @MRobi points out, you could also just use some switch nodes in series. The only difference here is that the function node is a bit more compact.
1 Like
Yup, you’d need 3. One would check if msg.payload.event.device_name was equal to (==) “Kitchen Table”, one would check if msg.payload.event.attribute was equal to “pushed”, and one would check if msg.payload.event.value was equal to “7” (just like the if condition).
1 Like
I’ve got to be doing something wrong. I’m getting this now in debug
Depends on the situation. I’ve got 30some switches each with buttons 1-11. So that would be either a giant function node with 300+ outputs, or 300+ individual function nodes. I use 1 switch node to identify which switch, then 1 more switch node per light to identify the button. So I’ve got 1 more node than switches.
3 Likes
Good point! Switches can also be easier to scan than function nodes. I mean, looking at a flow, you have some idea of what a switch is doing. You can’t tell much from the outside about what a function node is doing.
2 Likes
Switch nodes worked great. Thank you again everyone! Awesome community
2 Likes
Anyone having issues with 0.115 beta working with custom component Hubitat? I’ve lost control and seeing states of all devices
I’ve been struggling with this lately. The RBE node is no longer working.
For every press on the switch, I’m getting 4 hubitat_events. Which I always had gotten but the RBE node stopped the duplicates. But now, the _msgid is different on every event and the payload timestamp is different by milliseconds.
Here I have a debug node on the hubitat_event and another on the RBE node. I turned on a single light.
It’s causing issues because every automation based on a light switch fires 4 times. Not a huge deal on ones that turn on another light (aside from network congestion), but I have switches that control garage doors which triggers then opens the door then closes the door and repeats. Or the switches that make Alexa announcements now announce it 4 times.
Because the msgid is different and the timestamp in the payload is different, the RBE node allows it to pass through.
Anybody else seeing anything similar and have a solution?
I was running into this as well
My solution was to use the “Delay” node set to Rate Limit set to 1 within 2 seconds and the “drop future messages” (something like that) checked
It completely solved my issues with this
Interesting, that could do it.
As a temporary I changed the RBE to msg.payload.event.description but doing this, if I hit the same trigger twice without hitting something else in between it would still block the second one.
Have you tried shorter than 2s? The timestamp of all the msgs seem to be within ms of each other. I’m wondering if a rate limit of less than 1s could work for those one-off situations where I hit a button and the wife hits a button at practically the same time.
EDIT: I guess rate limit minimum is 1s which is odd since the delay side of the node supports ms. I’ll test it at 1s
1 Like
Rate Limit set to 1s seems to have done the trick. I cycled through all my alexa switches and garage door switches and they’re working with no issues. I like this solution better than the temporary msg.payload.event.description RBE node I had put in place. Thanks!
1 Like
I just added this integration and it worked well, discovering the Xiaomi / Aqara zigbee temp and contact sensors from the HE hub.
The only thing I can’t get to work is the reporting of battery status. When I look at the sensor in HE it reports what seems to be an accurate status but in HA it says unknown.
Has anyone else come across this?
What are the contents of the duplicate messages (the payload)? I mean, are they actually duplicates (aside from the ID), or are 4 different events happening for each switch action?
So a battery entity was created in HA for the device, but it’s not getting a value?
They are identical. For example I’ll get 4 events saying “Dining Room Button 3 - Pushed”.
I turned on debug logging on HE and each button push causes 7 or 8 log entries (between debug logging and info logging). I wonder if some of those are being passed along with the original message as events?
@jason0x43 yes that was the case but after 24-48hrs it came good? maybe i was being impatient? my bad sorry