search

mclarkk / lifxlan

Python library for accessing LIFX devices locally using the official LIFX LAN protocol.
MIT License
503 stars 115 forks source link

Light.get_power() stopped working after firmware update #172

Closed erchegyia closed 1 year ago

erchegyia commented 1 year ago

Recently updated my Mini DD to v3.9. the simple script from lifxlan import Light light = Light("D0:73:D5:XX:XX:XX", "192.168.1.XXX") if light.get_power() > 0: ... has stopped working.

File "/usr/local/lib/python2.7/dist-packages/lifxlan/light.py", line 41, in get_power response = self.req_with_resp(LightGetPower, LightStatePower) File "/usr/local/lib/python2.7/dist-packages/lifxlan/device.py", line 526, in req_with_resp raise WorkflowException("WorkflowException: Did not receive {} from {} (Name: {}) in response to {}".format(str(response_type), str(self.mac_addr), str(self.label), str(msg_type))) lifxlan.errors.WorkflowException: WorkflowException: Did not receive [<class 'lifxlan.msgtypes.LightStatePower'>] from d0:73:d5:xx:xx:xx (Name: None) in response to <class 'lifxlan.msgtypes.LightGetPower'>

Surprisingly I had to also fix DHCP reservations for this light as the MAC address has been changed during the firmware update. Did anybody else notice something similar? Couldn't find anything relevant in the release notes (except the mysterious "Significant improvements to connectivity").

erchegyia commented 1 year ago

Got the following reply from Lifx support regarding the MAC address, nothing so far regarding LAN API

"From v3.70, the MAC address reported to the router will be MAC+1, where MAC is the MAC address printed on the product. This requires static IP addresses to be reconfigured/updated in the router settings. This change is due to a limitation of the ESP32 and Amazon WSS onboarding in new products and can't be avoided. Note that the MAC address used in all other instances, i.e., in the App, communication with third-party devices, etc. is still the MAC address printed on the product."

erchegyia commented 1 year ago

ok, this was very confusing. The target in the frame address is supposed to be the MAC according to the docu: image This is not the case anymore after v3.9 as the MAC has been incremented, but the 'target' still should be the 'old' MAC (aka SN).