The result is the same in side the Home Assistant jail.
When I try to add rfxcom with automatic integration, I always have a timeout with /dev/cuaU0 - n/a, s/n: n/a.
When I try to add rfxcom manually (configuration.yalm), I saw 2 lines on home-assistant.log:
2021-12-28 09:26:24 INFO (MainThread) [homeassistant.setup] Setting up rfxtrx
2021-12-28 09:26:24 INFO (MainThread) [homeassistant.setup] Setup of domain rfxtrx took 0.0 seconds
But I have no icon that appears on configuration/integration. Is it normal?
Moreover, when I change USB ports by putting cuau0 instead of cuaU0 for example, I have the same as before…
Yes, I believe this is normal when an integration is configured through yaml
I happen to notice, when trying to add the integration myself, there is an option to Enter Manually. Try this if you want to manage it from the UI.
So, is it working now?
I happen to see your issue on GitHub as well. I’m not sure how much they can help because our jails are using FreeBSD, which is not supported by the devs. I’ve “watched” the issue anyways.
I have tried manually and automatically, but the result is the same. I no longer saw an error message but yet the RFXCOM does not seem to be working. I left on another attempt by migrating to Truenas Scale. I hope this time I can get it to work (although at the moment I still have USB problems).
Hi @troy
I’m not able to acces the “file editor” because my installation of HA is not encrypted http://192.168.1.220 but my external acces to HA is encrypted https://
Here is the path from outside: modem → Nginx Proxy Manager (reverse proxy + encryption) → HA jail (not encrypted).
Any idea how to fix that ?
Thanks
Sorry, I do not - But I don’t think there should be anything specific to using this plugin versus any other installation - Maybe someone else will be able to help.
I don’t expose anything to the interwebs, so all my just uses http
This a TCP/IP question, not one related to the TrueNAS Core plugin. In order to use File Editor, you will need to use https for local login.
Unfortunately, I don’t know how to do this, but someone should be able to answer the question if posted in a different thread. Before that, do a search in the docs & the Web for an answer.
Kinda sort of - it’s the right idea… This should work if you’re using the community plugin
iocage console $jail_name
# press 0 to exit menu
# Install the exchangelib library
service homeassistant install exchangelib
# or eventually upgrade it if it's already present but in an older version.
service homeassistant install exchangelib --upgrade
@tebra I forgot to mention… each time you need to recreate the HA virtualenv (for example, each year when the python changes) you’ll also need to reinstall exchangelib
During those situations you can reinstall exchangelib along with homeassistant
service homeassistant reinstall homeassistant exchangelib
Hi @troy
After upgrading home assistant today (using option 4 in the menu), home assistant fails to start.
I do not see anything in the logs, but when do a check_config (option 8 in the menu), I get the following message:
Home Assistant only supports Linux, OSX and Windows using WSL
Is there any workaround? perhaps reverting to an older version of home assistant?
You can either run a Plugin UPDATE from the TrueNAS UI to pull in the updated rc script - Or you can follow (pretty easy) instructions to update the file manually.
Well almost fixed… People are still reporting that Home Assistant fails to restart using the GUI but it does restart as expected if you use the console menu… Sorry, I know that’s really inconvenient but I’m not sure what I can do.
The best workaround at this point is to add a button to Home Assistant so you can trigger service homeassistant restart form the GUI
EDIT: Looks like this issue hit a few others as well
It seems there is a proper workaround for systemd but I’m not sure how to implement that in FreeBSD startup script.
It is a bit strange that the serivce start argument works but not the restart via GUI - I would consider it as a bug on HA side as it is not consistent experience. What do you think?
Doesn’t seem like a bug according to @balloob - At least in the issue I linked above
The process exited with code 100 . Your systemd script needs to be configured to trigger a restart when that happens. This has changed in 2022.2. We forgot to add it to the breaking changes, update coming later today.
But I think I figured out a workaround for us… Since we’re already using the FreeBSD daemon in the rc script, there are two possible options available. I’m about to test them now
-r Supervise and restart the program after a one-second delay if it
has been terminated.
-R restart_delay_seconds
Supervise and restart the program after the specified delay if it
has been terminated.
just uses http
