Could you detach it from the fork? Now nobody can fork this plugin.
I also made some adjustments to the css file so the dimmer look better on mobile devices:
old:
new:
New pimatic plugin for integration with Philips Hue
Could you detach it from the fork? Now nobody can fork this plugin.
I also made some adjustments to the css file so the dimmer look better on mobile devices:
old:
new:
@sweebee said:
Could you detach it from the fork?
Perhaps the easiest way of doing this: “To detach the fork and turn it into a standalone repository on GitHub, contact GitHub support”. See also https://help.github.com/articles/why-are-my-contributions-not-showing-up-on-my-profile for further info.
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
I’ve simply deleted the repo and pushed it anew - there were no issues or PRs or anything yet anyway, so while that is the case, it was easier. Fork away!
I’m also not exactly a frontend guy, so I definitely appreciate help with CSS/UI stuff.
Installed the plugin today to check it out:
basic stuff works as expected, dimming and changing colors with the sliders work as they should.
the colorpicker is a little jumpy and generates a lot of socket hang up errors.
also when calling multiple lights with a rule, for example 4 hue color lights with different hue and sat settings but also 2 hue lux lights that I switch on simultaniously with a dummy switch I am getting this error:
21:38:11error [pimatic-mobile-frontend]: Client error: Uncaught Error: cannot call methods on slider prior to initialization; attempted to call method ‘disable’
other than that a great start, thanks!
Yea the color pickers are a pain in the ass (also for pimatic-led-light). Isn’t there a good color picker that also works great on mobile devices?
@djmvt said:
basic stuff works as expected, dimming and changing colors with the sliders work as they should.
the colorpicker is a little jumpy and generates a lot of socket hang up errors.
Does https://github.com/markbergsma/pimatic-hue-zll/commits/issue_picker_overload fix that?
(install with npm install git+https://github.com/markbergsma/pimatic-hue-zll.git#issue_picker_overload
)
also when calling multiple lights with a rule, for example 4 hue color lights with different hue and sat settings but also 2 hue lux lights that I switch on simultaniously with a dummy switch I am getting this error:
21:38:11error [pimatic-mobile-frontend]: Client error: Uncaught Error: cannot call methods on slider prior to initialization; attempted to call method ‘disable’
Thanks for the report - I’ve wrapped the slider method calls with “pimatic.try” which should suppress it. The branch above also has the fix, let me know if you see it again.
@markbergsma the uncaught error is still there after installing that branch but it is a lot less frequent so that is a good thing
Checked some stuff this morning:
There are still some errors reported, both socket hangup errors and the uncaught error but they are less frequent.
What I did notice is a higher cpu usage than before I was using this plugin (used the hue branch from pimatic led light before).
My pi went from idling between 5% and 15% to idling between 15% and 25%.
So it looks like hue-zll is doing a lot of polling or something like that.
Also the socket hangup errors are reported even when there is no status change, pimatic just running, no switches pushed or anything.
So there is something happening “under the hood”.
@djmvt at my raspberry, node is always around 1-5% cpu (with this plugin)
@sweebee could this have something to do with the number of hue lights? Got 11 hue lights configured.
It seems my pi is running higher anyway then. But with 3 temp sensors and about 15 switches on 433mhz, 2 kodi devices, hyperion connection, smartmeter, 2 ip cameras and some other stuff going on I don’t find this alarming haha
@djmvt said:
Checked some stuff this morning:
There are still some errors reported, both socket hangup errors and the uncaught error but they are less frequent.
The socket hangups I haven’t tackled yet, so that makes sense. On the uncaught error: is it still exactly the same error, or is it subtly different now? Still slider methods, etc?
What I did notice is a higher cpu usage than before I was using this plugin (used the hue branch from pimatic led light before).
My pi went from idling between 5% and 15% to idling between 15% and 25%.
That’s quite a lot indeed. On my RPi2 it doesn’t make a dent next to running pimatic-homeduino with an unfiltered RF receiver, but I’ll look into this more.
So it looks like hue-zll is doing a lot of polling or something like that.
Also the socket hangup errors are reported even when there is no status change, pimatic just running, no switches pushed or anything.So there is something happening "under the hood
Yes, for sure. It polls every light, by default every 5s but you can change that with the global “polling” configuration option. So if you have 11 lights configured, it will send 11 separate requests every 5s even if you do nothing else. And currently that probably means they are sent very closely after each other, which the Hue bridge may not like. That’s where the hangup errors are coming from.
If you enable debug logging, you can see some more of this happening.
I’ll see if I can improve this. If you have many lights it’s probably more efficient if the plugin requests the state for all lights in one request, so I’ll add that. Alternatively, I can add a poll interval per light, so the polling can be reduced for lights for which this is less important.
Unfortunately the Hue API doesn’t offer a way to subscribe to events and be notified of them as they happen, so some polling is necessary.
@markbergsma the uncaught error is indeed another one now: "cannot call methods on flipswitch prior to initialization; attempted to call method ‘enable’"
Didn’t notice this in the early morning.
About the polling: I guessed it had to be something like that, as far as I noticed pimatic led light does a single request for all the lights. So I think that would result in a lot less error messages.
Pimatic is running on a B+ pi so the higher cpu load should be normal. I don’t care about it a lot, everything is configured and running as it should (these small errors are worked on) so there’s no issue for me.
@djmvt said:
@markbergsma the uncaught error is indeed another one now: "cannot call methods on flipswitch prior to initialization; attempted to call method ‘enable’"
Didn’t notice this in the early morning.
Yes, that makes sense. I just pushed a fix for that to both branches as well - please let me know whether it’s completely gone now.
About the polling: I guessed it had to be something like that, as far as I noticed pimatic led light does a single request for all the lights. So I think that would result in a lot less error messages.
I’ll look at that next. Thanks!
@markbergsma uncaught error is gone
Ok - the Hue library the plugin is using (node-hue-api) apparently doesn’t currently support getting the status for all lights. (As far as I can tell pimatic-led-light doesn’t poll the state at all?) I might look at adding that upstream, later. Alternatively I could switch to using the Huejay library which would have some other advantages as well - but that requires Node.js 4+, so needs to wait until Pimatic 0.9.
In the mean time:
I’ve added a per-device polling interval configuration option, which allows you to change the default for that device. So if you need faster state changes for that device, lower it, if it’s unimportant, raise it to reduce the load on your system.
I’ve made all Hue API requests go through a FIFO queue with configurable concurrency (default: 2), so the bridge doesn’t get overwhelmed.
With that, I’m currently not able to trigger the socket hangup errors with ~9 lights and some groups, but YMMV. The master branch is updated. Let me know if it doesn’t improve the situation. Thanks!
@markbergsma said:
As far as I can tell pimatic-led-light doesn’t poll the state at all?
Yes, this is missing as `node-hue-api’ did not provide any easy way of get the rgb state. This has been implement meanwhile, however. See https://github.com/peter-murray/node-hue-api/issues/77
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
Wasn’t aware that there was no polling in pimatic led light.
Anyway I’ve been testing this weekend and got a lot less errors. An occasional socket hangup is still there but certainly not as frequent as it was.
Did get another error when starting a rule that involves changing states of 4 hue lights: “Client error: Cannot read property ‘spectrum’ of undefined”.
Does this have anything to do with the hue zll plugin?
Yesterday the author of node-hue-api was very quick to respond to my enhancement request for retrieving all lights/groups status at once. So today I’ve written support for that in pimatic-hue-zll. Github issue #2 Currently available in a branch:
https://github.com/markbergsma/pimatic-hue-zll/commits/global_polling
I’ll see how it behaves and then probably release that as 0.1.1 in the next few days if I notice or hear of no issues.
@djmvt said:
Wasn’t aware that there was no polling in pimatic led light.
Anyway I’ve been testing this weekend and got a lot less errors. An occasional socket hangup is still there but certainly not as frequent as it was.
Good, the queue definitely already helped, and no individual light/group polling will help even more.
Did get another error when starting a rule that involves changing states of 4 hue lights: “Client error: Cannot read property ‘spectrum’ of undefined”.
Does this have anything to do with the hue zll plugin?
Yes, likely, I guess I’ll need to trap that as well. Will have a look tomorrow.
Ok for now I’ll leave my installation as it is, for some reason when I try to update to the latest hue-zll my pimatic goes berzerk with “number of api calls exceeded” errors.
Will wait for the next official update.