-
-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ESOCKETTIMEDOUT and ETIMEDOUT #15
Comments
Hi @deanlyoung, The first series of errors are network errors, timeouts homebridge-hue gets when trying to communicate with the hue bridge. Typically these network timeouts happen when the network connection to the hue bridge is poor, or when the bridge is too busy. If you run As to your second question: homekit defines the power or On characteristic as a Boolean, but uses values 0 and 1 instead of false and true. To wit, if you switch off power from the iOS 10 Home app, you see a log message "homekit power changed from 1 to 0". However some Homekit applications use false and true instead of 0 and 1, and instead you would see "homekit power changed from 1 to false" in the log. Long story short: don't worry about this. I'll see if I can suppress the messages in a future release. Regards, |
Thanks for the reply, @ebaauw! I'll look into the logs some more and try out your timeout suggestion. I have my RPi connected via Ethernet. |
Running
On mobile, so I couldn't figure out how to copy the logs from my terminal app, but here are some screenshots of the errors when attempting to update I could be wrong, but it looks like updating certain aspects of the lights aren't being executed in the correct order. So for example, the current state (on/off) should be checked, if "off" → "on", and then change other values, like brightness/hue/saturation. |
Hi Dean, @deanlyoung Hmm, I think that first error is thrown by homebridge itself, not by homebridge-hue. I think 51826 is the port you masked from your config.json. On startup, homebridge creates at web server at that port, for your iOS devices to connect and interact with the homebridge bridge accessory. EADDRINUSE means homebridge cannot create this web server, because the port is already used by another program. Are you running multiple instances of homebridge? I'm a bit puzzled by the logs from the first screenshot. It looks like you switched light 3 on from homekit (that message should have appeared just before these), and homebridge-hue sends a put of /lights/3/state to the hue bridge to mirror that change. However that doesn't seem to reach the bridge, due to a connection reset error. Then the bridge justly complains that it cannot change the brightness nor colour, as the light is still off. Now, there's more going on, the communication error occurs twice, so another command to the bridge has failed as well. That's the joy of asynchronous I/O: the error message doesn't necessarily apply to the latest communication attempt. I really need more of the logs. Could you start homebridge -D > logfile.log 2>&1 to capture the logs? You can still monitor the logs by tail -f logfile.log from another terminal session. The logs from the second screenshot look fine to me. Homebridge-hue does a get /lights to receive the updated light states from the hue bridge and then sets the homekit characteristics to match any changes. |
Hi Dean, @deanlyoung Nice lamps! The logfile is very insightful, thanks. When activating a homekit scene, the homekit app sends an event to homebridge-hue for each characteristic in the scene. That's three characteristics for each light (brightness, hue, and saturation, even though the app might show them as one colour). On each event, homebridge-hue checks whether the characteristic value has changed and if so, issues a put request to the hue bridge. By design, homebridge-hue sends these requests asynchronously, that is, it doesn't wait for the response from the hue bridge, but continues handling the next event. Consequently, the hue bridge receives the next request(s) when it's still processing the previous one(s). I've done some testing on my old gen1 bridge, and I consistently get ECONNRESET when the homekit scene contains 8 characteristics. With 7 characteristics, everything works fine. With three lights times three characteristics, the math doesn't really work in our favour. So what could we do about this (short from upgrading to a gen2 bridge)?
Please let me know what you think. 4 is probably easiest and quickest to implement, if you're comfortable typing json by hand. Implementing 1 or 2 would be relatively easy for me, but I'd rather focus on the dynamic accessory model (and issue #16). I do think I should implement 2 eventually anyway, probably making the number of parallel requests a config parameter. |
I stand corrected: 1 was easiest to implement, just published version 0.0.12. @deanlyoung could you see if that version solves this issue for you? |
One more thing, @deanlyoung , I wouldn't worry about the other plugins. Once every 20-30 seconds is peanuts compared to the load to the hue bridge. For something completely different: how about creating a CLIPTemperature and a CLIPHumidity sensor on the hue bridge? Homebridge-hue exposes these CLIP sensors to homekit. These could then be updated periodically from Wunderground from a cron job. This job would be a simple script doing an http get on wunderground.com, extracting the temperature and humidity values from the response, and two http puts to send these values the hue bridge. No need for an additional homebridge plug-in. |
@ebaauw it's definitely more stable, but that "It's getting late" scene is being really stubborn. I forgot to mention that that scene does in fact control more than just the 3 hue color lights. It also turns every other light off connected to the bridge, so 5 others, in addition to controlling the 3 color ones, 8 total. However, when I remove control of all other lights (except turning off an additional bedroom light) it still performs the same way. It just doesn't show the ECONNRESET now in the logs, which is a step in the right direction! Another upside is that the other scenes seem to work properly now and show up highlighted in the Home app after tapping them. Yay! (whereas, the "It's getting late" scene highlights, then un-highlights when it realizes the scene hasn't actually finished) Unfortunately, I can't seem to get I've also noticed, maybe anecdotally, that only the "Tall" light is usually the one that doesn't turn red, but tapping the scene again eventually gets it to change, and yet still no recognition by the Home app that it's in fact completing the scene now. Anyway, that's all to say that I think I can live with it the way it is now, versus the extra effort/debugging/development it would take to track down the issue more. Happy to keep trying things, but I don't want to waste too much of your time :) THANK YOU! As for the other plugins, I was mistaken. 20-30 seconds was actually how often I was going back into the Home app while testing, and the Edit: @ebaauw sorry, I missed a lot of your earlier comment above the most recent 2! which I only picked up on after seeing your comment on #16... That's a huge insight about the difference between Gen1 and Gen2. Totally makes it seem like there is more value in upgrading (I thought it was mostly a hardware encryption limitation to be HomeKit Siri compatible, but I suppose an added benefit is more processing capability). I'll explore the json route from 4 above. I'm pretty comfortable with json, but if I get hung up, I have some other apps that might work. |
Hi Dean, @deanlyoung I find homekit sometimes reverts changes I make to scenes or rules when syncing with my other devices over iCloud. I'd double check that the changes to the getting late scene have been propagated to your other devices. I now log a debug message on ECONNRESET, so you would only see it with homebridge -D. I tested with 16 characteristics in a scene. Some updates actually cause an ECONNRESET on the first retry as well, but eventually work on the second retry. The CLIP sensors on the hue bridge aren't real sensors, they're more like variables where you can store sensor output. So instead of exposing the data to the web, your Python script would do an http put to the hue bridge to update the CLIP sensor value. |
Ah, gotcha! I'm currently reading through the Hue API documentation. Really good stuff! edit: @ebaauw Wow! I'm really liking the Hue API. Thanks for the tip on updating sensors locally! |
Hi @ebaauw ! Thank you for all the work you've done on this hue homebridge plugin. I too ran into the ECONNRESET issue and worked on a solution locally. I'm running a Hue 1st Gen bridge and noticed that error appeared when I loaded a scene that required many API calls (turn on, set brightness, set color, etc. on 5-6 lights). When I googled the error, I found information about a limitation in 1st Gen bridges: http://www.developers.meethue.com/faq-page
My solution was to write a request cache loop that makes a maximum N requests per T milliseconds, repeating until the cache is empty. When I set it to 10 requests per 1000 milliseconds, I still got errors, though fewer of them. Through trial and error I found that 5 requests per second works reliably on my setup. The only time I still have failures is when a change request is made on a light that is in the off state (ex: requesting set brightness to 30% when light is off). The Hue bridge complains about an invalid API request in those situations. I didn't realize that you were also working on the problem (though was happy to see an open source project that was so active). The changes I made were to version 0.0.11 and was planning to incorporate them in version 0.0.12 with the 300ms request retry. Would you be interested in reviewing my changes? I could fork your project and submit a PR. |
btw, @ebaauw (and @fedhat) it seems that by hardcoding a group for my three color lights via Hue's API, I was able to fully solve this issue. The transitions are much faster and I haven't seen an issue yet. @ebaauw, I'm not sure if you want to leave this issue open in light of that insight you gave me, but maybe there are some refinements to the module you want to take note of. We discussed a lot... :) Thanks again! |
Hi @fedhat, Yes, I know that FAQ. It refers to the limitations of the Zigbee network, the Hue bridge sending commands to the lights; the ECONNRESET is a limitation on the IP side, homebridge-hue sending requests to the Hue bridge. On that side, a PUT /group is just as resource intensive as a PUT /light; on the Zigbee network, a group command is a broadcast, whereas a single light command is a unicast, hence the difference in number of requests between lights and groups. Also note that the bridge caches the light states, to a GET /lights wouldn't even result in any Zigbee traffic. The IP problem is not so much the number of requests per second, but the number of parallel requests. As homebridge-hue sends requests to the Hue bridge asynchronously, the bridge receives the next request before it has responded to the previous. The 1st Gen bridge cannot seem to handle more that 6 open requests. Consequently, we need to limit the number of open requests to the bridge (option 2 in my earlier comment), rather than the rate of these requests. As all requests go through |
That's good to hear, @deanlyoung. I'll keep the issue open, until I have implemented the limit on number of open requests. |
Thank you, @ebaauw. I didn't realize that the FAQ referred to the limitation of the Zigbee network, nor that the actual limitation of the 1st Gen bridge is the number of open requests. For my own edification, I'll update the request cache system I added to account for open requests, rather than requests per second. My modifications are built around @deanlyoung thank you as well. I'll keep that in mind. |
@ebaauw (and @deanlyoung in case you're curious) |
I get a this at least once a day, seems to resolve itself (after one hour, looking at the logs):
This is the pattern, which is repeating every [heartbeat] seconds. |
Hi Joost, @jojost1 Please ignore the The ETIMEDOUT and EHOSTDOWN errors indicate that homebridge-hue cannot connect to the Hue bridge, typically because the Hue bridge or the network connection the Hue bridge is down. It's generated on every communication attempt with the Hue bridge, which is every heartbeat seconds when homebridge-hue polls the Hue bridge. What type of server do you run homebridge on? Is this server connected to the network by wire or by WiFi? What is your home bridge configuration? What is your Hue bridge config? |
Running it on an iMac, connected by wire. Homebridge-hue settings in config are all default. Unrelated question: There is no way to hide the hue-bridge and/or daylight sensor right? Kind of useless for those to be there ;-) |
Could it be related to the iMac sort of sleeping and suspending its network interface? No, there isn't. I don't think they're useless. The bridge accessory will be used to persist the bridge username, so you wouldn't need to edit config.json to add it manually, once I'll have moved to dynamic platform accessories (see issue #4). Currently, it supports dumping the bridge state on Identify for troubleshooting. The daylight sensor accessory could be used for HomeKit rules in other apps than the iOS Home app. There should probably be a way to suppress it, see issue #7. Are you running into the 99 bridged accessories limit? Otherwise, just create a dummy room in HomeKit and move all the accessories you don't use there (including the accessory for homebridge itself). Be sure to unmark them as favourite. |
For the other issue: thanks for the info!
Nope don't have +99 accessories, I already unmarked them and made a separate room. Thanks! |
The undefined errors should not longer appear as of v0.1.16. |
i'm also receiving this message often on every heart beat currently set to 5 seconds. |
@pponce You don't get any EHOSTDOWN errors? My best guess is hiccups in your WiFi network. Do you see lost packets when you do a Do you also get these errors when connecting the homebridge server by wire instead of over WiFi? When only using the homebridge-hue plugin? If so, than please attach a full debug log and your config.json here. See Troubleshooting in the README. |
Indeed, that's not a Philips Hue bridge ID. It's derived from the Mac address of your Raspberry Pi, courtesy of HA-Bridge, I assume. Where did that username come from? Did you (do the equivalent of) press(ing) the link button on HA-Bridge at homebridge-hue's request?
Version 0.1.10 supports multiple values for |
Tested 0.1.10. seems to work. Now just getting the HA-bridge errors. |
My issue with ETIMEDOUT errors i believe has resolved. |
@pponce that's an interesting point about connecting via powerline. I have my RPi connected to the router via powerline (as opposed to wireless, which is flakey on a 2B with a USB wifi stick), and my bridge connected directly. I wonder if I'm getting the |
I bet it's the powerline. I decided to connect everything (pi3 and hue hub) direct to the router and the timeout went away. I had originally been running wifi on pi3 and powerline to philips hub. I had the timeout issues like crazy. Once i hooked it all up direct i was able to do the 2 second heartbeat with no timeout issues. |
@pponce I can edit: after the longest period without an |
I've also had luck improving homekit related networking issues by turning on IGMP proxy and IGMP snooping on my router if you have those options (for each wireless radio and for lan). |
I double checked the documentation and code of
For all these errors, home bridge-hue was able to open a network connection to the Hue bridge, but received no timely response. You could try and increase To check for network problems, you could try ping or curl as I described above. Wired ethernet is more reliable than Wifi or powerline. In my experience, powerline is more reliable than Wifi, but your mileage may vary. I started out retrieving the full bridge state on each heartbeat (with a single request |
v0.3.5 again does separate requests per resource type on heartbeat. |
Finally, homebridge-hue v0.3.7 throttles requests to the Hue bridge, see point 2 in #15 (comment). homebridge-hue will issue maximum 3 requests in parallel to a v1 (round) bridge, and maximum 10 parallel requests to a v2 (square) bridge. This can be changed in @pponce, @deanlyoung, this is all I can think off to improve homebridge-hue's performance. Please let me know if you see any improvements. |
My issues were almost completely solved by not using WiFi or power-line, instead hooking up direct via ethernet. |
Thanks, @pponce.
IGMP snooping is a technique for a network router/switch to reduce the network traffic to hosts that do not need multicast traffic, used e.g. for IPTV, but also for UPnP. Basically, a multicast server sends messages to a special broadcast address per service (e.g. 239.255.255.250 for UPnP). Without IGMP snooping, hosts (the Hue bridge, your RaspPi running homebridge) filter out the multicast messages they don't need, but that costs some network-related processing. With IGMP snooping, the router/switch forwards the multicast messages only to ports connected to a host that actually wants them, reducing the network traffic on the other ports.
Yes they do. Additionally, the Hue app or some other app for the Hue bridge might have created CLIP sensors working in conjunction with the rules for these switches. |
@ebaauw as always, you da man! I'm installing now and will keep an eye on performance. Really helps that you walked us through the technical aspects of all this, too. I certainly learned some things and can understand how to better optimize my setup because of that., and not just think "I don't know why it works, but it works". The biggest thing was understanding how power-line sends all requests through the same port. Even before the latest updates, I can still say that performance was drastically improved by connecting the RPi running Homebridge directly to the router improved speed and reliability. Most noticeable with changing multiple lights' hue/saturation/brightness at the same time. Before, I'd have to trigger a Scene 3 times to get the lights to change "all the way" (i.e. usually only one light, or one state would take effect - only color changed, only brightness changed, etc.). |
@ebaauw Yes thanks for all the detail. |
Never mind. i see how i can do it one by one. |
Indeed, one by one is the only way provided by the Hue API. |
Not really sure what to make of these, but they appear in the error log when I attempt to change the lights. Using the iOS 10 Home app, I get a "Failed" state on Philips Hue bulbs when attempting to tap a scene. From what I can tell, it looks like this usually occurs for bulbs that are trying to change more than one parameter (e.g. hue, saturation, brightness) within on scene.
I've also noticed in the log file that bulbs appear to be changed from "0" to "false" (or vice versa), and "1" to "true". Seems like the type of a variable isn't set correctly, but I could be wrong...
I am running Homebridge on a Raspberry Pi 2 B+ and I have the 1st Generation Hue Hub. This is my config file:
The text was updated successfully, but these errors were encountered: