Open NodeRedFan opened 2 years ago
The "update" comes from the bridge API V2 and just means there is a "status update" (on/off/color/brightness/etc...) from a device.
@NodeRedFan if it's not working for you, just use the Philips-events node and switch the data for the response you need. It's a workaround but works great.
Well, the thing is that the whole "Hue Bridge" seems to jam, if it occurs on one of the lights. So once the situation jams, no more updates follow from the Bridge API V2 either.
I have the impression that it occurs after I set a light (again) to a previous value. So entering "true" when the light was already on, or "false" when it was already off... Now trying it with a toggle, and that seems to hold longer.
@andesse Even stranger actually - when the Bridge blocks for one light, I can still switch another light (but only 1x) before that blocks as well...
@NodeRedFan i have only ONE situation in my setup where I control two lights. And that's the bed-lamps of my wife and me, that can turned off separately with a switch. In all other cases I just trigger scenes. Can recommend for a zero-issue setup.
@andess - Using Scenes and Groups (to turn off) now, and that seems to be more stable indeed.
Still hoping to get the lights "fixed" in one of the following releases, of course. But hey, that's the thing about "bleeding-edge" releases :)
Cool that it works for you. I actually turn off whole groups.
Andreas
Am 22.03.2022 um 09:39 schrieb NodeRedFan @.***>:
@Andess - Using Scenes and Groups (to turn off) now, and that seems to be more stable indeed.
Still hoping to get the lights "fixed" in one of the following releases, of course. But hey, that's the thing about "bleeding-edge" releases :)
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
Hello all, with me it is exactly the same behavior (unfortunately). Currently, I have been able to reproduce the behavior with a wireless socket (from Osram) and with one from (Ikea / Tradfri). But it does not work with the original philips lamps as well. But controlling the sockets or lamps from the HUE-App (Android) works well.
Nodered: v2.2.2 HueMagic: v4.4.2
best regards, Ulf
Happens here too, on a single light bulb, reproducible within seconds. Gets stuck and doesn't accept any commands anymore until redeploy.
Removed huemagic and doing the command with FHEM now, which does it with no issues.
Fresh install, also have this issue. Locks up after just few cycles. Nodered: v2.2.2 HueMagic: v4.2.2
@Furrypaw delete HueMagic, make your own https requests. Problem solved.
Can confirm this issue as well
Here my repository for https HUE API V2. It's just a flow with everything you need. https://github.com/andesse/node-red-hue-api.v2-flows
Unfortunately, I got tired of waiting. I just stopped using this plugin and went straight to http call. It's super easy. https://developers.meethue.com/develop/get-started-2/#follow-3-easy-steps
Unfortunately, I got tired of waiting. I just stopped using this plugin and went straight to http call. It's super easy. https://developers.meethue.com/develop/get-started-2/#follow-3-easy-steps
@smistrydev that is what my flow is using, just api v2 and not v1. V1 will be depreciated soon.
Same problem here!
I solved it by moving two versions back via:
cd ~/.node-red npm uninstall node-red-contrib-huemagic@4.2.2 npm install node-red-contrib-huemagic@4.1.0
(tested with 4.2.2 and 4.2.1 = stuck!)
The issue seems to be related to #315
I have the same issue
I have the same issue
@Orochica just use my flow example as recommended and you’ll never have any issue again. Thank me later. :)
@andesse I thank you now ;-) I step back from huemagic and took your route .. Nice move
@andesse I thank you now ;-) I step back from huemagic and took your route .. Nice move
@jemmail it felt just so necessary haha. Thanks for feedback
Same bug here. Now trying to use a new node or create my own http requests as suggested. :( RIP Huemagic
Now observing if anyone forks this amazing project to not allow it die.
@toaster-code you are welcome to join my repository and happy Hue users Don’t waste time for other contrib. Http will be stable
@toaster-code you are welcome to join my repository and happy Hue users Don’t waste time for other contrib. Http will be stable
Thanks. In fact I am right now reading your instructions. Very nice work by the way.
The thing is I miss having a "plug-and-play" solution. That is why I loved Huemagic. Nothing else to do except get a token, setup the Huebridge and think about my switches, lamps, groups and sensors, filtering by their UUID.
I am reading your docs and it seems that users need to learn and be cautious before using your work. I really liked to have everything hidden under the hood of HueMagic and as I understand the low level logic stays visible as flows. I will give it a try and give my feedback.
Thank you.
@toaster-code just don’t deploy without yadomi contrib. That’s all. The helper flow let you easy determine all Id and rid. You will be amazed how quick the responses are
just follow the link already sent and send HTTP requests with two nodes (just need to tweak the URL adresses to decide what to do)
to see your lamps:
[ { "id": "0f48caf49ebb9409", "type": "http request", "z": "a90cb775b4fe69cd", "name": "Status HUE", "method": "GET", "ret": "obj", "paytoqs": "ignore", "url": "http://xxx.xxx.xxx.xxx/api/YOURAPICODE/lights", "tls": "", "persist": false, "proxy": "", "authType": "", "senderr": false, "credentials": { "user": "", "password": "" }, "x": 390, "y": 120, "wires": [ [ "d617ea837ef0b097", "ccf71e81eac3effa" ] ] }, { "id": "9e11b35a2bdd0b08", "type": "inject", "z": "a90cb775b4fe69cd", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "", "payloadType": "date", "x": 190, "y": 120, "wires": [ [ "0f48caf49ebb9409" ] ] }, { "id": "d617ea837ef0b097", "type": "debug", "z": "a90cb775b4fe69cd", "name": "", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "false", "statusVal": "", "statusType": "auto", "x": 600, "y": 120, "wires": [] }, { "id": "ccf71e81eac3effa", "type": "debug", "z": "a90cb775b4fe69cd", "name": "", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload[\"7\"].state.on", "targetType": "msg", "statusVal": "", "statusType": "auto", "x": 630, "y": 180, "wires": [] } ]
and to send a command for example colortemperature to 2700 to lamp 12: (please note you have to send the number ct=1000000/ColorTemperature)
[ { "id": "5e09b7f927ee57c9", "type": "function", "z": "a90cb775b4fe69cd", "name": "Colore 2700", "func": "msg.headers = {}\nmsg.method = \"PUT\"\nmsg.url = \"http://xxx.xxx.xxx.xxx/api/YOURAPICODE/lights/12/state\" ;\nmsg.headers[\"content-type\"] = \"application/json\"\n\n\nmsg.payload = {\n\"on\":true,\n\"ct\": 370,\n};\n\nreturn msg", "outputs": 1, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 350, "y": 340, "wires": [ [ "439aef07606fff5f" ] ] }, { "id": "439aef07606fff5f", "type": "http request", "z": "a90cb775b4fe69cd", "name": "", "method": "use", "ret": "obj", "paytoqs": "ignore", "url": "", "tls": "", "persist": false, "proxy": "", "authType": "", "senderr": false, "credentials": {}, "x": 550, "y": 340, "wires": [ [ "42017a7c91d5893c" ] ] }, { "id": "658b602c2d2c1c55", "type": "inject", "z": "a90cb775b4fe69cd", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "", "payloadType": "date", "x": 140, "y": 340, "wires": [ [ "5e09b7f927ee57c9" ] ] }, { "id": "42017a7c91d5893c", "type": "debug", "z": "a90cb775b4fe69cd", "name": "", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "false", "statusVal": "", "statusType": "auto", "x": 730, "y": 340, "wires": [] } ]
I had the same issue here, I simply moved my raspberry pi close to my router, and that solved the problem. It seems that network delay can cause that
I had the same issue here, I simply moved my raspberry pi close to my router, and that solved the problem. It seems that network delay can cause that
In my case I had VM and and hue bridge connected to same router. The delay should be negligible. Issue was still present.
@Furrypaw @ismaia just use my repo, it is maintenance free and just needs a bit more time to setup. https://github.com/andesse/node-red-hue-api.v2-flows
This bug still exists and I have it. Make is useless. I needed to reinstall my rasp with all smart home and now stuck with this bug.
Node-RED version: v4.0.2 Node.js version: v20.16.0 HueMagic version: 4.2.2
This bug still exists and I have it. Make is useless. I needed to reinstall my rasp with all smart home and now stuck with this bug.
Node-RED version: v4.0.2
Node.js version: v20.16.0
HueMagic version: 4.2.2
@adis1987
Please use my respository and you will never have a Problem again. It is easy to setup, just follow the step by step instructions.
https://github.com/andesse/node-red-hue-api.v2-flows
Greetings Andreas
Did a fresh install of HueMagic 4.1.2 (my last version was 3.0.0), on the latest Raspbian Bullseye (today, March 21st, 2022).
I noticed that my Hue Lights get stuck in the "executing command" status, after working correctly for one ON/OFF cycle.![image](https://user-images.githubusercontent.com/102041918/159280049-ea83df45-c9b7-421e-96f2-d0f734b20470.png)
When trying to troubleshoot with the "philipshue-events" node, the output is this (every second)![image](https://user-images.githubusercontent.com/102041918/159280264-34e19015-8569-4741-bf30-603fcbed8269.png)
Seems like node-red is trying to update the Bridge, but it doesn't seem to be working. When doing a new deploy in node-red, issue is (temporarily) solved, until the next on/off cycle.
Is anyone experiencing the same issue? I can reproduce with any simple flow, using a HueMagic Light.
HueMagic version; 4.2.1 Hue Bridge version; BSB002 / 1.50.1950111030