Error requesting from the bridge #350
Comments
|
same here on 4.2.1 but just installed hue-magic 4.2.2 testing now |
|
I am seeing same issue with hue-magic 4.2.2 |
|
Hi guys, |
|
hi i have but from yesterday after update to 4.2.2 i cant see any request problem in my logs |
|
Node RED: 2.2.2 I still see it after 4.2.2 |
|
@tocDK: so, you don't know about your npm or node version? |
|
@ptweety still new to HomeAssistant. Just trying to figure out where I can see that |
|
Hm, maybe you are using a docker for Node-Red: |
|
Same problem here |
|
Hi again, I've tried to reproduce the behavior on my side, but wasn't able to ... At least the first line in your logs that reads:
showed, that there is no actual response object coming back from the api call to the bridge. This little You can try to apply this patch #349 and see, if you get more information in your logs. If someone of you is able to spin up a local Node-Red instance with node-red-contrib-huemagic installed and generate some more debug logs that might also be helpful. |
|
Hi all, i have the Versions:
After the update hue node 4.2.2 (5 hours ago) the log is clear, the group / light node works in universal mode fine. Also to all again many thanks for the corrections and the associated effort. If there are still problems in the next 24 hours, I will send the debug log. |
|
So Very weird, I applied the pull request to change the catch and now seems to be working much better , No errors thrown I'll leave it running and see how it goes |
|
I am also having this issue: Maybe this is related |
8 hours later I get the same problem, with no difference in the log (ie the messages are the same, the change to api.js does not appear to have changed this) `25 Mar 08:10:29 - [warn] [yeelight-config:192.168.1.115:55443] [Yeelight-Config][onError][Error] Error: read ECONNRESET retrying 25 Mar 08:11:46 - [info] [hue-bridge:Philips hue] Error requesting info from the bridge. Reconnect in some secs. undefined 25 Mar 08:11:46 - [info] [hue-bridge:Philips hue] Initializing the bridge (192.168.1.147)… |
|
Ok I am trying the suggestion in Will report back |
|
Hi again, I still have a problem with the hue group node. Unfortunately, so far I can not see how to reproduce the behavior. In the following scenarios I have the problem with the hue group node: Hue scenes are switched automatically by sensors or manually a push button via a hue scene node in universal mode. If the corresponding Hue scene must/should be switched off, this is done via a hue group. Again, the trigger is a sensor or a switch. The corresponding group ID is passed as a string in msg.topic together with the settings. The problem is that the group is not always switched off. Attached is a message object for the hue group node and an excerpt from the log The last log entry should have turned off the group by a sensor. But it did not happen. |
|
Hi again, one more item. I know that there is a property in the msg object in the payload that is not meant for the HUE. I just sent the same msg directly to the bridge with a http node. I get the following payload back: In the response there are two objects in the payload, one with the error unknown ... and in the second object a success. The light was also switched off. Is the unknown property possibly the culprit? |
|
Did not work......sigh I have a test environment running on docker ....if anyone wants to suggest adding debug statements, I'd be happy to try it.....seems to be fairly intermittent though so will take time to actually get results |
@davidcreager i have all the same issues and it drives me crazy. I tried to send http requests, but I can't get it running. I used the Rest App in iOS to discover the key, but I didn't got the header in node red running. Can you share a flow to me that I can use http requests, please? It should be the function node for the header and the http request one, right? Greetings |
|
Hi again, after a certain time the bridge does not run stable anymore and log entries with the already known entries occur more and more often. In my case, this happens after the hue group node has often turned off some groups (in my case only rooms). With under then also the group node seems to hang or it is turned off nothing more. However, there are no problems with the hue scene node. I have then tried the way via a direct http connection via API v1 and API v2. I noticed the following points for which I have no explanation: First I started with an http request for the HUE API V1 REQUEST FOR ROOM ESSZIMMER RESPONSE OK REQUEST FOR ROOM KUECHE RESPONSE ERROR - WHY So far I had used the room id for the request. This did not work for the kitchen room. So I tried the id_v1. REQUEST FOR ROOM KUECHE REPONSE OK. In fact, I have no idea what value is expected from the Bridge API V1. I tested this for all other rooms. Except for the kitchen, I was able to use the id and the id_v1 for all other rooms. I started with the id because it is also displayed in the hue group node. But the error for the kitchen room "resource /groups/4747c001-1fbb-46ee-b8a4-461e909401ff/action, not available" is not clear to me. Which value / ID is used in the HUE group node ? Last but not least I tried the http request with the hue api v2. Here everything went basically very well, after a restart of the Hue bridge there were no further problems. After that also the strange LOG entries were there again. REQUEST V2 RESPONSE OK In another response I had two entries in the payload. This was preceded by a change of different scenes in the same room. In the last scene also not all lamps were used Unfortunately, I have no experience with the HUE API. but already the change from v1 to v2 seems very complex to me with HUE. Furthermore, I have that. Problem only with the hue group node. It feels like the HUE Bridge is not coping properly with the id for the v1. Dahe would be very interested in what id the hue node uses. Have a nice evening |
Hi, this is my flow to test some http request to hue api v1 and hie api v2.
|
|
@ralfhille Thank you so much for sharing! I think I'll just use this in the future and the philipshue-events for status updates. Due I have a account on Hue developers I can solve problems in no-time by myself. That was my plan all the time, I just couldn't create the header. To create the context for the https node like that is a really cool idea! |
|
@ralfhille: I lost track with which direction you are going for. But whatever. One comment regarding your flow: you don't need this extra https-node but can (and should) use the build-in |
@ptweety |
|
you can configure the built-in |
|
@ptweety cool thanks for the hint! |
|
Same Problem |
Hi @ptweety, until the update of the HUE Bridge, everything was actually fine. After that there were just some problems with the hue-nodes. After that, it was actually only to find out where the problem is and why the combination HUE Bridge and node-red HUE nodes no longer ran cleanly. So if everything is good again, I go the way of the hue-nodes, clear advantage a large community with which I can exchange. By the way, this also applies to all other node-red nodes. Maybe finally the hint to all who have a problem to update to the node-red version 2.2.1. I found some duplicate wires in my nodes. More information about this BUG https://github.com/node-red/node-red/releases/tag/2.2.1 |
Is your implementation of Huemagic stable? Are you running Node-red on docker? |
i have the same problem that appears some times and i'm not in Docker |
|
Thanks so much for letting me know, I was dreading trying to set this test up |
|
are you familiar with |
|
Ooh. That sounds interesting. I will have a look |
|
@davidcreager: Just get |
|
Wow thanks.....appreciate the help |
|
I too have this problem and basically makes HueMagic unusable. I've tried downgrading the npm package by simply entering the container and npm install node-red-contrib-huemagic@4.2.1 I think that downgraded it but now I have other weird problems where flows don't seem te be processed properly anymore and I'm wondering if there is some error introduced in my flow or it's HueMagic that is broken. Now trashing the container and starting fresh, but would like to get pointers. When it works it's great, so much faster than other things I've tried. |
|
@sanderboele i highly recommend using direct https requests to the bridge. Works flawless, just the Hue event contrib needed. (It would work without it too, using a http node for the event stream, but more convenient) |
|
thank you @andesse I will check this out |
Hi, I use the node-red server side event node. You find a sample to start and stop the server side event communication. It works perfectly with the hue bridge. |
|
For me as a beginner and just learning to understand how node-red works, it's much easier to understand HueMagic. I use events for example to detect a button push on a friends-of-hue switch and it's real easy to just drag in lights, groups, scenes and everything well documented so I can create something in little time that just works! It would take me days to figure out how to pull all data I need from the bridge and to everything from http event streams, or am I missing something trivial here?
example of what I'm doing now. This is Dutch language btw 👍 |
Feel happy, I can only share your opinion and I have also used the hue node for a relatively long time. But after an update on the hue bridge, I had massive problems with the hue node. But since I only turn lights on and off or set scenes, I decided for the moment to solve it via http request and server side events. |
|
@sanderboele you are absolutely right about that, it's a convenient contrib. Managing everything trough https took me a whole day to setup. Seeing your flow makes me want to share a hint. When you trigger 2 lamps/ groups simultaneously, add a one second delay to the second one. It will help the bridge not struggling with too many requests at once. The official Hue api Guide says, not more than one group request in a second. |
|
Thanks for the tip @andesse I will add this delay and hope huemagic is fixed soon so my family doesn't kick me out of the house |
@ralfhille i keep that one in mind, thanks. |
|
I installed the same stuff but now in my mac mini m1, also just the standard container from docker hub, but now I get some interesting stuff: I'm hoping to have fixed the issue by copying api.js straight to the container. In hindsight I could have understood this from the thread, but I didn't :( I now created a crontab that restarts node-red then my stuff kinda works |
|
instead of restarting every 9 minutes, I now wrote a tiny and crude monitoring script #! /usr/bin/env python
from sh import tail
from sh import docker
errorMessage = "Error requesting info from the bridge"
for line in tail("-f", "/data/docker/docker-data/containers/9abf662a938852f09c5cd925cf812b50ea95eb2dccaed8e1db46527f21a0a471/9abf662a938852f09c5cd925cf812b50ea95eb2dccaed8e1db46527f21a0a471-json.log",_iter=True):
print(line)
if errorMessage in line:
print("restarting container...")
docker("container", "restart", "nodered_node-red_1") |
|
@sanderboele just change to https requests. The HUE api has changes on every bridge firmware release, HueMagic might cannot keep up so fast with updates. But using the standard V2 commands for lights / groups / motion / button endpoints just works great. If you need help to setup a flow, I can help out. |
|
@andesse I'd rather fix the code than go through this tedious process of
figuring out all ID's and how exactly to interact with them through http. I
looked into it and I managed to turn a light on and off, but frankly I'd
rather go do something else :P
My container has pretty long uptimes (I've had more than 24hrs), so the
problem doesn't occur very often and it often happens a couple of minutes
after I deploy a change on node-red. My script now immediately restarts the
container and you don't notice it as it happens quickly. This behaviour
leads me to believe it may be some kind of rate limit on the bridge. Before
I completely move away from HueMagic an go through the motions of deploying
with plain http it has to fail in a more dramatic way
…On Fri, May 20, 2022 at 6:37 PM andesse ***@***.***> wrote:
@sanderboele <https://github.com/sanderboele> just change to https
requests. The HUE api has changes on every bridge firmware release,
HueMagic might cannot keep up so fast with updates. But using the standard
V2 commands for lights / groups / motion / button endpoints just works
great. If you need help to setup a flow, I can.
—
Reply to this email directly, view it on GitHub
<#350 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAC5HKQ7QG46VRTEO4EMYXDVK65VVANCNFSM5RKHKHDQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@sanderboele "We can’t send commands to the lights too fast. If you stick to around 10 commands per second to the /light resource as maximum you should be fine. For /grouped_light commands you should keep to a maximum of 1 per second. The REST API should not be used to send a continuous stream of fast light updates for an extended period of time, for that use case you should use the dedicated Hue Entertainment Streaming API." In my https setup I don't use single lights, just use different scenes for rooms that are for daytime / evening / night & morning. As I have an apartment with 5 rooms, so around 15-20 scenes. |
I've managed to figure out how to do everything except how to enable and disable my motion sensors. Any tips would be greatly appreciated. |
|
Find out your motion sensor endpoint Id and do it like this |
|
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 |
|
This is great! Thank you!!! |
|
This issue persists with intermittent operation of Node Red with HUE From Node-Red logs on restart11 Aug 08:37:03 - [info] Node-RED version: v3.0.2 Stream of errors - log level set to TRACE11 Aug 08:33:31 - [info] [hue-bridge:Philips hue] Connected to bridge |
|
@isaac-the-newt come to me :) |
|
Hi Andreas,
Thanks for your offer to assist with working around the issues with HUEMAGIC.
I’ve had a look at the files from your GitHub repository and decided I would resolve this issue via an alternate method.
I have been able to remove HUEMAGIC completely from my system and insert functionally equivalent I/O interfaces to the HUE system using Node-RED blocks from the Home Assistant core library for Node-RED.
I’ve added some simple one-line automation scripts within Home Assistant core to replicate the TAP switch and other HUE button sensor inputs and everything is working reliably.
I exported my previous HUEMAGIC flows for posterity should that project ever get resolved and stable.
HUEMAGIC offered great integration opportunities but was not reliable and I spent many, many months trying to understand if my issues were caused by Wi-Fi interference, or access point placement, or other networking issues.
At this time, everything is solid. 😊
Thanks again for your support of the HUE user community.
regards,
Greg Belcher
From: Andreas ***@***.***>
Sent: Thursday, 11 August 2022 15:54
To: Foddy/node-red-contrib-huemagic ***@***.***>
Cc: isaac-the-newt ***@***.***>; Mention ***@***.***>
Subject: Re: [Foddy/node-red-contrib-huemagic] Error requesting from the bridge (Issue #350)
@isaac-the-newt <https://github.com/isaac-the-newt> come to me :)
—
Reply to this email directly, <#350 (comment)> view it on GitHub, or <https://github.com/notifications/unsubscribe-auth/AWY7QEZBWPLCCSEUQSHYLXTVYSIRBANCNFSM5RKHKHDQ> unsubscribe.
You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AWY7QE5KPWT2N55LWV7EAZLVYSIRBA5CNFSM5RKHKHD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOJA3TJOA.gif> Message ID: ***@***.***>
|
|
@isaac-the-newt Thanks! nice that it worked out like that for you. Is HA offering the whole API V2 Integration, or are parts still relying on V1? Greetings |
|
Hi Andreas,
V2 with legacy support for V1.
regards,
Greg Belcher
From: Andreas ***@***.***>
Sent: Monday, 15 August 2022 15:19
To: Foddy/node-red-contrib-huemagic ***@***.***>
Cc: isaac-the-newt ***@***.***>; Mention ***@***.***>
Subject: Re: [Foddy/node-red-contrib-huemagic] Error requesting from the bridge (Issue #350)
@isaac-the-newt <https://github.com/isaac-the-newt> Thanks! nice that it worked out like that for you. Is HA offering the whole API V2 Integration, or are parts still relying on V1?
Greetings
Andreas
—
Reply to this email directly, <#350 (comment)> view it on GitHub, or <https://github.com/notifications/unsubscribe-auth/AWY7QE24SAY5BGCXXPHDFSLVZHHMTANCNFSM5RKHKHDQ> unsubscribe.
You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AWY7QEZ2XWITGBXWXBVCXODVZHHMTA5CNFSM5RKHKHD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOJBS4DYA.gif> Message ID: ***@***.***>
|
After the update I get the following entries in the node-red log:
HUE Bridge Version BSB002 / 1.50.1950111030
Node Red Version 2.2.0
All scenes and/or lamps can only be switched sporadically.
Is it now a mistake or did I go about it the wrong way?
The previous version with the workaround worked stable for me. Whereby I use exclusively the switching of scenes and groups.
The text was updated successfully, but these errors were encountered: