Light group only return status when requested, not on change.

[Travelbacon]

First of all. Thank you for making this great pallet for Node-RED! I use it with a lot of pleasure to enable non-Friends of Hue devices to Homekit. Huemagic allows me to make more advanced sensor scenes that are not possible with Hue. And I can easily communicate with a low memory device like an Arduino while I save a lot of time by making cases/intelligence parts on the Node-RED side.

Describe the bug
The group node does not return the status payload when all lights in the group changed to on or to off.
According to the manual it should return the status payload.
"If a change in the group is detected, the following status message is returned from the node. Please note that the group only outputs status messages when either the last light is switched off or when the first light is switched on (if all were switched off beforehand)."

Flow to Reproduce
Add a group node with a debug node to read status. Turn all the lights off in this group via the (e.g. Hue) app. The group node does not return the status payload. If you inject the group node with payload.status = true, the group node generates the status payload.

In my testcase I use a group with only two bulbs. No other devices. I want to be sure that the switch might be counted as a device. I could add code, but that would be specific for my house. The work to adapt it is more than to drop these 3 nodes by yourself.

Please complete the following information:

• Node-RED version: 2.2.2
• NodeJS version: 14.19.0
• Device running Node-RED: 2 Pi's.

[andesse]

@Travelbacon

I opened already a bug report a month ago, (cause I am testing the beta firmware on one of my bridges) for these kind of problems. This contrib isn't converting correct from the HUE API2 to easy json format at the moment.
You can use this contrib for all status updates of all devices.

@yadomi/node-red-contrib-philipshue-events

[Foddy]

I will check out the updated docs and hopefully be able to create a fix soon.

With the latest public firmware I can reproduce this issue with the groups. Sending commands still works for me.

@andesse, please give me a hint what else is not working properly?!

[Travelbacon]

I opened already a bug report for these kind of problems. This contrib isn't listening correct to the HUE API2. You can use this contrib for all status updates of all devices.

@yadomi/node-red-contrib-philipshue-events

Thanks you! I can use this as a temporary work around.

[andesse]

I will check out the updated docs and hopefully be able to create a fix soon.

With the latest public firmware I can reproduce this issue with the groups. Sending commands still works for me.

@andesse, please give me a hint what else is not working properly?!

@Foddy

Buttons, rooms (grouped_lights), lamps, motion sensors. Everything wasn't working for me anymore, cause of the beta software. I can't get any data out of the nodes.

I issued this and the problem with the scenes, in bug reports a month ago already, that I see this coming. (Cause I have a beta software bridge and am on the firmware quite a while now)

The recommended contrib listens directly to the API V2 and hammers like a machine gun status updates out of the node.
I just Filter and switch them to my flows now.
With this contrib the latency for buttons / motion sensors for example dropped by 500ms. Everything is faster.

I'd recommend to have a look on the contrib.

Edit: yes, sending commands works fine

[andesse]

I opened already a bug report for these kind of problems. This contrib isn't listening correct to the HUE API2. You can use this contrib for all status updates of all devices.

@yadomi/node-red-contrib-philipshue-events

Thanks you! I can use this as a temporary work around.

@Travelbacon

You just need to use switches, and filter (filter by device Id and the action) out what you need. It also is quite a lot faster.

[Foddy]

The node-red-contrib-philipshue-events plugin outputs all events directly from the bridge and does not process them (converting the message to a consistent JSON format, adding additional information for each node, converting RAW XY colors to RGB, HEX…) like HueMagic does beforehand. HueMagic v4+ is using the same event source API by the way :)

It doesn't surprise me that using the raw event messages from the bridge is faster in latency…

The problem is the following with the betas:
Not everybody has them, they are buggy, uncompleted and they are not documented yet.

Even if the beta version is the new "right" one and the current, public version will soon no longer work, I can't expect every "normal" user to install the beta so they can use HueMagic. They are also changing pretty frequently their API – that would lead to more issues than nice new bridge features.

I hope that you (and others with the same issues on closed beta firmwares) can temporarily create workarounds with node-red-contrib-philipshue-events or similar until Philips releases the next stable API release / bridge firmware.

[andesse]

@Foddy

the Beta Community is on the same Firmware as the public bridges at the moment. It's 1950111030 even on my beta bridge, that version went public release.

As I also have an account on the developers page, I think they won't be too much changes in the V2 in the future. If yes, most likely additional things. They won't change the basics now, cause the V2 is already published to app developers, when I got that right.

I am not a pro, I just had a really bad time here when nothing worked anymore, so I was in need to find a solution with the other contrib. I really just send the data trough 2 switches, one for the device id, the second one for the event.

For buttons I use the initial_press and change it to a true instead using the short_pressed that comes even from the v2 quite a bit slower. Buttons are on turbo mode now and working instantly.

I really like the concept of HueMagic, cause it is so convenient. But I am not able to update. Is it because I changed one file for scenes in my system and the update checks the exact filesize?

[bmdevx]

I went through the code and I think there is an issue with the 'processResources' function in the API file. Editing the grouped resources section seems to have fixed the nodes reporting correctly for me, at least in version 1950111030.

// RESOURCE HAS GROUPED SERVICES?
if (fullResource["services"]) {
	for (serviceType in fullResource["services"]) {
		const grouped_services = fullResource['services'][serviceType];

		for (groupedServiceID in grouped_services) {
			if (!processedResources["_groupsOf"][groupedServiceID]) { processedResources["_groupsOf"][groupedServiceID] = []; }
			processedResources["_groupsOf"][groupedServiceID].push(fullResource.id);
		}
	}
}