search

hencou / esphome_components

Collection of own ESPhome components
25 stars 15 forks source link

Mi - fut089 remote control incorrectly parsed #22

Closed Bl00d-B0b closed 9 months ago

Bl00d-B0b commented 9 months ago

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.

hencou commented 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.

Bl00d-B0b commented 9 months ago

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

Bl00d-B0b commented 9 months ago

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

GertVanderstukken commented 9 months ago

hello, can it be related to my issue (Mi - fut089 #20)? it seems the fut089 remote is not interpreted correctly.

Bl00d-B0b commented 9 months ago

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

GertVanderstukken commented 9 months ago

indeed: see the logs, when you use fut089: it say's: rgb_cct packet received (9 bytes):

and not fut089 packet received (9 bytes)

Bl00d-B0b commented 9 months ago

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

Bl00d-B0b commented 9 months ago

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

GertVanderstukken commented 9 months ago

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

hencou commented 9 months ago

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.

hencou commented 9 months ago

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.

Bl00d-B0b commented 9 months ago

Oh yes, you right. the same behavior on other remotes.

Ed

GertVanderstukken commented 9 months ago

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"}
hencou commented 9 months ago
  • 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"?

GertVanderstukken commented 9 months ago

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.

Bl00d-B0b commented 9 months ago

Hello,

for me is the same, I send you my ftu089 logs from another device, which is with native firmware, not esphome

hencou commented 9 months ago

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?

Bl00d-B0b commented 9 months ago

Hello, yeas I can. I always update my firmware. do I need to change my config to get newest firmware?

Bl00d-B0b commented 9 months ago

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

hencou commented 9 months ago

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.

GertVanderstukken commented 9 months ago

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!!!

Bl00d-B0b commented 9 months ago

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 :)

Bl00d-B0b commented 9 months ago

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...

Bl00d-B0b commented 9 months ago

@GertVanderstukken
what version you use to compile? looks like mine was not cleared in cache.

GertVanderstukken commented 9 months ago

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.

Bl00d-B0b commented 9 months ago

how many switches you manage with single mcu? I have 6 in total, ad looks like it's a problem

Bl00d-B0b commented 9 months ago

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

Bl00d-B0b commented 9 months ago

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

GertVanderstukken commented 9 months ago

I have at the moment 2 lights as test (and group 0) on it. I will make a more complete config, probably this evening.

hencou commented 9 months ago

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.

Bl00d-B0b commented 9 months ago

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.

hencou commented 9 months ago

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.

hencou commented 9 months ago

Closed because the parsing is working with fut089 now.