search

cl0rm / eiscp_bridge

add WiFi Control to older onkyo AVRs. Converts the RS-232 protocol into onkyo's own Ethernet protocol.
8 stars 0 forks source link

Compatibility with Home Assistant 2024.9 #3

Open cl0rm opened 1 month ago

cl0rm commented 1 month ago

currently it seems this is broken on Home assistant 2024.9 (at least for me it doesn't work anymore). The UDP discovery packets should be sent already. Maybe its just my configuration, maybe it's a bug or a thing where the native Ethernet receivers react in a different manner.

cross reference (this issue is related to all ("native ethernet") onkyo receivers): https://github.com/home-assistant/core/issues/125768

I will close this issue and inform you / update the code when I find the culprit.

cl0rm commented 1 month ago

The problem seems indeed to be the discovery. It is not in general incompatible with 2024.9. Sometimes it works. The component used, onkyo-eiscp, seems to only detect it sometimes. (onkyo.exe --discover) only sometimes returns the receiver name. (onkyo.exe --host 192.168.1.15 volume=45) however works reliably.

Maybe discovery only works AFTER sending at least one command. I have to do further testing.

ManiacDC commented 1 month ago

I had a bug in my eiscp_relay, which is loosely based on your code. I forgot to check if you had the same bug, it looks like you may. Here's my bug fix: https://github.com/ManiacDC/eiscp-relay/commit/c3c3330888dc022f4549f2863199eeaf4411435a

May or may not be related...

cl0rm commented 1 month ago

Thank you very much for the information. This should not affect my code. You seem to have sent an ASCII one for the "version" byte instead of an actual one (0x01). I do send this correctly (see eiscp.c, line 61).

This bug (if it even is a bug) seems to be in the UDP portion of the code. Once discovered, it seems to work across home assistant reboots. It might be that after a reboot of the ESP device, the UDP task does not kick in until at least one TCP packet was sent. That's at least how it looks like. (And that would indeed be possible, as this could does not use multithreading. If the main loop is stuck at tcp_task, discovery would fail)

Edit: I have again carefully looked through the code, but none of the functions should be blocking.