The "new" Milight IBox and milight binding

Add-ons Bindings
,
41

Hey @JMacIV,

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.

Cheers,
David

42

Looking forward to it! Thanks for the continued hard work.

If we can’t crack this, may have to gift you an iBox :slight_smile:

John

43

Changelog:

  • 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.

Thanks,
David

44

Hey David,

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!

John
beta1.txt.pdf (37.8 KB)

45

Hey John,

thank you for the attached log, there is indeed a NoSuchElementException, which should not occur anymore in this fixed build.

Changelog:

  • Update binding readme
  • Fix NoSuchElementException
  • Minimum (re)transmission is fixed to 1
  • Link/Unlink bulb implemented
  • If color value was too high, checksum sometimes was calculated wrong: fixed
  • Support multiple iBox bridges in the same network by checking the bridgeID when receiving a sessionID.

Thanks,
David

46

Hey David,

No exception in this build, but I still do not have any control, much like the last one.

I tried removing the old RGB iBox and RGB Bulb Color Zone in case they were conflicting. Unfortunately, that did not yield any results.

Thanks David!

John
beta2.txt.pdf (38.3 KB)

47

Hey John,

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.

48

Hey David,

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?

Thanks,
John

ibox-settings.png820×644 43.7 KB

49

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.

Thanks,
David

50

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 :frowning:

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…

Any other thoughts?

John
beta4-preUDP.txt.pdf (53.6 KB)

51

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.

Thanks,
David

52

Hey David,

Here is the logs with latest build. Keep in mind, this is post change from TCP to UDP. Should I try swapping that back?

I could not get the bulbs to respond at all this go round.

I am also attaching my bridge settings.

Thanks David!

bridge.png949×728 33 KB
beta6.txt.pdf (31.6 KB)

53

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.

Thanks,
David

54

Changelog:

Regards,
David

55

@David_Graeff,

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:

  1. 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.
  2. I can dim the brightness of the iBox. Seems to be ramping normally.
  3. I can change the colour. The colours do not reflect the PaperUI selection.
  4. 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.

Logs:
https://drive.google.com/open?id=0B0r7CYNTNqQIOTZyQlFDbmVKX1U
PS, I’ll put all my logs in this folder from now on

Thanks again David,

Appreciate the slog.

Duncan

56

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.

57

Hey all,

I somehow missed the fact, that their are different commands for RGBW and RGBWW bulb types.

Changelog:

  • Support RGBW and RGBWW types of bulbs
  • Change the thing type ids (braking change!). Please remove and re-add bulbs.

Cheers,
David

58

@David_Graeff, thanks again.

Exactly the same results this time.

iBox brightness set to 0 results in iBox light stopping responding.

Loss of the same item types after reboot. :pensive:

No response from my (i think RGBW) bulbs.

Logs in the same place as my last post.

Thanks again for the :alarm_clock:. Appreciate it.

Duncan

59

Hello I would like to help, but I am new to openhab2. I am not able to install the beta version. Could someone help with that I have a windows installation.

Solved, I have beta 8 running.

60

Hey @Duncan_Pullen and all,

have you tried the other bulb type (ww instead of w or other way round)? I may have confused them, because according to the log, you still use the commands of the bulbs that don’t work for you.

Thank you for continued test reports.

I have no real explanation why labels are disappearing for you. This looks like a paperui or core problem, but within the binding I do not edit the thing after a bridge discovery took place, and it is created the same way each time.

Thanks,
David