Closed Bl00d-B0b closed 9 months ago
Hi,
Yes this should work. Please be aware that the remote needs to be from the same remote_type and device_id as configured in the yaml "light" section, otherwise it will not work reliable.
Hello,
Yes, I know. I have several milight hub devices, and now make decision to move to your project. I have more than 50 different esphome devices.
this is my remote:
fut089 packet received (9 bytes): Raw packet: 31 81 3D 82 49 2C 04 47 D8
Decoded: Key : 31 b1 : 25 ID : 3364 Command : 01 Argument : 0D Sequence : 6B Group : 04 Checksum : 82
and this is my yaml. light:
and even, when I add logger.log to print me something... I do not see nothing in events or in a logs
not sure, if it's important, but when I send commands via esphome, the key value is 00 Decoded: Key : 00 b1 : 25 ID : 3364 Command : 05 Argument : 64 Sequence : 05 Group : 04 Checksum : E6
I am also using api: and ota: with encryption.
Ed
hello, can it be related to my issue (Mi - fut089 #20)? it seems the fut089 remote is not interpreted correctly.
A have a lot of different switches... OK, let me try with this one:
raw dump from wall switch on/off rgb_cct packet received (9 bytes): Decoded: Key : 6D b1 : 20 ID : 04F1 Command : 01 Argument : 09 Sequence : F5 Group : 04 Checksum : 1D
Changing my yaml to: light:
and this is raw dump from esphome, still key always: 00
rgb_cct packet received (9 bytes): Raw packet: 00 DB DD B4 66 D9 A5 61 A5
Decoded: Key : 00 b1 : 20 ID : 04F1 Command : 01 Argument : 09 Sequence : 17 Group : 04 Checksum : F2
but now i can see, than my switch start to receive events!!!.
looks like you right, it's an issue with fut089!
Ed
indeed: see the logs, when you use fut089: it say's: rgb_cct packet received (9 bytes):
and not fut089 packet received (9 bytes)
no no no...
in both ways it says correct...
Remote ON command: fut089 packet received (9 bytes): Raw packet: B0 28 20 0F 76 DC 83 71 E1
Decoded: Key : B0 b1 : 25 ID : 3364 Command : 01 Argument : 04 Sequence : B9 Group : 04 Checksum : 46
esphome ON Command: fut089 packet received (9 bytes): Raw packet: 00 D8 B0 3F 66 CC BC 61 9E
Decoded: Key : 00 b1 : 25 ID : 3364 Command : 01 Argument : 04 Sequence : 0E Group : 04 Checksum : 8B
As you can see, both shows correct remote ID
Hello,
Looks like I found a problem with fut089. Maybe you can check source code, where it's an mistake: I going to click on fut089 remote control groups, and show you raw packets:
turn ON Group 1 rgb_cct packet received (9 bytes): Raw packet: 2D 85 39 86 45 24 2A 46 69 Decoded: Key : 2D b1 : 25 ID : 3364 Command : 01 Argument : 01 Sequence : 11 Group : 01 Checksum : 15
turno ON group 2: rgb_cct packet received (9 bytes): Raw packet: 71 41 FD C2 09 E7 ED 09 EE
Decoded: Key : 71 b1 : 25 ID : 3364 Command : 01 Argument : 02 Sequence : 12 Group : 02 Checksum : DC
turn OFF group 2: rgb_cct packet received (9 bytes): Raw packet: DC FC CC 63 42 B3 85 3F 44
Decoded: Key : DC b1 : 25 ID : 3364 Command : 01 Argument : 0B Sequence : 13 Group : 02 Checksum : 71
Turno OFF group 1: rgb_cct packet received (9 bytes): Raw packet: 93 5C 27 6C 17 00 73 2E 85
Decoded: Key : 93 b1 : 25 ID : 3364 Command : 01 Argument : 0A Sequence : 14 Group : 02 Checksum : 04
And now, when I try to press turn off any of groups, including "0" it's always tries to turn off with zone 2. But If I enable zone 4 for example, then it's stacks on zone 4, does not care what zone I press to off.
Looks like sidoh/esp8266_milight_hub project also have same problem!
Ed
but where do you see: "fut089 packet received (9 bytes):" I guess on the sidoh/esp8266_milight_hub logs?
What do you see in the esphome logs (so this project) when you press On or Off on a fut089? Do you get: "fut089 packet received (9 bytes):" or "rgb_cct packet received (9 bytes):"
I get rgb_cct, so I think the device_type is ignored for fut089 and as such: incoming packets are interpreted as rgb_cct => wrong (Apperantly fut089 remotes use different codes).
BTW: my fut089 is working OK with sidoh/esp8266_milight_hub
The ESP module does a loop over all configured remote_types from the yaml file. "fut089" and "rgb_cct" are nearly similar, so when the module listens to "fut089" it will also receive "rgb_cct" and vice versa in the same module. When you want to have both remotes correctly determined I think you need 2 seperate modules and configure each with only 1 remote type in the yaml file.
Hello,
Looks like I found a problem with fut089. Maybe you can check source code, where it's an mistake: I going to click on fut089 remote control groups, and show you raw packets:
turn ON Group 1 rgb_cct packet received (9 bytes): Raw packet: 2D 85 39 86 45 24 2A 46 69 Decoded: Key : 2D b1 : 25 ID : 3364 Command : 01 Argument : 01 Sequence : 11 Group : 01 Checksum : 15
turno ON group 2: rgb_cct packet received (9 bytes): Raw packet: 71 41 FD C2 09 E7 ED 09 EE
Decoded: Key : 71 b1 : 25 ID : 3364 Command : 01 Argument : 02 Sequence : 12 Group : 02 Checksum : DC
turn OFF group 2: rgb_cct packet received (9 bytes): Raw packet: DC FC CC 63 42 B3 85 3F 44
Decoded: Key : DC b1 : 25 ID : 3364 Command : 01 Argument : 0B Sequence : 13 Group : 02 Checksum : 71
Turno OFF group 1: rgb_cct packet received (9 bytes): Raw packet: 93 5C 27 6C 17 00 73 2E 85
Decoded: Key : 93 b1 : 25 ID : 3364 Command : 01 Argument : 0A Sequence : 14 Group : 02 Checksum : 04
And now, when I try to press turn off any of groups, including "0" it's always tries to turn off with zone 2. But If I enable zone 4 for example, then it's stacks on zone 4, does not care what zone I press to off.
Looks like sidoh/esp8266_milight_hub project also have same problem!
Ed
The groupId is not always reliable determined from the received command. Therefore, in the function "RgbCctPacketFormatter::parsePacket" the groupId is determined on another way. So in the logging can be indeed incorrect, but the ESPHome light state will be correct.
Oh yes, you right. the same behavior on other remotes.
Ed
so, to be sure. Ed: can you confirm that with your FUT089 remote (and off course using this ESPHome integration), you can turn on and off lights using the remote, while keeping the state in home assistant correct ?
I mean: when you turn on a light using the remote, the status in Home Assistant changes to On and when pressing Off on the remote, the state in Home Assistant changes to Off ? I cannot get this last to work. ESPHome is interpreting the Off command from FUT089 wrongly (as Speed up, apperantly because it think's it's an RGB_CCT remote).
This is the log from the ESPHome integration when pressing Off on a FUT089 remote:
rgb_cct packet received (9 bytes):
Raw packet: 40 98 3F D8 26 96 1A 26 5F
Decoded:
Key : 40
b1 : 25
ID : 621D
Command : 01
Argument : 0A
Sequence : 60
Group : 01
Checksum : 88
[22:14:33][D][mi:128]: Received Milight request: {"command":"mode_speed_up"}
- remote_type: fut089
Hi Gert, I'm wondering how you can get a "rgb_cct" capture with a fut089 remote device, did you configure in the yaml light section only devices with "remote_type: fut089"? Or also "remote_type: rgb_cct"?
Hello,
when I configure only fut089 devices, I get no logs at all... Only when I add also an rgb_cct in the yaml, i get log's from the fut089 (and also from an rgb_cct that I actually have and that's also working OK). However: it seems that the packets from the fut089 are then seen as rgb_cct...
That's why I think there's somewhere an error where the yaml is not correctly parsed when it mentions fut089. But... my coding knowledge is not good enough to dive into (this) code I'm afraid...
BTW: in issue 20, you can find the yaml config I was using.
Hello,
for me is the same, I send you my ftu089 logs from another device, which is with native firmware, not esphome
I have no fut089 to test with, but it seems there was a problem in the ESPhome module when switching the listening mode from one remote type to the other. So it was listening always as rgb_cct. Can you test with the newest code from Github?
Hello, yeas I can. I always update my firmware. do I need to change my config to get newest firmware?
my last build: Dependency Graph |-- ESP8266WiFi @ 1.0 |-- ESP8266mDNS @ 1.2 |-- noise-c @ 0.1.4 |-- ArduinoJson @ 6.18.5 |-- SPI @ 1.0 |-- ListLib @ 1.0.0+sha.a250c6e |-- RF24 @ 1.4.5 |-- PathVariableHandlers @ 3.0.0 |-- StreamUtils @ 1.7.3
Hello, yeas I can. I always update my firmware. do I need to change my config to get newest firmware?
The "external_components" needs to be refreshed. These are cached, and normally once per day updated. Using "refresh: 0s" in your yaml "external_components" section should help but in my own case at home not.
Best is to delete the folder ".esphome\external_components" when you use a standalone ESPhome installation. The files will be retrieved again from Github then.
When using ESPhome as a plugin in homeassistant: in the latest versions its not possible to delete this folder by hand, I ended up by deinstalling and installing the ESPhome plugin in homeassistant. Settings remains with this action, but the cache folder is cleared.
Yes!!! It's working now:
[11:47:51][D][mi:067]: Received packet:
fut089 packet received (9 bytes):
Raw packet: E3 0C 08 B3 87 65 3C 9B 9C
Decoded:
Key : E3
b1 : 25
ID : 621D
Command : 01
Argument : 01
Sequence : 6F
Group : 01
Checksum : AD
[11:47:51][D][mi:128]: Received Milight request: {"state":"ON"}
[11:47:55][D][mi:067]: Received packet:
fut089 packet received (9 bytes):
Raw packet: FE A9 B5 37 CE AA 31 8E 9A
Decoded:
Key : FE
b1 : 25
ID : 621D
Command : 01
Argument : 0A
Sequence : 70
Group : 01
Checksum : D2
[11:47:55][D][mi:128]: Received Milight request: {"state":"OFF"}
Thanks!!!
Hello,
after i update firmware, I lost my device: WARNING milight-house-hub.iot.home.arpa: Connection error occurred: [Errno 104] Connection reset by peer WARNING Can't connect to ESPHome API for milight-house-hub.iot.home.arpa: milight-house-hub.iot.home.arpa: Connection closed (APIConnectionError) INFO Trying to connect to milight-house-hub.iot.home.arpa in the background INFO Successfully connected to milight-house-hub.iot.home.arpa in 0.005s WARNING milight-house-hub.iot.home.arpa: Connection error occurred: [Errno 104] Connection reset by peer INFO Successfully connected to milight-house-hub.iot.home.arpa in 0.012s
if i updete it withiout fu098, then it's works fine. but now I need to update it over usb :)
It's looks like device is overloaded or looped, uploading firmware by wifi after adding fu098 is working, sometime, but very very slow, and brokes in the middle...
@GertVanderstukken
what version you use to compile? looks like mine was not cleared in cache.
I upgraded the ESPHome Add-on for Home Assistant to 2023.11.4 this morning.
After that I upgraded ESPHome on the nodemcuv2 itself . Then I went into the yaml file, adapted some lines (in order to trigger a recompile), saved and installed => it did a full recompile and uploaded over WIFI.
how many switches you manage with single mcu? I have 6 in total, ad looks like it's a problem
Hello,
I can also confirm, now i can see fut089, BUT when I configure 6 remote controls: 5x rgb_cct+ 1x fut098 then device can't connect to esphome api. update via wifi failes. look like device is overloaded with cpu... not sure how to reproduce.
I assumes you can reproduce it configuring dummy devices. 3 devices are still working ok, but starting from 4-6 gets problems
this one I already receiving, when I have 4 light devices in my nodemcu
INFO Successfully connected to milight-house-hub.iot.home.arpa in 15.341s WARNING milight-house-hub.iot.home.arpa: Connection error occurred: milight-house-hub.iot.home.arpa: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2023.11.4). WARNING Can't connect to ESPHome API for milight-house-hub.iot.home.arpa: milight-house-hub.iot.home.arpa: Connection closed (APIConnectionError) INFO Trying to connect to milight-house-hub.iot.home.arpa in the background INFO Successfully connected to milight-house-hub.iot.home.arpa in 0.004s WARNING milight-house-hub.iot.home.arpa: Connection error occurred: milight-house-hub.iot.home.arpa: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2023.11.4). INFO Successfully connected to milight-house-hub.iot.home.arpa in 0.004s INFO Successful handshake with milight-house-hub.iot.home.arpa in 2.880s [16:01:16][D][api:102]: Accepted 192.168.11.1 [16:01:16][W][api.connection:091]: : Socket operation failed: HANDSHAKESTATE_SETUP_FAILED errno=11 [16:01:19][D][sensor:093]: 'WiFi Signal': Sending state 100.00000 % with 0 decimals of accuracy [16:01:22][D][api:102]: Accepted 192.168.11.1 [16:01:22][W][api.connection:091]: : Socket operation failed: HANDSHAKESTATE_SETUP_FAILED errno=11 [16:01:27][D][sensor:093]: 'Uptime': Sending state 42.04800 s with 0 decimals of accuracy [16:01:32][D][api:102]: Accepted 192.168.11.1 [16:01:35][W][component:214]: Component api took a long time for an operation (0.29 s). [16:01:35][D][api.connection:1089]: Home Assistant 2023.11.3 (192.168.11.1): Connected successfully
I have at the moment 2 lights as test (and group 0) on it. I will make a more complete config, probably this evening.
I use ESP8266 modules with a max of 4 light entities per module. In the past I've heard from users which are using ESP32 modules with around 20 entities without a problem.
Hello. 1 device is 4 lights entries. with 4 devices (16 lights) on esp8266 I see a lot of problems already :( as you can see above in my message.
It seems you are using encryption, this can be to heavy for this devices. Start with a stripped down config and see how far you can go. There is no rule how much devices can be handled, but they are cheap so consider multiple devices. Or try ESP32 devices they have much more resources.
Closed because the parsing is working with fut089 now.
Hello,
is it possible to read signal from remote control? my assumption it should be possible with: on_command_received:
but it's not working. Maybe I'ts my mistake.