Home Assistant Core -- TrueNAS CORE Community Plugin

Community Guides
396

Yes… I would think 10-15 minutes should be plenty but this depends on hardware and number of integrations. I’m hopeful this might work - A user on GitHub was able to upgrade from a version that was still using python 3.7. We can check some things, but I don’t want to start doing to much, just yet

Log back in to the jail, let check the status and see if how if / how many errors are in the logs

iocage console $JAIL_NAME
# Press 0 to exit menu
service homeassistant status

If it’s running, try this to show the last 100 line of the log file

service homeassistant logs -t 100

If it’s not running - do a config check_config

service homeassistant check_config

Hey @Tromperie - Can you please say about how long you had to wait

397

It is running now. But I think I waited like 20-30 min. (hard :joy:) .the issue is resolved. All looks good… Thanks Troy.

1 Like
398

:sweat_smile: – That is a wait indeed…

Lets get rid of this, since it not typically needed… I can just trigger this myself when it is.

To remove that, use

iocage console $JAIL_NAME
# Press 0 to exit menu
sysrc -x plugin_clean_install_service
1 Like
399

About ten minutes, but my CPU is a 4 core 8 thread Xeon with 16G of RAM.

1 Like
400

@troy,
Because of deprecation of automation IDs, I deleted the ZFS snapshot automation and tried to go through the process again. I ran into an error in the /truenas_api/zfs_snapshot.yaml with this;

unknown tag !<!input> at line 32, column 36:
dataset_name: !input dataset_name
^
Frank

401

:thinking: I’m not sure @Tromperie - I just triggered mine manually a few times, without error

This is from from my Home-Assistant logs

2021-03-11 15:26:17 DEBUG (MainThread) [homeassistant.components.rest_command] Success. Url: http://10.10.1.10/api/v2.0/zfs/snapshot. Status code: 200. Payload: b'{"dataset":"nvme/apps/homeassistant","name":"automated_backup_2021.03.11_15.26"}'
2021-03-11 15:27:01 DEBUG (MainThread) [homeassistant.components.rest_command] Success. Url: http://10.10.1.10/api/v2.0/zfs/snapshot. Status code: 200. Payload: b'{"dataset":"nvme/apps/homeassistant","name":"automated_backup_2021.03.11_15.27"}'

and on TrueNAS, I confirmed the snapshots were created

troy@core $ zfs list -r -t snapshot -o name,creation nvme/apps/homeassistant
NAME                                                         CREATION
nvme/apps/homeassistant@automated_backup_2021.03.11_15.26  Thu Mar 11 15:26 2021
nvme/apps/homeassistant@automated_backup_2021.03.11_15.27  Thu Mar 11 15:27 2021
402

I had MQTT up and running worked great. Had to turn off my NAS to move it to another location in my house. Now MQTT is refusing to start. Tried uninstalling and reinstalling, and it is still refusing to start.

I get:
1615587178: The ‘port’ option is now deprecated and will be removed in a future version. Please use ‘listener’ instead.
1615587178: Error: Unknown configuration variable “-e”.
1615587178: Error found at /usr/local/etc/mosquitto/mosquitto.conf:10.
/usr/local/etc/rc.d/mosquitto: WARNING: failed to start mosquitto

I have made my config, look like the one posted previously with all the code around the time of adding in Usr/Pwd’s and that hasn’t helped. It’ll take away the unknown variable and the warning, but still wont start. I set it all up a few days ago and am doing the exact same as I did then. (as far as I can tell)
Any help would be greatly appreciated.
Version:

TrueNAS-12.0-U2.1

403

Same here with Mosquitto issues. Have removed the jail and rebuilt with no luck.

404

Have had to wake up a spare Pi and just run that as my MQTT server. MQTT is so important as a backbone to HA.

405

It looks like the FreeBSD mosquitto port has been updated to 2.0 or later. This version has some breaking configuration and command line changes. See the blog post here: https://mosquitto.org/blog/2020/12/version-2-0-0-released/
I have not updated mine yet, and I’m running mine in a raw jail not a TrueNAS plugin, so I don’t know exactly what it will take to fix. I expect a minor change to the config file and maybe the startup script.

I’ll post notes here if I get mine updated and working.

1 Like
406

@DoucheCanoe and @elyobelyob sorry for the delayed response… I think found the problem

Looks like the variable name for the pidfile has changed. Please give this a try…

EDIT – See here instead

407

Thanks @jkhii just what I needed to see

408

Hi, thanks for taking a look.

I made the change, but unfortunately it’s still not starting.

Is there a log file I can reply with useful info from?!

In the meantime, I’ve popped back to my spare MQTT server …

Thanks

Nick

409

I see it now - I don’t think the pid-file was even being used before…

Rather than have you try editing more files, please give this a try

  • $ZPOOL is the pool where you have activated iocage
  • You may use any valid --name JAIL_NAME to name this jail
cd /mnt/$ZPOOL/iocage/.plugins/github_com_ix-plugin-hub_iocage-plugin-index_git
iocage fetch -P mosquitto.json --branch test-quick-fix --name JAIL_NAME
410

Watching you edit your post while I was typing into shell was interesting…

Its currently running now. Thank you.

1 Like
411

This seems to have worked for me. I have a second jail now which started up and responded to a test.

root@mosquitto-1:~ # mosquitto_sub -d -t /dev/test
Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending SUBSCRIBE (Mid: 1, Topic: /dev/test, QoS: 0, Options: 0x00)
Client (null) received SUBACK
Subscribed (mid: 1): 0

I’m still on my Pi spare for the moment, so if you want me to destroy my current jail and build again from scratch, happy to help.

1 Like
412

If your current jail is broke, then I suppose there is nothing to loose?

You can just rename your test jail to the current jail’s name, after it has been destroyed.

iocage destroy -f $original_jail_name
iocage stop $test_jail_name
iocage rename $test_jail_name $original_jail_name
iocage start $original_jail_name
1 Like
413

I destroyed it and recreated.
All back up and running.

Now on the branch, right? Not that I’ll be updating anytime again soon …

Thanks

414

Actually, no. Using --branch only works on the command line, and for the initial installation. When you run the update (or upgrade) it will use it’s default behavior. Currently the way iocage works, is to to look for a branch that matches the release - which at this time, would be the 12.2-RELEASE - if that branch does not exist it will use the master branch instead.

For the mosquitto plugin, I do not have separate release branches, everything typically installs and updates from the master branch.

Anyway, I pushed these changes over so this will install again from TrueNAS UI and running a Plugin UPDATE won’t break it, if you installed using --branch test-quick-fix

1 Like
415

Hi Troy,
I didn’t explain clearly enough about the daily snapshot. Yours will work because it is already set up. The problem is that the blueprint will not create an automation because of the error I posted.

unknown tag !<!input> at line 32, column 36:
dataset_name: !input dataset_name

An automation is written to the automations.yaml, but it does not appear in the automations list and is, therefore, not triggered. It was only after checking both yamls that I found this error message while looking at the file in File Editor. Should I post this to the general Configuration forum for yaml experts to give advice?

Also, after updating MQTT to 2.08, my single Tasmota switch gives this error message in the console: Connect failed to 192.168.0.31:1883. It was working before the update and I can log into the Tasmota webpage. I checked the config file of mosquitto and see you set it to allow anonymous false, so I changed it to true and added a username and password. Still no go. See edit below.

Regards,

Frank
Edit: Sorry Troy I stuffed that up badly. You did set anonymous to TRUE. I set it to FALSE to try a username and password but that did not work, so I set it back to TRUE.