Closed scumbug closed 2 weeks ago
I managed to sniff out and tested the EOJ and EPC on SSNG (http://sh-center.org/sdk/ssng)
EOJ : 0x013A01
EPC : 0x80
EDT : on: 0x30 | off: 0x31
EPC : 0xF0
EDT : 0x31 to 0x3A (0x31 lowest, 0x3A highest)
EPC : 0xF2
EDT : on: 0x30 | off: 0x31
EPC : 0xF1
EDT : 0x41 down | 0x42 up
Looks like the class is missing from pychonet, and complicating things is the absence of the detailed specifications for 0x013A Ceiling Fan, but you have done all the heavy lifting with reverse engineering the properties. Shouldn't take too long to add this to the baseline, maybe within a week?
I have made some changes tonight to see if we can get this working. Can you please update from the repo directly rather then from HACS as I havent published an updated version yet.
You can also select and download the master branch using HACS. Please try it.
I was not aware you could do that! that is super handy to know!
may not work properly at the moment because I found a syntax error in CeilingFan class in pychonet and I need to push an updated version to PyPi which I wont be able to do until later tonight Australian time.
thanks for working on this. i did a quick test using my own implementation of ceilingfan class.
so far, the fan power, fan direction and fan fluctuation works but not fan speed.
i suspect we need to send multiple EPC to adjust the fan speed within 1 payload (maybe send both fan power and fan speed together)
have decompiled the manufacturer app that controls the fan and will continue to do some sniffing and reverse engineering of their data model
seems like the manufacturer are using proprietary EPC for all the device properties
EPC: 80 81 82 86 88 8A 8C 93 9D 9E 9F F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE
these are the EPC available when i try to get all property map from the device. will try to map the user defined EPC (F0 ~ FE) by looking at the decompiled app
alright, i have managed to map out the following
Hex | Dec | Description | EDT | Note |
---|---|---|---|---|
F0 | 240 | Fan Speed | 0x31 to 0x3A | 31 lowest, 3A highest |
F1 | 241 | Fan Direction | 0x41, 0x42 | 41 down, 42 up |
F2 | 242 | Fan Fluctuation | 0x30, 0x31 | 31 off, 30 on |
F3 | 243 | Light Power | 0x30, 0x31 | 31 off, 30 on |
F4 | 244 | Light Mode | 0x42, 0x43 | 42 normal, 43 night |
F5 | 245 | Light Brightness | 0x01 to 0x64 | 1 lowest, 64 highest |
F6 | 246 | Light Color | ? | |
F7 | 247 | Nightlight Brightness | 0x01, 0x32 | 1 low, 32 medium |
F8 | 248 | Off Timer | 0x31, 0x30 | 31 off, 30 on |
F9 | 249 | Off Timer Remaining Time | ? | |
FA | 250 | On Timer | 0x31, 0x40 to 0x43 | 31 off, 40 no melody, 41 to 43 melody select |
FB | 251 | On Timer Remaining Time | ? | |
FC | 252 | Fan Buzzer | 0x31, 0x30 | 31 off, 30 on |
FD | 253 | CtlOptSource | ? | |
FE | 254 | Melody | 0x40 to 0x43 | 40 no melody, 41 to 43 different melodies |
my fan model does not come with lights so i can't test them out. also can't find much information regarding the timers
and i realised that only fan power works with the current implementation. for everything else, we need to at least send the Fan Power EPC and Buzzer EPC together with the property we like to change.
Few examples:
To set fan speed
1081 0001 05FF01 013A01 61 03 80 01 30 FC 01 30 F0 01 3A
<--> <--> <----> <----> <-> <-> <--> <--> <--> <--> <--> <--> <--> <--> <-->
EHD TID SEOJ DEOJ ESV OPC EPC1 PDC1 EDT1 EPC2 PDC2 EDT2 EPC3 PDC3 EDT3
To set fan direction
1081 0001 05FF01 013A01 61 03 80 01 30 FC 01 30 F1 01 42
<--> <--> <----> <----> <-> <-> <--> <--> <--> <--> <--> <--> <--> <--> <-->
EHD TID SEOJ DEOJ ESV OPC EPC1 PDC1 EDT1 EPC2 PDC2 EDT2 EPC3 PDC3 EDT3
To set fan fluctuation
1081 0001 05FF01 013A01 61 03 80 01 30 FC 01 30 F2 01 30
<--> <--> <----> <----> <-> <-> <--> <--> <--> <--> <--> <--> <--> <--> <-->
EHD TID SEOJ DEOJ ESV OPC EPC1 PDC1 EDT1 EPC2 PDC2 EDT2 EPC3 PDC3 EDT3
Great work! Can you raise a PR on Pychonet with your implementation of the CeilingFan class? With respect to sending multiple values, the EchonetInstance setMessages can be used, look at the following methods from HomeAirConditioner as an example.
def setHeaterHumidifier(self, state, humidity):
if not state:
return self.setMessage(ENL_HVAC_HUMIDIFIER_STATE, 0x42)
return self.setMessages(
[
{"EPC": ENL_HVAC_HUMIDIFIER_STATE, "PDC": 0x01, "EDT": 0x41},
{"EPC": ENL_HVAC_HUMIDIFIER_VALUE, "PDC": 0x01, "EDT": humidity},
]
)
def setMode(self, mode):
if mode == "off":
return self.setMessage(ENL_STATUS, 0x31)
return self.setMessages(
[
{"EPC": ENL_STATUS, "PDC": 0x01, "EDT": 0x30},
{"EPC": ENL_HVAC_MODE, "PDC": 0x01, "EDT": MODES[mode]},
]
)
Im thinking implement the methods in CeilingFan and then update the code in Home Assistant to call them with method values rather then 'setMessage' (EDIT - this is they way it needs to be done because it will be easier to manage multiple vendor implementations in pychonet rather then in the home assistant component)
Also, since this is a vendor proprietary implementation, we probably need a means of supporting that within pychonet using the factory in combination with manufacturers ID(?)
Raised a PR over at pychonet. Have already tested it on home assistant (updated fan.py
on my local to call the methods instead of setMessage
) and everything seems to be working properly
on the manufacturer ID. calling EPC 0x8A
gives me the following
on the node profile: 0x00000B
on the device itself: 0x0000FE
Thats awesome! Ill publish the pychonet version shortly. Can you raise a PR in here too for fan.py?
Here's the PR for fan.py
Please test the master branch and if its all good ill release an update and close this.
just tested on master branch. works great! thank you for working on this!
Hi @scottyphillips, I am looking to enable the lighting feature of the fan here. I have also tested out the mapping, here is the updated mapping for the table on the lighting (F3 to F7 verified).
Hex | Dec | Description | EDT | Note |
---|---|---|---|---|
F0 | 240 | Fan Speed | 0x31 to 0x3A | 31 lowest, 3A highest |
F1 | 241 | Fan Direction | 0x41, 0x42 | 41 down, 42 up |
F2 | 242 | Fan Fluctuation | 0x30, 0x31 | 31 off, 30 on |
F3 | 243 | Light Power | 0x30, 0x31 | 31 off, 30 on |
F4 | 244 | Light Mode | 0x42, 0x43 | 42 normal, 43 night |
F5 | 245 | Light Brightness | 0x01 to 0x64 | 1 lowest, 64 highest |
F6 | 246 | Light Color | 0x00 to 0x64 | 0 warmest, 64 whitest |
F7 | 247 | Nightlight Brightness | 0x01, 0x32, 0x64 | 1 low, 32 medium, 64 high |
F8 | 248 | Off Timer | 0x31, 0x30 | 31 off, 30 on |
F9 | 249 | Off Timer Remaining Time | ? | |
FA | 250 | On Timer | 0x31, 0x40 to 0x43 | 31 off, 40 no melody, 41 to 43 melody select |
FB | 251 | On Timer Remaining Time | ? | |
FC | 252 | Fan Buzzer | 0x31, 0x30 | 31 off, 30 on |
FD | 253 | CtlOptSource | ? | |
FE | 254 | Melody | 0x40 to 0x43 | 40 no melody, 41 to 43 different melodies |
Unfortunately, I do not have any experience modifying the code for home assistant custom integrations, are you able to point me a starting direction for me to get started on the implementation?
Hi, I have KDK wifi ceiling fan too, the HA side can show exactly the current status of the fan(ON OFF status, reverse, fan speed) but I can only ON & OFF the fan through the HA, other features like reverse are not able to set from the HA interface. @scumbug how you able to control the (reverse) fan from HA interface?
I checked again and it seems that some of the data implemented in the pychonet library is incorrect, so I will make a correction.
@lysiong Sorry. It seems that the data structure differs depending on the device. Could you please submit the log obtained in debug mode here?
Also, is the Fan entity configured in your environment?
@nao-pon , first at all, thank you for reply, please find below for the log file, by the way, do you need my fan model?
KDK reverse trigger through HA.txt KDK reverse trigger through KDK apps.txt
Also, is the Fan entity configured in your environment? I didn't configure anything as the fan entity is auto-generated by ECHONETLite.
By the way, currently is that possible to set fan speed from the HA? I can see that ECHONETLite can detect current speed only.
Normally this integration would result in a Fan entity like this, but you don't see it?
(Note: This image is an example and is not generated by this integration.)
Normally this integration would result in a Fan entity like this, but you don't see it?
(Note: This image is an example and is not generated by this integration.)
I can't find this interface, this interface need to manually create it?
@lysiong Normally there is a Fan entity on the device screen and you can control the airflow etc. on the details screen. But there is no Fan entity in your screenshot, so there seems to be a problem.
Are there any errors in the HA log?
@nao-pon sorry for late reply as was busy on something, let me show u all the entitiy
both fan entity just show on off button, no speed control
is that possible got many different model of this KDK wifi control ceiling fan & they using different protocol to communicate. Anyhow, it still can show the correct status of the fan, I can control "on off" through HA, other features not controllable.
From the entities created in your environment, it seems that your device does not support changing the fan speed. However, since the direction and oscillation can be set, the entity details screen should look like the one below, but for some reason, it is not created correctly. This is a bit strange.
I don't have a fan on my Echonet device, so I can't verify it. Could you please put this integration into debug mode, restart HA, and attach the startup log for this integration?
By the way, I can control on off button only, other like direction and oscillation not able to control. But the integration did show the correct status of the direction & oscillation.
below is the start up log file, I filter out all the un-related & add a mask on my IP(x.x.x.x) home-assistant_echonetlite_2024-09-04T03-06-17.132Z.log
@lysiong I think I might have found the cause. There was a problem with the function settings of the Fan entity. I pushed the fix to the master branch. Can you verify using the master branch?
@nao-pon in the new HACS v2.0.1, I not able to find the master branch,
Oh, that's right. Do you have the Samba add-on installed? You can download the zip file, unzip it, and place the contents of custom_components /echonetlite in the same directory to apply it.
@nao-pon at last now it show the below interface after I change to master branch.
I can confirm that fan direction can be control at below button & also the fan speed. But fan speed suppose to increase/decrease by 1 to 10, not 10 to 100 as if I try set fan at 35, the fan speed won't set unless I set something like 10, 20, 30 then fan speed will be set.
Congratulations! Thanks for your validation! I'll check the fan speed.
@scumbug, @yeongjonglim, @lysiong I implemented the ceiling fan light function in my edge branch. However, since I cannot test it on an actual device, there may be bugs. If you can test it, please try my edge branch.
My edge branch can be deployed by HACS by adding my repository to the custom repository of HACS. If there is a bug, you can always revert to the regular version. Please try it.
Hi @nao-pon,
I have tested the integration for 3 different versions, I see that they are all achieving different results. Please find my comparisons below:
As seen from the image, this is the only component used to control the fan, where we have speed controls, oscillation and direction in a single view.
From the entity view, we can see that there are only 6 entities, there is no control to the fan buzzer anywhere, only viewing of its state. Direction and fluctuation can only be controlled using the main component.
From the entity view, I can see that the previous sensors are no longer in use, I am guessing that they are now replaced by the switch instead. However, these switches do not actually work, they still pretty much work like just a sensor, any toggles just trigger the buzzer and then the state remains, unless toggled from the main component screen. My guess for the switches alone don't work might be due to this. The buzzer payload is expected to always be included in the payload, hence probably hardcoded somewhere to always send on
as the payload, so the switch won't actually be useful. For direction and fluctuation, it may not work if not sent with some other payloads?
On top of this, I have also tried the latest master branch in the current repository, it seems to fail on import, hence unable to test further.
Last error log
Logger: homeassistant.setup
Source: setup.py:334
First occurred: 14:02:34 (1 occurrences)
Last logged: 14:02:34
Setup failed for custom integration 'echonetlite': Unable to import component: cannot import name 'get_device_name' from partially initialized module 'custom_components.echonetlite' (most likely due to a circular import) (/config/custom_components/echonetlite/__init__.py)
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/loader.py", line 1007, in async_get_component
comp = await self.hass.async_add_import_executor_job(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/loader.py", line 1067, in _get_component
ComponentProtocol, importlib.import_module(self.pkg_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/util/loop.py", line 200, in protected_loop_func
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/importlib/__init__.py", line 90, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 995, in exec_module
File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
File "/config/custom_components/echonetlite/__init__.py", line 28, in <module>
from .const import (
File "/config/custom_components/echonetlite/const.py", line 51, in <module>
from custom_components.echonetlite.fan import (
File "/config/custom_components/echonetlite/fan.py", line 10, in <module>
from . import get_device_name
ImportError: cannot import name 'get_device_name' from partially initialized module 'custom_components.echonetlite' (most likely due to a circular import) (/config/custom_components/echonetlite/__init__.py)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 334, in _async_setup_component
component = await integration.async_get_component()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/loader.py", line 1027, in async_get_component
self._component_future.result()
File "/usr/src/homeassistant/homeassistant/loader.py", line 1019, in async_get_component
comp = self._get_component()
^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/loader.py", line 1067, in _get_component
ComponentProtocol, importlib.import_module(self.pkg_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/util/loop.py", line 200, in protected_loop_func
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/importlib/__init__.py", line 90, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 995, in exec_module
File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
File "/config/custom_components/echonetlite/__init__.py", line 28, in <module>
from .const import (
File "/config/custom_components/echonetlite/const.py", line 51, in <module>
from custom_components.echonetlite.fan import (
File "/config/custom_components/echonetlite/fan.py", line 10, in <module>
from . import get_device_name
ImportError: cannot import name 'get_device_name' from partially initialized module 'custom_components.echonetlite' (most likely due to a circular import) (/config/custom_components/echonetlite/__init__.py)
First warning log
Logger: homeassistant.util.loop
Source: util/loop.py:77
First occurred: 14:02:34 (1 occurrences)
Last logged: 14:02:34
Detected blocking call to import_module with args ('custom_components.echonetlite',) in /usr/src/homeassistant/homeassistant/loader.py, line 1067: ComponentProtocol, importlib.import_module(self.pkg_path) inside the event loop; This is causing stability issues. Please create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue For developers, please see https://developers.home-assistant.io/docs/asyncio_blocking_operations/#import_module Traceback (most recent call last): File "<frozen runpy>", line 198, in _run_module_as_main File "<frozen runpy>", line 88, in _run_code File "/usr/src/homeassistant/homeassistant/__main__.py", line 223, in <module> sys.exit(main()) File "/usr/src/homeassistant/homeassistant/__main__.py", line 209, in main exit_code = runner.run(runtime_conf) File "/usr/src/homeassistant/homeassistant/runner.py", line 189, in run return loop.run_until_complete(setup_and_run_hass(runtime_config)) File "/usr/local/lib/python3.12/asyncio/base_events.py", line 674, in run_until_complete self.run_forever() File "/usr/local/lib/python3.12/asyncio/base_events.py", line 641, in run_forever self._run_once() File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1990, in _run_once handle._run() File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run self._context.run(self._callback, *self._args) File "/usr/src/homeassistant/homeassistant/setup.py", line 165, in async_setup_component result = await _async_setup_component(hass, domain, config) File "/usr/src/homeassistant/homeassistant/setup.py", line 334, in _async_setup_component component = await integration.async_get_component() File "/usr/src/homeassistant/homeassistant/loader.py", line 1019, in async_get_component comp = self._get_component() File "/usr/src/homeassistant/homeassistant/loader.py", line 1067, in _get_component ComponentProtocol, importlib.import_module(self.pkg_path)
The main fan control component is now unavailable.
The entity view also shows that all fan controls are gone. I have tested the light functionality, however, none of the control works.
Some error logs that I have captured while testing.
Logger: homeassistant.helpers.entity
Source: helpers/entity.py:942
First occurred: 14:12:29 (5 occurrences)
Last logged: 14:15:31
Update for light.common_fan fails
Update for switch.common_fan_fan_buzzer fails
Update for switch.common_fan_light_mode fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 942, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1300, in async_device_update
await self.async_update()
File "/config/custom_components/echonetlite/light.py", line 126, in async_update
await self._connector.async_update()
File "/config/custom_components/echonetlite/__init__.py", line 504, in async_update
return await self.async_update_data(kwargs=kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/echonetlite/__init__.py", line 534, in async_update_data
batch_data = await self._instance.update(flags, no_request)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/pychonet/EchonetInstance.py", line 147, in update
response = await self._api.echonetMessage(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/pychonet/echonetapiclient.py", line 344, in echonetMessage
await update_func(False)
File "/config/custom_components/echonetlite/__init__.py", line 548, in async_update_callback
await update_func(isPush)
File "/config/custom_components/echonetlite/light.py", line 299, in async_update_callback
self._set_attrs()
File "/config/custom_components/echonetlite/light.py", line 220, in _set_attrs
int(
TypeError: int() can't convert non-string with explicit base
@nao-pon, do let me know if any further testing is required. Thanks for the work!
@yeongjonglim Thanks for your validation. I've made some fixes to the light and fan entities in my edge branch. Please re-download and try again. The latest version at this time is 97da085.
Hi @nao-pon,
Thanks for the quick turnaround! I have tested the version 97da085.
The fan component is fixed.
The light component on the other hand
I didn't find any warning nor error log this time round.
I am trying to fix this. In the current edge, except for device On/Off and light Off, the value is sent after device On and buzzer On when sending. Please let me know how it goes.
Hi @nao-pon,
I have tested the latest edge version. Unfortunately, only light off is working, the other light related features are all not working. I can now hear that when adjusting light features, there are 2 beep sounds for a single action, however, there are no change in the result state.
That's unfortunate. It's expected that the light will beep twice when you operate it.
I think there is a specific data transmission for operating the light, but would you be able to find that from the data transmitted when you operate it with the KDK smartphone app by using SSNG (http://sh-center.org/sdk/ssng) or SSNG for iOS (http://sh-center.org/sdk/ssngios) mentioned in the first post?
Hi @nao-pon,
I have tried to use the SSNG app on iOS, but only able to turn off the light.
While using the KDK app, I am able to see the network payload sent as follow to the KDK server (I assume) to turn on the light:
{
"appliance_id": "[REDACTED]",
"method": "SET",
"packet": "0D0093014200FD010400FC013000FE01400080013000F0013500F2013100F1014100F3013000F6014400F4014200F5012D00F8043131FFFF"
}
I will need more time to pull up more payloads for different actions, do let me know if that is necessary. I can't really make any sense from the packet
information, you may have some more knowledge with that. Another guess is that the packet always includes all desired states that is controllable to the fan, so setting 1 state at a time is not going to work.
@yeongjonglim I've reordered and formatted the packets. As you say, it may be necessary to send all of this data at once.
0D00
93 01 42 00 # 0x93: "Remote control setting" Local: 0x41, Internet: 0x42 (Should be sent first)
80 01 30 00 # 0x80: "Operation status"
F0 01 35 00
F1 01 41 00
F2 01 31 00
F3 01 30 00
F4 01 42 00
F5 01 2D 00
F6 01 44 00
F8 04 31 31 FF FF ?
FC 01 30 00
FD 01 04 00
FE 01 40 00
I'll look into how to do that.
@nao-pon,
How about sending 2 at a time instead of everything? Even the packet I shared does not include all possible properties.
Well, can you try some transmit data on SSNG?
I am experimenting with sending some parameters together, try the latest edge.
@nao-pon, I would love to try from SSNG, however, I can't find any option from the iOS app to allow me to send multiple payload, only possible to set one EPC at a time.
I am also afraid that you might be right, all of the data may be required to be sent together to control the light. I have just tested, but no luck.
You can test this using the Windows version of SSNG or pychonet running in a python command shell.
Or try running the HA action (formerly known as service) "light on" with color temperature and light brightness.
Hi @nao-pon, thanks for the hint, I have managed to test out how the fan light should work. In summary, the payload cannot be sent individually, all fan related payload must be sent together with all the light related payload for all of the controls to work. Here is an updated table from my previous comment.
Hex | Dec | Description | EDT | Note | Required |
---|---|---|---|---|---|
80 | ?? | Fan Power | 0x30, 0x31 | 31 off, 30 on | Yes |
F0 | 240 | Fan Speed | 0x31 to 0x3A | 31 lowest, 3A highest | Yes |
F1 | 241 | Fan Direction | 0x41, 0x42 | 41 down, 42 up | Yes |
F2 | 242 | Fan Fluctuation | 0x30, 0x31 | 31 off, 30 on | Yes |
F3 | 243 | Light Power | 0x30, 0x31 | 31 off, 30 on | Yes |
F4 | 244 | Light Mode | 0x42, 0x43 | 42 normal, 43 night | Yes |
F5 | 245 | Light Brightness | 0x01 to 0x64 | 1 lowest, 64 highest | Yes |
F6 | 246 | Light Color | 0x00 to 0x64 | 0 warmest, 64 whitest | Yes |
F7 | 247 | Nightlight Brightness | 0x01, 0x32, 0x64 | 1 low, 32 medium, 64 high | Yes when F4 is 43 |
F8 | 248 | Off Timer | 0x31, 0x30 | 31 off, 30 on | No |
F9 | 249 | Off Timer Remaining Time | ? | No | |
FA | 250 | On Timer | 0x31, 0x40 to 0x43 | 31 off, 40 no melody, 41 to 43 melody select | No |
FB | 251 | On Timer Remaining Time | ? | No | |
FC | 252 | Fan Buzzer | 0x31, 0x30 | 31 off, 30 on | Yes |
FD | 253 | CtlOptSource | ? | No | |
FE | 254 | Melody | 0x40 to 0x43 | 40 no melody, 41 to 43 different melodies | No |
This is an example payload on the SSNG free data field that I have sent to turn on the light.
10,81,00,0A,05,FF,01,01,3A,01,61,09,80,01,30,F0,01,35,F1,01,41,F2,01,31,F3,01,30,F4,01,42,F5,01,32,F6,01,32,FC,01,30
For easy readability
1081 000A 05FF01 013A01
61 09
80 01 30
F0 01 35
F1 01 41
F2 01 31
F3 01 30
F4 01 42
F5 01 32
F6 01 32
FC 01 30
Additional note for F4 (light mode), whenever the value is 43, F7 (night light brightness) must be present with a valid value. F7 cannot be present when F4 (light mode) is having value 42. I am not sure why is this logic like this when the F3 (light power) does not care if other light related settings are there, that's why turning off the light was working. I also noticed that the fan settings must also be present at all times when setting the light values, I believe light settings do not need to be present when setting fan settings, hence fan was working previously.
Do let me know if there are any additional test cases you would like to see. I have tested all light power, brightness, temperature, night mode and night mode brightness.
@yeongjonglim Thank you for your detailed report. 👍 I will consider implementing it according to the specifications.
I haven't tested it at all, so I don't know if it works properly, but I fixed edge based on the reported specifications. Please try it. If you get an error, please let me know.
Hi @nao-pon, it's working now for most of the functions, here are some of the bugs I found.
It's not possible to set to any night mode, all night_low, night_medium and night_high are giving errors. Settings these do not give any effect now.
The light temperature value is reversed, the warmest on the component is actually the coolest temperature, while the coolest temperature is actually the warmest.
There is no buzzing sound when the light is adjusted. I propose to keep this functionality the same as the fan control.
I discovered a warning regarding the light temperature, I'm not sure if this is the right place to raise it.
Logger: homeassistant.components.light
Source: components/light/__init__.py:1172
integration: Light ([documentation](https://www.home-assistant.io/integrations/light), [issues](https://github.com/home-assistant/core/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+light%22))
First occurred: 21:31:30 (1 occurrences)
Last logged: 21:31:30
None (<class 'custom_components.echonetlite.light.EchonetLight'>) sets invalid supported color modes {<ColorMode.BRIGHTNESS: 'brightness'>, <ColorMode.ONOFF: 'onoff'>, <ColorMode.COLOR_TEMP: 'color_temp'>}, this will stop working in Home Assistant Core 2025.3, please create a bug report at https://github.com/scottyphillips/echonetlite_homeassistant/issues
5. Should we still keep these 3 settings. I have tested, all 3 of these do not have any effect on the fan. I suggest to remove all of them to reduce confusion.
<img width="1109" alt="image" src="https://github.com/user-attachments/assets/bbd5bb3b-10dd-4845-9171-e7e92569a3d4">
The light settings can be controlled through the main light component, while the buzzer does not seem to really disable or enable it anyway. On the other hand, shall we keep these sensor data for the fan and add those light related sensor data? I think it will be beneficial for ha to detect if the fan setting is changed from the remote control. These sensors were available on the very first version when it got released, but became unavailable immediately from the next version onwards.
<img width="1110" alt="image" src="https://github.com/user-attachments/assets/eec6a4d2-6b11-46d3-91ec-8d0cce0be0ca">
That's it, really thank you for all the effort!
I am trying to setup echonetlite for my ceiling fan that uses echonetlite protocol. but it seems that i am getting a keyerror when adding my device
any help or direction is greatly appreciated!