here is the community thread :
thats the reason why i am still using it as a custom
here is the community thread :
thats the reason why i am still using it as a custom
Yep, that works too. The change channel service uses the actual Harmony functionality to change channel (same as remote or Harmony app does).
So you can do (Harmony will then send change channel to correct device depending on activity, same as remote does):
harmony_channel_2: sequence: - service: remote.harmony_change_channel data: entity_id: remote.harmony channel: 2
or, for sending command instead of using device ID use device name (assuming 43446701 wold be device with name TV):
harmony_channel_2: sequence: - service: remote.send_command data: entity_id: remote.harmony device: TV command: 2
Issue in GitHub was closed
I do recall some of it. There seems to be an issue on HassIO itself. I have been working on another component (does not use web sockets if I recall correctly but keeps HTTP connection open) and similar issues on HassIO.
The errors being reported back are like āhost unreachableā etc, that really is the OS returning that it cannot open a socket to the host.
I think it is an issue in the OS or an issue within the Pyton libraries for HassIO itself. Harmony component here is then just a victim of the issue. Donāt like putting āblameā somewhere else, but here we do a call to connect and what is returned is an error from that call (which ends up being a OS error).
As you had the issues, if you can check out this updated one using XMPP. Would appreciate it.
will do, i really love the harmony component, together with xmpp
hmm, loaded the new file :
2019-03-14 21:51:13 ERROR (MainThread) [homeassistant.components.hassio] Testing configuration at /config
Failed config
General Errors:
- Platform not found: remote.harmony
Successful config (partial)
@ehendrix
this is the correct file? new PR
https://raw.githubusercontent.com/home-assistant/home-assistant/da89f0ffa0592077a415599218990861e6c00333/homeassistant/components/harmony/remote.py
as soon as i overwrite my older custom compotent remote.py file, i get th error below?
2019-03-14 21:51:13 ERROR (MainThread) [homeassistant.components.hassio] Testing configuration at /config
Failed config
General Errors:
what am i missing?
seems it doesnt install the new aioharmony requirement or something?
Yep, that is the correct file.
I would have expected some other kind of error if it would not install. Can you enable debug for homeassistant itself. See what it is failing on?
Must be somewhat specific to HASSIO I think. I tested multiple times on mine and it would download it successful. Also with it as a custom component right now.
Hopefully debug logs will show more info.
hmm, nothing to see actually in debug :
2019-03-14 23:12:05 DEBUG (SyncWorker_2) [custom_components.harmony.remote] Discovered host already known: (āHarmonyā, ā192.168.0.21ā, 5222)
and then this :
2019-03-14 23:12:10 ERROR (MainThread) [homeassistant.components.hassio] Testing configuration at /config
Failed config
General Errors:
- Platform not found: remote.harmony
Successful config (partial)
Hmmm, cause the message that discovered host is already known, that means that the Hub was already added.
There definitely should be more DEBUG entries then. If you did not enable debug as default, then make sure you have:
logger: default: warning logs: custom_components.remote.harmony: debug aioharmony.harmonyapi: debug aioharmony.harmonyclient: debug homeassistant.core: debug
ok, copy pasted your āloggerā stuff, so i have more logs: there
but when i do a restart, i do have nothing more then below:
2019-03-14 23:28:21 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=homeassistant, service=restart, service_data=>
2019-03-14 23:28:25 ERROR (MainThread) [homeassistant.components.hassio] Testing configuration at /config
Failed config
General Errors:
- Platform not found: remote.harmony
Successful config (partial)
2019-03-14 23:28:25 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=persistent_notification, service=create, service_data=title=Config validating, message=Config error. See dev-info panel for details., notification_id=homeassistant.check_config>
i cant do a restart when i load your new .py file, its stuck then
thats why i maybe dont see anything in logs?
A new comment on GitHub. : Python modules have to be available via pypi.
Thatās maybe the issue? Hassio isnāt downloading it?
Yeah, does seem something specific to Hassio, maybe it is not downloading it or so. Thatās a bummer ā¦ was a bit hoping you could test already.
Waiting for that dependent library (slixmpp) to get the fixes and go into pypi.
Probably someone else can test, but I think you can post this new stuff in the other thread about Logitech in the blog section, not this oneā¦
Anyway, sleep time now, already 00:00
I think that analysis is lacking. The only one mentioning host unreachable seems to be you and Hass.io has lots of TCP-based integrations that work well.
It seems more likely to me that the websocket implementation has an intermittent issue and it is only being observed on Hass.io because that is what everybody is using.
running hassio here, no issues in current versions. In fact, I havenāt had issues since the dark December when they removed xmpp. In fact, I have my ādevā version hassbian and my āreleaseā version hassio working at the same time most of the days both talking with harmony.
i dont have issues with websockets either, but i just from time to time had the undiscoverable issue
so i needed to resync to access the hub again
Here is for example where it was reported:
Now the exception reported there is what is being returned by the aiohttp library. Within the Harmony library it is just being caught and reported upon as is.
So it is not just me. Note also that up till now those that have been reporting issue seem to have been on HassIO.
I run it here at my home as well with 2 Harmony HUBs and itās probably one of the most stable connections I have (cause it is going to something inside the house as well and not to external servers).
Iāve worked with others who run with it without issues and they are not on HassIO.
Been seeing similar issues with another component (August) where itās network connection is flaky and errors returned back are OS errors like āHost unreachableā or āNetwork unreachableā.
See: Lot of delay in status, locking, doorbell ding sensor Ā· Issue #9 Ā· snjoetw/py-august Ā· GitHub
This user is also on HassIO.
Here is someone else reporting similar issue on HassIO with host unreachable for no apparent reason:
Now I know for Harmony and August components aiohttp is being used. For August it uses pooled connections (and thus connection to server is kept open) and Harmony is using web sockets (connection is being kept open).
The connections are working fine for a while and then suddenly they fail with errors like āHost Unreachableā. This error is being reported back by the aiohttp library and is an OS error (or aiohttp library is interpreting something else as this).
So far what I know is that the issue like this is being reported not only for Harmony, seems to be for component(s) that keep their connections open, using aiohttp, and seems to be only on HassIO.
Where exactly the issue is however I do not know. Might also be only on HassIO running on certain hardware only. Or be certain level of OS that includes a certain level of driver or so just a lot more common on HassIO?
Be it an issue in the OS, be it an issue within the libraries? I honestly do not know. But for some reason the socket is not only closed but opening a new one fails with errors like it is unable to reach the host.
I do not have HassIO so I am unable to dig deeper into it myself to troubleshoot.
I had asked others to see if they could run something on there to try to determine if things like ping etc. are failing at that same time or not.
in my case, i was running HassOS on esxi (vmdk image)
FYI,
Just did a specific search on aiohttp and network unreachable. Others have seen this issue as well, seemingly related when running in Docker or so:
Seems to be something related to IPv6 and suggested solution is to ensure socket is only opened for IPv4 (if I understand these parts right).