search

Danielhiversen / flux_led

A utility for controlling Flux WiFi Smart LED Light Bulbs
GNU Lesser General Public License v3.0
158 stars 144 forks source link

support for wifi370 led strip controllers #32

Closed ChefsSlaad closed 7 years ago

ChefsSlaad commented 7 years ago

I have an (older?) wifi led strip controller, described as wifi370 on the box. https://nl.aliexpress.com/item/Original-Wifi-RGB-LED-controller-for-Iphone-Ipad-Android-mobile-phone-2-3Version-IOS-system-DC7/1032823060.html

this device is supported by the magic home app, and it seems to be a 'propper' flux_led device, but it has some significant differences.

this library recognizes it while scanning, but this device uses a different set of commands and does not use a checksum to send data. eg, turn on is CC 23 33 rather than 71 23 0F status is EF 01 77 rather than 81 8A 8B

this device also returns only 11 bytes of status rather than the 14 this library expects.

I managed to do a python conversion based on https://github.com/sidoh/ledenet_api

it can be found here: https://github.com/marcwagner/alarmclock/blob/master/ledenet_api.py

I can probably integrate my code into this project so that it can also work with homeassistant. However, due to some of the differences I am worried about breaking compatibility.

so, two questions: should I integrate my code and is there an easy way to recognize the different flavors of protocol?

Danielhiversen commented 7 years ago

If it is possible to add support for your device without breaking any compatibility, it would be great if you could integrate it here.

There is some code to recognize the protocol here: https://github.com/Danielhiversen/flux_led/blob/master/flux_led/__main__.py#L603

I have just started to add some tests, to make the risk of breaking current functionality a bit less.

ChefsSlaad commented 7 years ago

I will try :)

two questions:

  1. can you explain what the different mode values are? self.mode self.protocol (this one in particular!) self.rgbwcapable self.rgbwprotocol

  2. sending the state request uses a different set of bytes. The only way to get a response (that I can think of) is to send the second set when the first set does not result in a valid response. Do you see a better way?

ChefsSlaad commented 7 years ago

created a pull request for my first attempt. Let me know how I did

edit: also fixed some bugs I introduced

ChefsSlaad commented 7 years ago

ok, there was a conflict introduced by pull request 36 which I attepted to solve. however, there still seems to be a conflict that I believe needs your attention. Could you have a look and let me know if there is anything I need to adjust?