Thanks again for another iteration.
I have mixed news…
My ibox is doing the following:
Brightness ok
On/off ok
Color - not working
Party - works, but unable to be cancelled
RGB Bulbs:
No responding to any commands at all.
Tried:
Nightmode
On/Off
Colors
Color brightness
Color saturation
Party mode
Without an actual device and seeing the traffic of the commercial app via wireshark I may not be able to implement that correctly. I have no idea if it is a timing issue, because for sending the color I actually have to send three commands in a row or if the documentation is wrong about the actual commands for colors. I will provide another iteration with a changed timing later.
I think that we may have gone in reverse with this build. The whole system is less stable.
The On/Off on Color Zone 1 is finicky. It does not work consistently. Sometimes on/off works, others it does not. Sometimes the brightness slider and NightMode are working. On some instances, in order to get control back for one/off, you must enable and disable NightMode before the main ON/Off will work again.
I seemed to have lost all control of the iBox.
On a positive note, the brightness %s seem to be much more accurate!
I will try again with WireShark to see if I can make some headway.
wait another half an hour and I’ll upload an improved version. I think I found the reason why setting the color didn’t work. And yes the refactoring made the code look better but caused some regressions with encoding the iBox session id, required for sending further commands.
Make the rgbww led a separate thing. It works differently than the old RGBW bulbs and this is reflected in the available channels.
The previous animation mode channel is now only available for rgbww as it was emulated on older bulbs anyway. A new relative animation mode change channel is for all other/older led types.
Fix incoming packet parsing.
Fix channel definitions. Brightness and Saturation now correctly allow a value between 0-100 (PercentType).
Fix checksum calculations for color commands.
Add “password” configuration. (iBox supports to set a two byte password. I have no idea what this is for, the commands are send plain text anyway.)
Command repeat configuration
Wait between commands configuration
Commands are issued into a scheduled sender thread and no blocking sleep is used anymore.
Whitemode/Nightmode are triggers now instead of stateful channels. The most suitable widget would be a pushbutton. To return from Whitemode/Nightmode it might be enough to change the brightness I recon, but not sure. This is not really specified.
Glad to see we have moved onto Beta! I tried setting up the new RGBWW bulb settings, unfortunately, I seem to have no control over the iBox or the RGBWW bulbs, either using the Color Zone 1 or the RGBWW Zone 1 or the regular Color iBox or the new RGBWW iBox.
I did not bother to check the WhiteMode yet.
Looks like we also have some exceptions again in the log.
I really do appreciate all of this hard work David!
so Alpha9 worked the best for you so far and you had control over the iBox led?
Just from judging with what I can see in the logs, the communication is perfect now in beta2. All send packets are confirmed by the bridge, the initial session handshake works as well, no exceptions in the code. I have no clue what causes the non functional channels, to be honest.
That is correct. I Alpha9 definitely worked the best. I have no idea either. I am attaching a screenshot of the iBox software settings from its internal web server. Maybe it will hold a clue?
Hm, I think network protocol should be set to UDP. Could you change that and try again? I have updated the above post with a slightly modified variant, just too exclude stupid mistakes, like using a command repeat of 0 etc.
I went ahead and upgraded to Beta4. Once that was installed, I was able to turn the bulbs off, but not back on. And nothing else.
I then changed the setting to UDP, but have no effect. Still no control
I am attaching a log that was from before I set the UDP setting. Did not update the log after the UDP update since no change. I did check and it all looked pretty normal. Getting Session IDs and confirmation of commands…
This build does not really change anything but adds the entire session packet to the log, which might help. I suspect that if the iBox session ID is in a specific range, it works and with other IDs not. This could explain why it worked for you only for the first command or so, I made beta4 to request new session IDs every 10 seconds.
What catches my attention as well is that the second byte of the received session ID is always 00, no matter how often a new session has been generated. Looks wrong to me.
Would be really appreciated if you could provide me with this log.
Hm, looks absolute correct to me. Without a wireshark record of the app<–>bridge I have no idea what to try next.
Can you or someone run wireshark, observing the wifi or ethernet interface and sniffing for UDP traffic? It is necessary to run a local app or other implementation on the same PC for wireshark to work.
Alrighty… I have to install wireshark on my raspberry pi and then dig out the results. Sorry haven’t done that yet.
Here’s how my testing went. All testing was done in Paper UI.
Firstly, no response at all from my RGB lights. I’m thinking that may be to do with the fact that saturation is present. On my phone app, if i change my remote type (it’s a setting in the app) to include saturation, it completely stops controlling the lights. I’m guessing the same effect is in play here.
On to the iBox:
Turning the light off or to 0 brightness stops the iBox from responding. Nothing revives except turning the light on again on my phone app. Then responds to brightness again.
I can dim the brightness of the iBox. Seems to be ramping normally.
I can change the colour. The colours do not reflect the PaperUI selection.
HabPanel Colour picker did not work at all. (It includes saturation, so may explain it).
Another interesting observation. After reset or reboot the thing control for all the lights went wrong, the lost switches and were no longer labelled as brightness, saturation. I’ve put the screenshots in the log folder below.
I’m working with the first beta and have tried the last alpha. I notice some interesting behaviors issue.
At this point it is only repeatable on the RGB box using the Habpanel color picker. The hue would only increase in number until it was stuck at red.
Also in that panel sat and brightness sliders would act slightly different, any other commands would “put them on the same page again”.
on/off only turns off. On requires a bit of a hack.
In the last alpha, I could get around the on and off not working by turning one night mode giving the brightness value and turning off night mode.
In the first beta, most things are broken for most lights, but I have limited rgb box control. Whitemode works by link a switch, but it works one way ‘on’ there is no color mode.
I didn’t really get to test more and my computers out of action. I also took a cursory look at your code, limitless’s sample and a look out there to see if anyone has a work solution.