Windows Hass Workstation was briefly configured—but then lost its config, and the UI repeatedly crashes

I’m probably confused about a lot of stuff because all of this is new to me—Home Assistant, MSQTT, etc. (I’m one of those people who suddenly discovered the changes to Google Home/IFTTT integration meant I needed to find new local alternatives to IFTTT smarthome integration).

I’m running Home Assistant 2022.8.7 OS 8.5 as a VM under Unraid. (I’ll probably get a dedicated Raspberry Pi so it isn’t tied to the PC if I get everything working.)

The LIFX and cloud integration seemed to go along fine.

But I wanted to set it up so our indicator light (a LIFX bulb) that turned red when my husband’s webcam activated continued to do that, and I read that MSQTT and Hass Workstation were the way to go, so I followed the instructions here.

I did create an mqttuser user in Home Assistant settings first, and supplied its username and password to the MQTT Integration (I had to “Reconfigure” to do that, as it initially set itself up to use the username home-assistant, not mqttuser).

Things seemed to go okay until I got to the Windows side, where initially all the indicators (broker connection and background service) had turned green after I configured them including enabling autostart of the background service.

But when I went to create my Sensor and hit Save, nothing happened. The Sensor Add box closed, but nothing appeared in the UI and I couldn’t use the Sensor. So I restarted the Hass Workstation UI and not only was there no Sensor but the broker configuration was all gone and it didn’t show the background service (which I could still see running in Windows’ Task Manager) as detected anymore. Re-entering my info didn’t work—the broker connection stuff turned green, but it still had no background service and shortly thereafter the UI crashed.

That was when I realized that restarting from the taskbar might not be the same as quitting and restarting. So I started Hass Workstation Service via the Start Menu. This time something was a little different—for a fraction of a second before the UI opened, a little interstitial window “Launching Application…” appeared.

But still, the configuration was blank and it detected no Background Service—it said, “The UI will crash after a while if the service wasn’t started first. Please make sure the service is running. If you used the installer and you are seeing this message, please check if your antivirus might be interfering.” And, true to promise, every time it starts now, after about 90 seconds the UI crashes, and restarts with no config and no background service detected.

(Windows is another thing I don’t know a lot about, I’m a Linux/Mac person. But I checked “Windows Security” → “Virus & threat protections”, and it doesn’t show any activity since before I started this.)

So I loaded the broker config into a Note I could quickly paste into and tried again. But even if I managed to enter everything and hit “Save” before the UI crashed, nothing happened—unlike that first time, nothing turned green, and on reload nothing I’d typed was saved.

Meanwhile, that same original process is in Windows Task Manager, seemingly chugging along, the UI just can’t detect it for whatever reason.

I’m assuming the way I restarted the UI after it didn’t add my Sensor really broke it in some fundamental way. But re-downloading the installer didn’t help, the same background service is there and it still behaves the same way. I couldn’t find “uninstall” instructions for Hass Workstation, so I don’t know if I should kill the background service in Task Manager, or somehow do a clean reinstall (how?), or what?

The only other variance I can think of is that, since it’s my husband’s Windows account (and I read in the GitHub issues that you can’t easily setup Hass Workstation for multiple Windows users), I used his Home Assistant login to install and set everything up on the HASS.io side except for creating the mqttuser account (since as Owner only I can do that).

The log messages for the Mosquitto broker show nothing remarkable that I can see except “unknown” connections to port 1883 being opened and immediately closed (Client <unknown> closed its connection) every two minutes continuously since I first looked after install Hass Workstation. Less frequently there are identified connections, that have mostly been closed but that at least once timed out. See below.

The only other strange thing (or maybe perfectly normal—I don’t really know how HassOS works after all) in the logs below are that, while homeassistant.local corresponds to the IP QEMU KVM says it supplied to HassOS (172.16.41.39), and if I use the Terminal Add-on to run “ifconfig” I see the local IP address of 172.30.33.0, the below messages all come from 172.30.32.1 (the identified connections) and 172.30.32.2 (the <unknown> ones). Neither the 172.30.32 nor 172.30.33 subnets are addressable by devices on my LAN. So I’m assuming either this is a big clue—or just how HassOS always works. :wink:

I appreciate any assistance and apologize for the verboseness—being a newbie I don’t know what’s significant, and what is not!

2022-09-03 16:22:06: New connection from 172.30.32.2:56988 on port 1883.
2022-09-03 16:22:06: Client <unknown> closed its connection.
2022-09-03 16:22:16: New connection from 172.30.32.1:46067 on port 1883.
2022-09-03 16:22:16: New client connected from 172.30.32.1:46067 as 6i0Owp9tiUy6AVpba8k7uZ (p1, c1, k60, u'mqttuser').
2022-09-03 16:22:17: Client 6i0Owp9tiUy6AVpba8k7uZ disconnected.
2022-09-03 16:23:17: Client 7Ap7AY96qZ3M6bfzUQCvgU closed its connection.
2022-09-03 16:23:17: New connection from 172.30.32.1:42671 on port 1883.
2022-09-03 16:23:17: New client connected from 172.30.32.1:42671 as 1ZrvtlTmpVOjb3KKDGbSdz (p2, c1, k60, u'mqttuser').
2022-09-03 16:24:06: New connection from 172.30.32.2:57434 on port 1883.
2022-09-03 16:24:06: Client <unknown> closed its connection.
2022-09-03 16:26:06: New connection from 172.30.32.2:57108 on port 1883.
2022-09-03 16:26:06: Client <unknown> closed its connection.
2022-09-03 16:28:06: New connection from 172.30.32.2:54440 on port 1883.
2022-09-03 16:28:06: Client <unknown> closed its connection.
2022-09-03 16:29:31: New connection from 172.30.32.1:47892 on port 1883.
2022-09-03 16:29:31: New client connected from 172.30.32.1:47892 as 0df51920a86d4a7bb49d5711630171a4 (p2, c1, k30, u'mqttuser').
[…Continued unknown immediately dropped connections every 2 minutes…]
2022-09-03 16:52:31: New connection from 172.30.32.1:47309 on port 1883.
2022-09-03 16:52:31: New client connected from 172.30.32.1:47309 as 2iz1WAr7QJsAVXC9TtoM17 (p2, c1, k60, u'mqttuser').
2022-09-03 16:54:05: Client 1ZrvtlTmpVOjb3KKDGbSdz has exceeded timeout, disconnecting.
2022-09-03 16:54:06: New connection from 172.30.32.2:53810 on port 1883.
2022-09-03 16:54:06: Client <unknown> closed its connection.

Use Hass Agent instead. I had loads of issues with Hass Workstation too.

And our very awesome Lewis - has a great video on using it, here:

As for the 172.X addresses, that is how docker works, each container gets an internal only IP address which allows docker containers to communicate with each other, without necessarily being contactable by the rest of the world. The IP address you should use is the IP address assigned to the VM, not to the docker container running the MQTT broker.

Thanks! Since you tried it, do you know I can uninstall it? The autostart seemed to get enabled even though it otherwise doesn’t work—the service is still there in the background when I rebooted Windows.

I manually opened the services in windows and stopped the service from running, And then set it to disabled. And THEN uninstalled the software from inside the add remove programs part of Windows. It didn’t seem to fully remove until I did that.

One quick warning about Hass Agent - the satellite service works great, until Windows installs an update, and then it seems to not run at boot, until you go in and re-install the service again. So try not to rely on using the satellite service part if possible.