I am Daniel Hjelseth Høyer and I work as Data Scientist in Tibber. Tibber is a smart home and energy supplier. My work evolves machine learning.
I am also an active contributor to Home Assistant
A utility for controlling Flux WiFi Smart LED Light Bulbs
License: GNU Lesser General Public License v3.0
I am Daniel Hjelseth Høyer and I work as Data Scientist in Tibber. Tibber is a smart home and energy supplier. My work evolves machine learning.
I am also an active contributor to Home Assistant
Hi!
Can you please release v 0.2.3 of flux_led
to pypi?
Thanks!
The following command/argument list:
python -m flux_led -w 0 1.2.3.4
Returns the following error message:
Usage: usage: __main__.py [-sS10cwpCiltThe] [addr1 [addr2 [addr3] ...].
__main__.py: error: An operation must be specified
Zero percent does not seem to be recognized as a valid brightness setting.
One percent does work:
python -m flux_led -w 1 1.2.3.4
Hi,
Can you tell me if this module is compatible with these device bulb?
https://pt.aliexpress.com/item/4000290763952.html
I have a little programming experience and if you can I can rn some commands...
Thanks...
Is there a way/documentation how to add new lights to protocol.py?
I am interested in
SP107E - https://gist.github.com/and7ey/c299ff2e34ac714621b2ef4f4eeb4ae3
SP110E - https://gist.github.com/mbullington/37957501a07ad065b67d4e8d39bfe012?permalink_comment_id=3611593#gistcomment-3611593
In result it will be supported in led_ble Home Assistant component - Bluetooth-Devices/led-ble#34
My device is a Controller RGB/WW/CW (0x25).
This is the code I used:
import asyncio
import logging
import pprint
from flux_led.aiodevice import AIOWifiLedBulb
logging.basicConfig(level=logging.DEBUG)
ip = "192.168.1.160"
async def go():
bulb = AIOWifiLedBulb(ip)
def _async_updated():
pprint.pprint(["State Changed!", bulb.raw_state])
await bulb.async_setup(_async_updated)
print(bulb.operating_mode)
await bulb.async_set_device_config(operating_mode="RGB")
await bulb.async_update();
print(bulb.operating_mode)
asyncio.run(go())
and this is the output:
DEBUG:asyncio:Using proactor: IocpProactor
DEBUG:flux_led.aioprotocol:('192.168.1.160', 5577) => 0x81 0x8A 0x8B 0x96 (4)
DEBUG:flux_led.aioprotocol:('192.168.1.160', 5577) <= 0x81 0x25 0x24 0x61 0x21 0x13 0x26 0x26 0x26 0x00 0x01 0x00 0x00 0xD2 (14)
DEBUG:flux_led.base_device:192.168.1.160: set_available: Received message 81252461211326262600010000d2
DEBUG:flux_led.base_device:192.168.1.160: State: LEDENETRawState(head=129, model_num=37, power_state=36, preset_pattern=97, mode=33, speed=19, red=38, green=38, blue=38, warm_white=0, version_number=1, cool_white=0, color_mode=0, check_sum=210)
DEBUG:flux_led.base_device:192.168.1.160: unmapped raw state: 129,37,36,97,33,19,38,38,38,0,1,0,0,210,
DEBUG:flux_led.base_device:192.168.1.160: Mapped State: LEDENETRawState(head=129, model_num=37, power_state=36, preset_pattern=97, mode=33, speed=19, red=38, green=38, blue=38, warm_white=0, version_number=1, cool_white=0, color_mode=0, check_sum=210)
['State Changed!',
LEDENETRawState(head=129, model_num=37, power_state=36, preset_pattern=97, mode=33, speed=19, red=38, green=38, blue=38, warm_white=0, version_number=1, cool_white=0, color_mode=0, check_sum=210)]
DEBUG:flux_led.aiodevice:192.168.1.160: device_config: wiring=None operating_mode=DIM
DIM
DEBUG:flux_led.aioprotocol:('192.168.1.160', 5577) => 0x62 0x03 0x0F 0x74 (4)
DEBUG:flux_led.aioprotocol:('192.168.1.160', 5577) => 0x81 0x8A 0x8B 0x96 (4)
DIM
Not sure what webcolors version is expected, but:
❯ flux_led --listcolors
Traceback (most recent call last):
File "/home/francisco/.local/bin/flux_led", line 8, in <module>
sys.exit(main())
File "/home/francisco/.pyenv/versions/flux_led/lib/python3.9/site-packages/flux_led/__main__.py", line 1718, in main
(options, args) = parseArgs()
File "/home/francisco/.pyenv/versions/flux_led/lib/python3.9/site-packages/flux_led/__main__.py", line 1655, in parseArgs
for c in utils.get_color_names_list():
File "/home/francisco/.pyenv/versions/flux_led/lib/python3.9/site-packages/flux_led/__main__.py", line 110, in get_color_names_list
for key in list(webcolors.css2_hex_to_names.keys()):
AttributeError: module 'webcolors' has no attribute 'css2_hex_to_names'
This member exists in uppercase (CSS2_HEX_TO_NAMES
), not lowercase.
Hi,
if I issue any python -m flux_led ...
command, I receive the following runtime warning:
/Users/rene/miniconda3/lib/python3.6/runpy.py:125: RuntimeWarning: 'flux_led.__main__' found in sys.modules after import of package 'flux_led', but prior to execution of 'flux_led.__main__'; this may result in unpredictable behaviour
The commands run fine on the device but I wonder whether this warning could turn into a bug at some point.
Greetings
René
I want to make a Python Script that changes the color of the light when a pitch is detected via Aubio.
The flux_led/BL602L20 based controllers seem to support bluetooth out of the box even if they're labeled as Wifi.
Are there any plans of supporting the BT control?
Hi,
This doesn't support my RGBCW lights and I wanted to see if it could with some a minor adjustments. A fix may be near line 700 where the mode code for this light responds as 01, interpreted as WW in the comments. It looks a little different in the code however at line 601 where 01 actually registers as DIM and not RGBM. I am curious if then before making a 01 device register as a WW or DIM? light if we could run another conditional to see if it could recognize something closer to a RGBW controller - that might be all it takes to get this working for an RGBCW light.
I have a mockup at home in C# and know the commands well.
Here is an example response from the Magic Light RGBCW device:
RGBCW
# 81 35 24 61 01 05 FE 00 00 00 07 00 0F 55
(this is my RGBCW device response)
# 81 25 23 61 21 06 38 05 06 f9 01 00 0f 9d
# | | | | | | | | | | | | | |
# | | | | | | | | | | | | | checksum
# | | | | | | | | | | | | color mode (f0 colors were set, 0f whites, 00 all were set)
# | | | | | | | | | | | cool-white 0x00 to 0xFF
# | | | | | | | | | | version number
# | | | | | | | | | warmwhite 0x00 to 0xFF
# | | | | | | | | blue 0x00 to 0xFF
# | | | | | | | green 0x00 to 0xFF
# | | | | | | red 0x00 to 0xFF
# | | | | | speed: 0x01 = highest 0x1f is lowest
# | | | | Mode WW(01), WW+CW(02), RGB(03), RGBW(04), RGBWW(05)
# | | | preset pattern
# | | off(23)/on(24)
# | type
# msg head
(this is the response expected taken from code - note Mode does not define RGBCW accurately for this device and the comments are a little different than the code.) At least maybe update the comments from
# | | | | Mode WW(01), WW+CW(02), RGB(03), RGBW(04), RGBWW(05)
to
# | | | | Mode(if61) DIM(01), CCT(02), RGB(03), RGBW(04), RGBWW(05)
and if we can include RGBCW lights to
# | | | | Mode(if61) DIM+RGBCW(01), CCT(02), RGB(03), RGBW(04), RGBWW(05)
Thank you so much for your help in understanding this one!
I bought these exact bulbs and color control doesn't seem to be working with it in Home Assistant:
https://www.amazon.com/gp/product/B07VQLZBNW/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1
The bulbs display their model number as v7 inside the MagicLight Android app (which is interesting because some older bulbs I purchased that only support rgb show as v8 and work fine).
Setting the color temperature (CCT) from inside the Android app gets the light to use brighter LEDs whereas if you select a color it uses LEDs that aren't nearly as powerful. If the bulb is setup in HA with the mode as rgbw
it allows you to control the color temperature but not the color. Even though you can change the color temperature it is very buggy and often times will just turn the bulb off.
These bulbs are incredibly cheap and when using the brighter white LEDs the bulb is actually pretty bright. The main reason I purchased them was to setup some cheap outdoor color bulbs for Christmas/Holiday lighting. I have Hue but $50 per bulb for outdoor color lighting is just too much. At this price point I wouldn't mind buying more bulbs if support was added for them.
If someone needs a bulb to help get this done I would be willing to buy and ship one if it is within the mainland USA.
@gerth2 and I have a controller that uses a variation of the LEDENET controller: https://www.amazon.com/gp/product/B01DY56N8U/
We've had some discussions over in this WIP PR: #42
Basically, we both get packets from the controller that look like this (14 bytes):
81 25 23 61 21 06 38 05 06 f9 01 00 0f 9d
0 Unknown
1 Type?
2 On/Off (23/24)
3 Effect
4 Unknown
5 Speed
6 Red
7 Green
8 Blue
9 Warm White
10 Unknown (always 01 so far)
11 Cold White
12 White/Color mode (f0 when colors were set, 0f when whites were set)
13 Checksum (I think?)
The Magic Color app sends packets that look like this (9 bytes):
31 bc c1 ff 00 00 f0 0f ac
31 00 00 00 d9 8a 0f 0f b2
0 Command
1 Red
2 Green
3 Blue
4 Warm White
5 Cold White
6 Write mode (f0 for color, 0f for white) -- should try ff to see if both can be written
7 Unknown
8 Checksum
@mjg59 you may be interested in the details here, as it seems related to #22 although with a different protocol variation.
Edit: corrected white/color mode byte meaning in status packet
Hi there,
Love the project, awesome work.
I just have one request: I might be able to do it if I have time to go through the code, but I have a set of lights that don't connect consistently to my wifi. If I use flux_led via bash in Linux, I'll have errors, like
Unable to connect to bulb at [redacted_ip]: bytearray index out of range
or
Unable to connect to bulb at [10.0.0.16]: timed out
...Which, if my strip isn't available, makes sense.
That's an error condition-- I realize that the script loops through bulbs to try and set them all, but the sys.exit(0) at the end doesn't give an indication to a shell script that there may have been errors based on the exit code.
Would you be willing to change this, or would you accept a pull request?
@Danielhiversen I tried to move the repo to Travisci.com but, I'm not able to since I don't own the repo. Can you add it? I can update the documentation once you do.
Hello,
I'm using this script instead of the MagicHome app becouse this one actually WORKS!
Has anyone tried to create a GUI for this app? Typing command lines in android is not very pleasant.
Hello! I'm pretty new to HA and ultra new to Flux/Magic Home as I'm trying to get my fish tank light integrated into HA for gradual on/off as well as being able to control it from my dashboard. I'm using a Lominie 4 Channels WiFi Controller for Upgraded F20 S120 P80 S20 P30 (WiFi-4 Channels) which is getting picked up as an 0x6 device by the Magic Home integration.
I'm running HA Container as I'm running all my HA stuff on a Ubuntu machine. The light is found via the Magic Home integration with no problem and basic controls like turning the light on/off, as well as jumping between "colors" (the light isn't true RGB as it's it's just using different white lights for those channels).
I saw in the Magic Home App that there is the ability to do gradient on/off. Is this something that could be brought into the Flux_led/Magic Home integration? It would be awesome to have my HA trigger the gradient on/off at various times, as it's currently not possible within the Magic Home App to schedule a gradient on/off event..
Attached is a copy of the diagnostics for the controller if it will help and provide any insight.
I've tried writing a few different scripts including using a float for "transition" thinking maybe that would get it to work, but I've had no luck. Maybe I'm just missing something, or maybe it's not implemented yet (as this appears to be a newish controller).
Any help would be appreciated. Thanks!
config_entry-flux_led-5afc1c443403de0f6e305599c965a57c.json.txt
Hi, I have a number of brightness only devices, such as these: https://smile.amazon.com/gp/product/B07J5B3R5L/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
These present themselves in the webui as
Unknown Model (0x21)
by FluxLED/Magic Home
Firmware: 2
and in the debug log
2021-10-17 21:32:46 DEBUG (MainThread) [flux_led.aioprotocol] ('192.168.254.233', 5577) <= 0x81 0x21 0x23 0x61 0x41 0x01 0xFF 0x00 0x00 0x00 0x02 0x00 0x00 0x69 (14)
2021-10-17 21:32:46 DEBUG (MainThread) [flux_led.device] 192.168.254.233: State: LEDENETRawState(head=129, model_num=33, power_state=35, preset_pattern=97, mode=65, speed=1,
red=255, green=0, blue=0, warm_white=0, version_number=2, cool_white=0, color_mode=0, check_sum=105)
2021-10-17 21:32:46 DEBUG (MainThread) [flux_led.device] 192.168.254.233: unmapped raw state: 129,33,35,97,65,1,255,0,0,0,2,0,0,105,
The problem is when I turn them on, the brightness doesn't get set and it stays off. Setting the brightness seems to adjust only the 'w' color, which seems to be ignored by this type of device.
The devices are quite useful, because any number of single color LED devices include a barrel connector and they are plug in play.
The only value you can set for a brightness only device is the 'r' channel I think. My work-around is as follows:
+++ b/homeassistant/components/flux_led/light.py
@@ -256,7 +256,7 @@ async def async_setup_entry(
try:
custom_effect_colors = ast.literal_eval(
options.get(CONF_CUSTOM_EFFECT_COLORS) or "[]"
- )
+ ) or []
except (ValueError, TypeError, SyntaxError, MemoryError) as ex:
_LOGGER.warning(
"Could not parse custom effect colors for %s: %s", entry.unique_id, ex
@@ -454,7 +454,7 @@ class FluxLight(FluxEntity, CoordinatorEntity, LightEntity):
return
# Handle Brightness Only Color Mode
if self.color_mode == COLOR_MODE_BRIGHTNESS:
- await self._device.async_set_levels(w=brightness)
+ await self._device.async_set_levels(r=brightness)
return
raise ValueError(f"Unsupported color mode {self.color_mode}")
With the above, I can turn it on and off, and slide the brightness in the gui, but the brightness is not reflected back, so it's half working. Sorry - I know the above patch is for the HA component, but it seems like the fix needs to be in the driver or likely both.
This encompasses two issues: warm white mode isn't set correctly, and there is a new bulb type hex value.
comment says:
# LEDENET devices support two white outputs for cold and warm. We set
# the second one here - if we're only setting a single white value,
# we set the second output to be the same as the first
This doesn't seem like the right thing to do, because on my newer bulbs it causes both the warm and cold lights to be activated at the same time, resulting in a not-warm appearance. Simply appending 00 fixes the issue.
The new bulb type is 0x35. Example messages: 8135236101050000000007ff0f55
I'm making a PR for these issues
The second byte of the state string determines the type of device and the protocol it speaks. Do you have any dumps of that for the LEDENET systems? I've been figuring out how to use this to determine whether a device is RGB+W or true RGBW as well.
Could you please have a look at this issue?: home-assistant/core#59725
Do you think that's fixable?
Thank you in advance.
Hello Dear.
I have RGB and RGBW led controller and i want to distinguish these two type of LEDs.
Is there any command that determined whether the led is RGB or RGBW?
Thank you.
Hallo,
is it possible to turn on wihte and color LED at same time?
Thanks
Markus
Query strip order
63 ...
Setting strip order
RGBW 0x06
62 06 02 0f 79 - RGB/W GRB W
62 04 02 0f 77 - RGB&W GRB W
62 04 01 0f 77 - RGB&W RGB W
62 04 03 0f 77 - RGB&W BRG W
RGBCW 0x07
62 05 0f 0f 85 - RGB&CCT / WCBRG
62 07 0f 0f 87 - RGB/CCT / WCBRG
62 07 01 0f 79 - RGB/CCT / RGBCW
62 07 02 0f 7a - RGB/CCT / GRBCW
62 07 0c 0f 84 - RGB/CCT / CBRGW
RGB 0x33 / 0x08
62 00 01 0f 73 - RGB
62 00 02 0f 73 - GRB
62 00 03 0f 73 - BRG
Query
62 00 02 0f 73
Response
0f 62 00 71
But we can get it all from 0x81
0x25
62 01 0f 72 - DIM
62 02 0f 73 - CCT
62 03 0f 74 - RGB
62 04 0f 74 - RGB&W
62 05 0f 74 - RGB&CCT
0xA1
0000 63 12 21 36 <-- Query
0000 63 00 32 05 00 00 00 00 00 00 02 9c <-- Response
Set
62 08 00 04 00 00 00 00 00 00 02 f0 60 <- set 2048
62 04 00 04 00 00 00 00 00 00 02 f0 5c <- set 1024
62 04 00 04 00 00 00 00 00 00 00 f0 5a
#pos 0 1 2 3 4 5 6 7 8 9 10 11 12
# 62 04 00 04 00 00 00 00 00 00 02 f0 5c <- checksum
# | | | | | | | | | | | |
# | | | | | | | | | | | always 0xf0
# | | | | | | | | | | wiring type (0 indexed, RGB or RGBW)
# | | | | | | | | | ?? always 00
# | | | | | | | | ?? always 00
# | | | | | | | n?? always 00
# | | | | | | ?? always 00
# | | | | | ?? always 00
# | | | | ?? always 00
# | | | ic type (01=UCS1903, 02=SM16703, 03=WS2811, 04=WS2812B, 05=SK6812, 06=INK1003, 07=WS2801, 08=LB1914)
# | | num pixels (16 bit, low byte)
# | num pixels (16 bit, high byte)
# msg head
#
0xA2
0000 63 12 21 0f a5 <-- Query
0000 0f 63 00 32 00 01 01 04 32 01 dd <-- Response
Set
0000 62 00 32 00 01 01 04 32 01 0f dc <-set 50
0000 62 01 2c 00 06 01 04 32 01 0f dc
#pos 0 1 2 3 4 5 6 7 8 9 10
# 62 01 2c 00 06 01 04 32 01 0f dc
# | | | | | | | | | | |
# | | | | | | | | | | |
# | | | | | | | | | | checksum
# | | | | | | | | | ?? always 0x0f
# | | | | | | | | segments (music mode)
# | | | | | | | num pixels (music mode)
# | | | | | | wiring type (0 indexed, RGB or RGBW)
# | | | | | ic type (01=WS2812B, 02=SM16703, 03=SM16704, 04=WS2811, 05=UCS1903, 06=SK6812, 07=SK6812RGBW, 08=INK1003, 09=UCS2904B)
# | | | | segments
# | | | ?? always 00
# | | num pixels (16 bit, low byte)
# | num pixels (16 bit, high byte)
# msg head
#
0xA3
0000 b0 b1 b2 b3 00 01 01 4f 00 05 63 12 21 0f a5 66
63 12 21 0f a5 <-- Query
0000 b0 b1 b2 b3 00 01 01 4f 00 0b 00 63 00 90 00 01 07 08 90 01 94 4a
63 00 90 00 01 07 08 90 01 94 <-- response
#pos 0 1 2 3 4 5 6 7 8 9
# 63 01 2c 00 01 07 08 96 01 45
# | | | | | | | | | |
# | | | | | | | | | |
# | | | | | | | | | |
# | | | | | | | | | checksum
# | | | | | | | | segments (music mode)
# | | | | | | | num pixels (music mode)
# | | | | | | wiring type (0 indexed, RGB or RGBW)
# | | | | | ic type (01=WS2812B, 02=SM16703, 03=SM16704, 04=WS2811, 05=UCS1903, 06=SK6812, 07=SK6812RGBW, 08=INK1003, 09=UCS2904B)
# | | | | segments
# | | | ?? (always 0x00)
# | | num pixels (16 bit, low byte)
# | num pixels (16 bit, high byte)
# msg head
#
Set
#pos 0 1 2 3 4 5 6 7 8 9 10
# 62 01 2c 00 01 07 08 96 01 0f 45
# | | | | | | | | | | |
# | | | | | | | | | | |
# | | | | | | | | | | checksum
# | | | | | | | | | ?? (always 0x0f)
# | | | | | | | | segments (music mode)
# | | | | | | | num pixels (music mode)
# | | | | | | wiring type (0 indexed, RGB or RGBW)
# | | | | | ic type (01=WS2812B, 02=SM16703, 03=SM16704, 04=WS2811, 05=UCS1903, 06=SK6812, 07=SK6812RGBW, 08=INK1003, 09=UCS2904B)
# | | | | segments
# | | | ?? (always 0x00)
# | | num pixels (16 bit, low byte)
# | num pixels (16 bit, high byte)
# msg head
#
https://github.com/Danielhiversen/flux_led/blob/master/flux_led/models_db.py#L120
In your readme, you only mention "Magic Home" does it still work for Magic Home Pro?
Per issue initially raised against HomeAssistant: home-assistant/core#11565
Investigation showed that raw data received by flux_led running under HASS was different to flux_led running via the command line and appeared to be sensitive as to how quickly/often it was queried.
A simple test program:
import flux_led
from time import sleep
light = flux_led.WifiLedBulb("192.168.200.170")
while True:
light.update_state(retry=2)
power_state = light.raw_state[2]
if power_state == 0x23:
print("ON")
elif power_state == 0x24:
print("OFF")
sleep(5)
Shows that if you change the sleep interval from 5 to 30 seconds, at 5 second pools changes made to the state of the LEDs is captured, at 30 seconds, it can take several minutes before the raw data reflects the current state.
Littering the code with print statements and checking if any errors or timeout in the socket was occurring showed no such evidence.
I have 4 different device types in use for testing which all exhibit this problem:
There seems to be some discrepancies between different LED strip manufacturers on what color wires mean what, or which bytes control which output channels.
To minimize confusing wiring or electrical work, support the ability to remap output channels per-device. Once the mapping is determined for the device, interacting with the flux_led API should be able to cause colors to change correctly (ie, setting the red channel value in the API causes the red LED's to turn on on the strip).
Create a python module package and publish it via PyPi to be installed via pip
.
This fix the issue #11
Hey,
any plans on adding the possibility to add those IC-Controllers or any advice on how to implement them myself?
https://www.ebay.de/itm/Wifi-RGB-IC-Led-Kontroller-Controller-Fernbedienung-fur-Android-IOS-Echo-Alexa/224136454002
Thanks
Jonas :)
Does this work on other controllers?
I've found a number of Led Strip controller that claim to work with the app Magic Home like those:
https://www.amazon.it/Regolatore-Wireless-striscia-regolatore-Smartphone/dp/B01J5A5YYM/ref=sr_1_4?s=kitchen&ie=UTF8&qid=1472830801&sr=1-4&keywords=led+controller
Have you tried?
Hi,
as the app did not work for my led strip (AK001-ZJ200 as reported by HF-A11ASSISTHREAD), I decided to dig a bit how to do it without the app and wrote this up just in case someone else wants to do the same, or if someone wants to try to integrate this to the code-base.
I found a link to a spec sheet from https://github.com/vikstrous/zengge-lightcontrol which describes the 48899 port communication to some extent: http://www.hi-flying.com/downloadsfront.do?method=picker&flag=all&id=dc406e44-84ec-4be1-ab11-a4ce403f6d3f&fileId=0f147d14-d0aa-4fc8-b01f-36e43418d19d .
For starters you must connect to the network advertised by the device LEDnetXXXX
or similar.
It should also be noted that some commands require passing a \r
while others do not.
On successful commands this device yields +ok=
(for queries followed by the response).
The wifi mode can be queried and set with the AT+WMODE command, so the first step was to change the controller from AP to STA mode:
echo 'AT+WMODE=STA\r' | nc -u 10.10.123.3 48899
This device required STA
all uppercase, a diversion from that spec sheet.
Setting the SSID and the key worked as follows:
echo 'AT+WSSSID=<NETWORK>' | nc -u 10.10.123.3 48899
echo 'AT+WSKEY=WPA2PSK,AES,<PASSWORD>' | nc -u 10.10.123.3 48899
The first two parameters needs to be adjusted accordingly depending on used encryption mode and cipher, this device accepted only all-uppercase variants. Note that adding \r
after the password would include that in it, the same is probably true for the name of the network.
After that the device can be rebooted and will hopefully connect to the network:
echo 'AT+Z\r' | nc -u 10.10.123.3 48899
Apparently some sort of software version can be requested by using VER, FVER and/or LVER, on my device only LVER did give a response:
AT+LVER\r
+ok=33_17_20170825_IR
It would be nice to have this integrated into this library & script, but I don't unfortunately have time for it. Hopefully this can be helpful to someone who wants to implement it, and maybe it helps someone who is looking into how to get these paired without the official "magic home" app.
Hi,
I want to increase/decrease the brightness of every color. But, I can able to perform it on warm/cold white color.
How to achieve this?
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?
Since updating to HA 2023.8 I have issues with my Magic Home RGBCCT wifi led controllers (AK001-ZJ2101, firmware 1.06). I have 4 of them and they all misbehave since the update:
Changing the color or brightness is only possible after the device has been turned on but before HA reports that it's off. Therefore chaging the color now requires three steps:
I checked the behaviour with the native app using local control and the device indeed reports that it's turned off after it was turned on via HA. However, if I disable the HA integration then they behave correctly in the Magic Home app.
2021-11-04 16:54:14 DEBUG (MainThread) [flux_led.aioprotocol] ('192.168.210.39', 5577) => 0x81 0x8A 0x8B 0x96 (4)
2021-11-04 16:54:14 DEBUG (MainThread) [flux_led.aioprotocol] ('192.168.210.39', 5577) <= 0x81 (1)
2021-11-04 16:54:14 DEBUG (MainThread) [flux_led.aioprotocol] ('192.168.210.39', 5577) <= 0x54 0x23 0x61 (3)
2021-11-04 16:54:14 DEBUG (MainThread) [flux_led.aioprotocol] ('192.168.210.39', 5577) <= 0x21 0x1F 0x59 0x22 (4)
2021-11-04 16:54:14 DEBUG (MainThread) [flux_led.aioprotocol] ('192.168.210.39', 5577) <= 0xFF 0x00 (2)
2021-11-04 16:54:14 DEBUG (MainThread) [flux_led.aioprotocol] ('192.168.210.39', 5577) <= 0x04 0x00 0xF0 0x07 (4)
Currently timers have no support for sunrise/sunset types. The iPhone app and 2nd generation bulbs support this feature out-of-the-box. The timers allow for gradual warm light brightness changes over a duration (supplied in minutes).
We should be able to read and write this timer state to bulbs.
I recently picked up some Zengge/HaoDeng/MagicHome/MagicHue (who's to say..) recess downlights, which are BLE mesh, and have a gateway. I've gone down a number of rabbit holes, but this component seems most promising, but it won't connect to the gateway locally. I can telnet to it on port 5577 though. Might be a case of the plugin always expecting a single light where technically these would present as an array of 1 or more of them when backhauled over the mesh.
https://www.amazon.com/gp/product/B0974P1459/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&th=1
My other thought was to try and create a ble/wifi bridge on esphome, but that will not be fun.
tks
On startup:
2021-10-18 07:16:06 ERROR (MainThread) [homeassistant.components.light] Error while setting up flux_led platform for light
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.9/site-packages/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
await asyncio.shield(task)
File "/home/homeassistant/.homeassistant/custom_components/flux_led/light.py", line 272, in async_setup_entry
list(custom_effect_colors),
TypeError: 'NoneType' object is not iterable
It would appear the CONF_CUSTOM_EFFECT_COLORS can return empty, and then the literal_eval returns None:
custom_effect_colors = ast.literal_eval(
options.get(CONF_CUSTOM_EFFECT_COLORS) or "[]"
)
I have a Lytworks Smart Fairy Lights. It's a string of 300 Fairy Lights with a IR RGB Controller JT-WF-RGB-03
which reports back as a AK001-ZJ2147
I get a raw state of:
129,26,35,37,1,0,100,8,0,0,1,0,6,87,
There is 7 colours that can be set onto the string.
Setting all 6 leds to blue is:
0b0b1b2b3000101080034a0000600010000ff0000ff00020000ff0000ff00030000ff0000ff00040000ff0000ff00050000ff0000ff00060000ff0000ffaf62
red
b0b1b2b3000101070034a000060001ff00000000ff0002ff00000000ff0003ff00000000ff0004ff00000000ff0005ff00000000ff0006ff00000000ffaf61
Set Blue-red-blue-red-blue-red
Set Blue
b0b1b2b30001010b0034a0000600010000ff0000ff0002ffff000000ff00030000ff0000ff0004ffff000000ff00050000ff0000ff0006ffff000000ffac5f
Query
b0b1b2b30001010c0004818a8b9604
b0b1b2b30001010c000e811a23280000640f000001000660a2
Set Red
b0b1b2b30001010d0034a0000600010000ff0000ff0002ff00000000ff00030000ff0000ff0004ff00000000ff00050000ff0000ff0006ff00000000ffaf67
Fairly sure the frames in the middle are querying the current state. There is also a stack of presets from 1-100, and able to set a cycle.
Any suggestions on debugging the frames as the first 4 bytes look standard magic, then 0101 and a counter, then the colours.
Any help would be appreciated.
led_flux.py
does not exist.python -m flux_led
fails withNo module named flux_led.__main__; 'flux_led' is a package and cannot be directly executed
Set warm white, 75%
says to use -0
but this turns the light off.I was able to find a workaround for (1) and (2) by executing flux_led/__init__.py
directly.
I'm currently implementing a Domoticz plugin using your library as api to handle the command to the real devices.
So far, i have succeeded in a basic setup, but when i want to set the brightness (or level) is "screws" up the brightness in the device, and sets it to 0.
There is no function available for setting the brightness regardless of the mode. so i use the getrgb, calculate the incoming value in 255 scale and call setrgbw with that calculated brightness
Hi,
I've a "Magic Home SPI Controller v3" with a WS2812B. It seems it only partially works.
When running a scan-command (-s) i get a valid response:
1 bulbs found
2CF443C91854 192.168.11.220 (mac is modified)
When i run a "-i 192.168.11.220" command i get this exception:
File "C:\Users\Gebruiker\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "C:\Users\Gebruiker\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\Users\Gebruiker\AppData\Local\Programs\Python\Python37\lib\site-packages\flux_led\__main__.py", line 1830, in <module>
main()
File "C:\Users\Gebruiker\AppData\Local\Programs\Python\Python37\lib\site-packages\flux_led\__main__.py", line 1807, in main
print("{} [{}] {}".format(info['id'], info['ipaddr'], bulb))
File "C:\Users\Gebruiker\AppData\Local\Programs\Python\Python37\lib\site-packages\flux_led\__main__.py", line 736, in __str__
pattern = rx[3]
TypeError: 'NoneType' object is not subscriptable
I did some debugging and saw what the issue is... One of the responses is:
81 a1 23 00 64 64 2a d5 00 02 03 00 59 6b = solid color
81 a1 23 00 65 64 2a d5 00 02 03 00 59 6b = function 1
81 a1 23 00 66 64 00 00 47 02 03 00 59 b4 = function 2
81 a1 23 00 67 64 ff ff ff 02 03 00 59 6b = function 3
Hello there,
as you might know this is used in the homebridge-magichome-platform plugin. This will form a bridge between Apples HomeKit and Magic Home Home controllers. But it seams as if this project is no longer maintained. This is why I'm asking you. Do you have any ideas, why this is happening?
There is an issue, through wich this script uses a lot of cpu time. ps -aux
reports:
python /usr/lib/node_modules/homebridge-magichome-platform/src/flux_led.py 10.0.0.252 -i
Restarting node solves the problem but I would like some other fix.
I will related to home-assistant/core#22161 add support to some configuration things that are explicitly used at strip controllers.
Remote control settings seem possible on these devices (AK001-ZJ2148
and AK001-ZJ2149
verified)
LEDENETHardware(
model="AK001-ZJ2148", # seen on older Addressable v3
chip=LEDENETChip.BL602,
rf_remote=True, # verified
),
LEDENETHardware(
model="AK001-ZJ2149", # seen on newer Addressable v3
chip=LEDENETChip.BL602,
rf_remote=True, # verified
),
Query
b0 b1 b2 b3 00 01 01 45 00 04 2b 2c 2d 84 19 <-- request: 2.4G remote control settings
Query Responses
b0 b1 b2 b3 00 01 01 5e 00 0e 2b 01 00 00 00 00 29 00 00 00 00 00 00 55 de <-- response: don't allow remotes
b0 b1 b2 b3 00 01 01 45 00 0e 2b 02 00 00 00 00 29 00 00 00 00 00 00 56 c7 <-- response: open to all remotes
b0 b1 b2 b3 00 01 01 5c 00 0e 2b 03 00 00 00 00 29 00 00 00 00 00 00 57 e0 <-- response: only allow specific remotes
b0 b1 b2 b3 00 01 01 e3 00 0e 2b 03 00 02 00 00 00 00 00 00 00 00 00 30 19
<-- '2 remotes, The controller can only be controlled after pairing with the device`
Commands
b0 b1 b2 b3 00 01 01 4e 00 10 2a 01 ff ff ff ff ff 00 00 00 00 00 00 00 0f 35 90 <-- set don't allow remotes
b0 b1 b2 b3 00 01 01 57 00 10 2a 02 ff ff ff ff ff 00 00 00 00 00 00 00 0f 36 9b <-- set open to all remotes
b0 b1 b2 b3 00 01 01 59 00 10 2a 03 ff ff ff ff ff 00 00 00 00 00 00 00 0f 37 9f <-- only allow specific remotes
b0 b1 b2 b3 00 01 01 f3 00 10 2a ff ff 01 ff ff ff 00 00 00 00 00 00 00 f0 16 f7
<-- clear pairings
Hi there,
is this implementation compatible to integrate it into Home Assistant?
flux_led.py in home assistant sends effects like so:
if effect in EFFECT_MAP: self._bulb.setPresetPattern(EFFECT_MAP[effect], 50)
Could the speed setting, set as 50 in this case, be set by the user when they send the effect?
I'm using some RGB 4-in-1 chip LED light strips and was trying to get the broadest colour spectrum possible by using combinations of the dedicated White LED cell in conjunction with the RGB LED cell. This allows for a range of pastel shades, though you tend to need to keep the % of white fairly low to see a difference.
After playing with the HASS UI there were times when I did end up with both LEDs on, and other times when I couldn't. So I thought I'd check what was possible in the module HASS uses.
I found I could get the desired effect, but only though sending two commands, as it's not possible to pass an RGB colour at the same time as the % White. For example:
python -m flux_led 192.168.200.58 -c 25,40,20 --on
python -m flux_led 192.168.200.58 -w 2 --on
If I wanted to leave the colour and remove the white, I couldn't use the off command, as this turns all of them off. Instead I had to set the white % to zero but set the light still to be on.
python -m flux_led 192.168.200.58 -w 0 --on
It would be a nice enhancement to be able to combine -c and -w values in a single command. How this would then be handled by the HASS UI, I'm not yet sure.
Using Ledenet strip module. Only the functions/animations, on off works but not set color
Any help would be greatly appreciated
Not sure if this should be asked as an issue or some other way.
When will the next release go out and pypy updated?
I'm asking because some of the fixes from the last commit will help the integration being worked on in Home Assistant. There's also another pull I'm going to propose to fix some of the output from the code that was added in my last pull request. It'd be great to have it added before another release.
Thanks for your time.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.