TypeError: Cannot read property 'owner' of undefined in node-red-log

[djiwondee]

Describe the bug After node-red-restart, there is no access to the light anymore. The node-red-log shows an error very early after restart

16 Jun 15:29:40 - [info] [hue-bridge:Philips hue II] Processing bridge resources… 16 Jun 15:29:40 - [info] [hue-bridge:Philips hue II] TypeError: Cannot read property 'owner' of undefined

Sending a message in node-red to a light node raises an exception as well

Re-pairing the bridge at all doesn't solve the problem as well. I've read already the recent issues and would agree with the assumption about some recent changes of the Hue API. But a proposed workaround is related to Groups and the alternative is time consuming to change the setup at all. Would really appreciate, if a fix would become available.

Expected behavior Command sent (in my case) to a Lights node working successful as before

Screenshots

Please complete the following information:

• Node-RED version: 2.2.2
• NodeJS version: 12.22.12
• Device running Node-RED: Raspberry Pi 4

Thanks in advance!

[andesse]

@djiwondee here is the fix

https://github.com/andesse/hue-clip-api.node-red-flows

[djiwondee]

Thanks @andesse!

have seen your repo quickly when I was reading the recent issues. Appreciate your work for that, but changing my setup with this takes me to much time. So my workaround is to go with this since I have MQTT already in place for controlling my equipment!

However, I would really appreciate getting an update from @Foddy. I'm patient for now. I can imagine @Foddy may have not so much time to respond quickly. All these fancy things here are mainly based on hobbies and costs free time. Who knows how his availability is right now...

[andesse]

@djiwondee thanks! This might work for some time but is API V1 that might be deprecated soon. That is the reason for the frequent updates from HUE, cause they merge everything into API V2 (Clip API). I saw it directly cause it's from 2020 and he is referring to the API V1 documentation. It might work for now, but idk how long.

How many Bridges, Lights, Sensors do you have? You probably saw my setup in a screenshot. That took me a couple of hours without having all the sub-flows and Pre-made action change nodes on hand, that I have in my repository.

If you have the same or even less, it might take you not so long. Most time will be probably spent on labeling link in / out nodes lol.

Edit: doing it like this, you're completely following the HUE API in the best way.

[marc-gist]

@djiwondee here is the fix

https://github.com/andesse/hue-clip-api.node-red-flows

Thanks! I too hope @Foddy can update his wonderful library soon :)

Anyone know/use HomeAssistants Hue integration? how well does it work. Love to stay in NR, but... I have lots of flows with Hue, so if I'm updating to something else, I hope its a permanent move (well, hopefully I don't need to, but plan for the worst i always say).

[andesse]

@marc-gist when you can send https requests with your automation, of course you can. If you are somehow able to read the eventstream, it could be possible in ha

[djiwondee]

@Travelbacon thank you very much for this quick fix. It works for me. I only utilise the "Hue Lights" node in my setup so far. This node is working now again and the initial error in the node read log when this contrib is connecting to my bridge has been disappeared.

[djiwondee]

@andesse

How many Bridges, Lights, Sensors do you have? You probably saw my setup in a screenshot. That took me a couple of hours without having all the sub-flows and Pre-made action change nodes on hand, that I have in my repository.

I'm running 16 hue bulbs, 2 hue power outlets, 4 motion sensors

Edit: doing it like this, you're completely following the HUE API in the best way. Totally agree! but your valueable flow looks right now more like a proof of concept. A lot of things I'm missing needs to be added.

• the identification of the devices rather determining the Id
• meaningful RGB values as parameter rather than Hue CIE colorspace XY coordinates.
• a simplified msg.payload for each
• persistens of the devices state

For all of these things node-red-contrib-huemagic is really a benefit!

[andesse]

@djiwondee

Yes, I agree that HueMagic is more convenient, cause it’s parsing the Data in the background. But that also makes the response a little bit slower.

I added a helper Flow for my repository where you can read all ID / Rid in one go, with an easy to read output. So the identification isn’t that time wasting anymore, unfolding all arrays. It can be downloaded separately.

Personally I don’t use specific colors for lamps. I have 2 lamps that need to be turned on in a special color. Just set the color in the app, read the eventstream, copied the values and used it for the action change node.

I don’t use payloads for lamps. I only trigger Scenes for every light setup, cause my motion sensors do this as well. Next to the lights I mentioned before, I have have 2 desk lamps, that need to be turned on individually. Disable / Enable these is just setup once so payloads are not needed in my opinion.

States in NodeRed are not necessary for me, as I dont control my lights through it. I have wall switches and motion sensors. If I would need a persistent State, I would write it in context, reading it from the Event Flow. i have one lamp where I am doing this, cause I need the previous color, when I used the alarm function.

For a quicker overall response (especially the initial_press for button) and no dependence on a contrib i like the repository I built, but everyone can decide by themselve what is considered to be more useful

My setup is 2 Bridges, 45-50 lamps and plugs, 6 motion sensors and 7 Buttons now. And if I had the recourses from my contrib, before I set it up in this way, it would be only 1.5 hours setup. When I did it first, it almost took me 8-10 hours. :D

Greetings Andreas

[andesse]

@djiwondee For the single lamps mentioned I am just using a toggle node, that get the state from the api and the switch (I use an nfc) my flow looks like that. So the toggle node represents the state of the lamp. Just reminded that lol