Closed brunmayr closed 6 years ago
I guess the controller you are using does only support RGBW instead of RGBWC? To me it looks like the expected response package is just missing the last integer value and therefore the dictionary value isn't filled but just a "blank" BytesIO object.
Can you fully control your device by your proposed fix? If so I think it is feasible to use it in production, but at first glance I would think it might cause unexpected problems in other functions.
I purchased the following controller: https://www.amazon.de/dp/B075X8TJCD/ref=twister_B077JMHF1R?_encoding=UTF8&psc=1
But the led stripe only supports RGBWW- so the CW connector is unused- i didn't mention that it works only with both White- Channels! The fix is working for me- i tested the General Functions and ct changes in the white spectrum, everything is working fine.
IMHO that fix should extend the compatibility in case of missing channels- if all connectors are supplied, there should be no reason for a blank ByteIO object.
Thank you for that nice library- i can complete some missing control functions in fhem using your functions!
Alright, I will have a closer look in 2 weeks when I have more time and work out the best solution.
Thx for the info! :)
I'm a little surprised your controller can interpret the requests sent by this library, as they contain more fields than necessary for only rgbww colors. But I guess they use the same protocol and just ignore fields they don't need. I still can't understand though how the parsing of the data works with your controller when some fields are missing. When I try to simulate this on my end I get this:
raise StreamError("stream read less then specified amount, expected %d, found %d" % (length, len(data)))
construct.core.StreamError: stream read less then specified amount, expected 1, found 0
And the data parsing fails.
Would it be possible for you to add a breakpoint in packets/responses.py
in line 57 where the received data from the controller is set to the StatusResponse
and post it's content here? You can also just add a print statement in that line and copy&paste it from the console if this is easier for you to accomplish.
Then I can take your exact controller response and do some testing with it.
This is the output of the data-Object if i set device.set_ww(255, 255):
b'\x81%#a!\x0f\x00\x00\x00\x00\x01\x00\xffZ'
b'\x81%#a!\x0f\x00\x00\x00\xff\x01\xff\x0fh'
I'm able to reproduce the problem and it has nothing to do with missing support for some channel. I'm a little surprised I never ran into this before. The response you are getting is the same as the one I get (when just looking at the size of the content). I guess the construct package was changed in the meantime and now includes an "_io" dict key? tbh I'm still not quite sure what causes this. But knowing that it probably comes from the data parsing and additional keys are most likely never a problem I will just include your fix.
Hi,
the function _calculate_checksum in packets/init.py throws the following error:
File "/opt/sunix/markusressel/sunix-ledstrip-controller-client/sunix_ledstrip_controller_client/packets/init.py", line 24, in _calculate_checksum checksum += params[param] TypeError: unsupported operand type(s) for +=: 'int' and '_io.BytesIO'
I don't know why but the params- Array has the following contents:
139 138 129 <_io.BytesIO object at 0x7fbfb9ae9a08>
I changed the checksum-function like that:
So it works for my Sunix Controller (HF-LPB100-ZJ200, Version V1.0.06)
Kind regards Georg