Yes, and I’m a new HA user installing on docker but you’ll run into the same issue I’ve got when you try to configure anything that phones in via MQTT. You’re looking at the issue from a mile high macro view of the server OS and virtualization, and I’m trying to advise you of a micro level problem that’s potentially a huge headache that you’ll have to get through. You may or may not need it, but 40% of installations use it and it’s not straightforward to get working.
But you’ve already dismissed me since I’m also new and currently working through a problem, and that’s fine. Later!
Welcome! There are several threads in these forums about migration from Homeseer to HA - be sure to search for them. I’ve never regretted making the jump several years ago.
If you choose either of the following two installation methods, it will be straightforward to install and configure an MQTT client and broker (if you need it):
Home Assistant OS
Home Assistant Supervised
The recommended choice is Home Assistant OS.
The MQTT client portion is provided by the MQTT integration.
The MQTT broker portion is provided by MQTT Broker Add-on.
The other two installation methods are:
Home Assistant Container (pure Docker-based version)
Home Assistant Core (python-only version)
Both Container and Core are considered to be advanced installation methods and assume the installer is familiar with the additional knowledge and administration required.
They support the MQTT integration (which allows Home Assistant to be an MQTT client). However, neither supports any Add-ons so you don’t have the ability to conveniently install an MQTT broker (like in OS and Supervised). That task is left up to you, including configuration to permit the client (Home Assistant) to login to the broker. It’s this step that tends to be challenging (but is trivial if you’re using OS/Supervised with the MQTT Broker Add-on).
AJ, I used HomeSeer for nearly 20 years before moving to Home Assistant. I started by running VirtualBox on the Windows machine that ran HomeSeer for nearly a year. I also ran a second instance in VirtualBox on my personal workstation as a “dev” instance. No issues with that method here.
Yes. I’ve done that between the 2 instances I mentioned above.
I’m now running both Prod and Dev instances on 2 Proxmox nodes in High Availability. The VM snapshot and backup options in Proxmox make managing HA operations and upgrades much easier, IMHO.
Same hardware specs for my HomeSeer Windows machine. I never gave the Home Assistant VM more than 4GB of memory and never had a problem with the collections of Add-ons I choose to run.
Good luck with your migration if you choose to make it. I can easily say I don’t regret the change at all. There is a learning curve to understand the architecture and patterns that work well in Home Assistant. Don’t make the mistake of trying to simply convert HS automation logic to HA automation logic. They don’t compare.
There are tons of resources on the forums but be careful to check post timelines. Home Assistant has changed significantly in the short 2 years I’ve used it. Check any advice against current documentation. The documentation is much better than HS, again IMHO.
@Tinkerer Where possible, I’ll be updating the firmwares so no issue there. The Z-stick 7 has in fact just arrived. I noticed on the Aoetec site, they have instructions on how to pair the z-stick up to HA.
I did also however find a HA article to avoid the EU version due to performance issues - is this still an issue given mine would be EU being in the UK?
PecosKidd Thanks! I’m probably treating this as starting from scratch albeit with devices already included and so I’ll exclude/include but nothing is being “migrated” from HS in this case.
@123 I have to say this is the bit that confuses me about the whole MQTT. And maybe this is where I apologise to tekno-yanqui as I had no idea what the relationship was with MQTT and HA.
Either way, my understanding is the fact I’ve chosen to go via Proxmox or VirtualBox means I am going down the Home Assistant OS route albeit on a VM.
Thank you @mterry63 - for some reason, I seem to recognise your name from HS days - maybe a Goodbye HS, Hello HA type thread? - maybe I’m just imagining things
I’m going to try and get Proxmox installed along with HA tonight on the machine and see how that goes leaving the current VB version as is on my laptop as a Dev system.
I was thinking a parallel install but I’ve got enough corruption currently that I either “reset” both HS and get HA in or just concentrate on one - I think I’ll go for HA knowing if it all goes pear shaped, I’m skilled enough with HS to spin up a new VM and get going.
re spec, I suppose I could either give it the 8GB or so or start at 4GB and upsize if needed. I’m looking around my spares to see if I can find any 16GB modules as I think it can handle 32GB in which case I can future-proof and assign more now.
As for HS logic - agreed and I think I’m finding this more and more that there are tons of articles that are old and outdated. Is there a general rule of thumb? ie last 6-12 months are ok?
The biggest events stack I have in HS are around motion sensors switching on lights, off after x mins if no motion and also if the manual switch is flicked on/off/on, it temp disables the auto-off from no motion (long bath for instance where not much movement)
Other than that, I have nothing complex that HA could not do for me I don’t think.
I’m feeling more comfortable with your history of 20 years with HS and yet being happy with HA that I don’t feel I need to ‘test’ the z-wave but go straight into building a prod environment. Don’t worry I won’t hold you accountable if it does not work:- )
@skykit
Compared to common scripting languages, what Home Assistant uses can be perplexing on first glance.
It uses a combination of two other open-source software projects: YAML and Jinja2.
YAML is a markup language (typically used for defining configurations) and Jinja2 is a templating language (with python-like syntax).
Think of YAML being used to create a form with fields and Jinja2 used to (optionally) compute values for those fields.
alias: example automation
id: example_abc123
description: Report which door opened but only during the night.
triggers:
- trigger: state
entity_id:
- binary_sensor.front_door
- binary_sensor.rear_door
- binary_sensor.garage_door
from: 'off'
to: 'on'
conditions:
- condition: state
entity_id: sun.sun
state: below_horizon
actions:
- action: notify.persistent_notification
data:
message: "The {{ trigger.to.state.name }} just opened."
Initially, use the Automation Editor in Visual mode and then switch it to YAML mode to see the code it automatically generated. Continue working this way and eventually you will become comfortable with the code’s structure.
At some future date, you may wish to compose the automation entirely in YAML mode because Visual mode doesn’t currently expose all of Home Assistant’s available automation features (most, but not all).
BTW, to share an automation, you just copy an example from the forum and paste it into the Automation Editor while it’s in YAML mode.
FWIW, more advanced users avoid the Automation Editor entirely and compose their automations with a text editor like VS Code (with some plugins).
6 months should be good, 12 months you may have to validate or expect to do some minor mods. Most recently the so-called “service-call” command was changed to “action” but both are acceptable at the moment (I believe). the HA Devs do give a clear timeline for depreciating old ways of doing things.
You’ll have to get used to the scheduled updates cycle of HA. It moves along at a quick pace, which can be a double-edge sword. At least you don’t have to upgrade.
For Z-wave, some advice - Start with the Z-wave-JS UI add-on, not the “core” (HA developed and maintained) add-on. You’ll appreciate the extra features. I moved my Z-wave network between platforms without change, just moved the controller from one system to the other “as-is”. No issues with that.
MQTT is another protocol available to Home Assistant which can help connect other technologies/devices. If you don’t use it now (sounds like you don’t) you can visit it at your leisure. I had a MQTT integration and broker in use with HomeSeer (Tasmota devices), so I just kept the broker as-is and moved them to Home Assistant. The great thing is there are hundreds if not thousands of integrations that are all free, not a per integration cost like HomeSeer.
You only need it if you intend to have Home Assistant communicate with any devices you have (or other systems) that support MQTT. For example, I still use my former home automation software (trusty old Premise) in addition to Home Assistant. The two communicate via MQTT (Premise supports some legacy devices I have for which there are no integrations in Home Assistant).
The questions in your first post didn’t mention MQTT, so having it introduced unsolicited in a reply was understandably puzzling. Just know that its installation and configuration is easier if you use the recommended Home Assistant OS installation method.
Join the HA Discord and ask the Z-Wave gurus over in the #related-tech channel - I switched fully to Zigbee a while back and haven’t kept fully on top of what’s going on in the Z-Wave world.
@skykit
Be advised those instructions aren’t needed (and don’t apply) if you install the MQTT Broker Add-on on Home Assistant OS (or Home Assistant Supervised).
Hi all
Thank you again for all the responses. Took the advice and setup the machine with ProxMox along and have setup HA.
To be fair, I was expecting it to be a learning curve but so far, all up and running BUT…
Despite the setup taking under an hour in total… I’ve been stuck with the z-wave setup.
As per @mterry63 recommendation, I’m trying to setup the whole z-wave UI thing. First of all, the github URL just would not work stating it was already installed.
I ended up finding a thread to simply use http and not https and sure enough, that worked allowing me to find and setup z-wave UI.
As far as I know this is working - I can see the new z-wave stick and it correctly reports back the firmware version.
This is where I’m stuck - I then went into integrations, added Z-wave ensuring the supervisor checkbox was unchecked. It asks for a URL so I stick in ws://a0d7b954-zwavejs2mqtt:3000 and I’m getting failed to connnect.
I’ve reinstalled the z-wave UI, tried a different port, but always seem to get the same Failed to connect.
Have I missed something obvious and critical here?
I have two locations, each with a development and a production installations. I chose to run my VB headless under server Ubuntu linux which frees up a lot of system resources. I purchased refurbished PC for the hardware. I allocate 2 or 4 GB to the VMs. My problems with this set up have been operator error.
I did have a challenge with getting the USB connected to the VM in that the /dev/ttyUSBx would change numbers (x) depending on the the number of USB devices plugged into the box at boot. This was resolved by using the alternate name for the USB device as opposed to /dev/USBx. (I wish I could give a link, but it seemed to happen automatically when I set up the VM.)
My reason for being with HA is that it is not cloud based. This allows me to be somewhat in control of my security and privacy … I’ve been burned badly once by one cloud company and dodged the bullet by another.
The cummunity is genrally good, and, as you can see, helpful.
Yup - thats the document that I followed and spent a good amount of time going through it again and again to ensure I did.
I’ve been out most of the day so only got a chance to see your response but back on it now - Decided despite it being against every developer fibre in me, to ditch the VM and start again taking it a bit slower this time.
I was all good with it but now slightly more confused with the second link you sent.
The first and all others online state the serial port should be set to /dev/ttyUSB0
But your second link states NOT use use this one and instead, use the /dev/serial/by-id one:
Do not use /dev/ttyUSBX serial devices, as those mappings can change over time.
Instead, use the /dev/serial/by-id/X serial device for your Z-Wave stick.
ok success! all up and running with Z-wave.
Untested any further than having the Z-stick 7 added with the Z-Wave JS UI add-on + Z-wave Integration as I need to start excluding devices from the old stick and including them on the new.
I guess I’ll never find out the cause of why I could not progress yesterday or what if anything was different today. But the “fix” seemed to be a complete rebuild of the HA OS VM in Proxmox.
FYI. I went with /dev/serial/by-id/X serial device which I realised was the one I went to yesterday too looking at my setup screenshots.
Going to bring over a few devices tomorrow and hopefully this is the beginning of my learning curve/experience and long-term use of HA!
Brilliant thank you - I too have gone for the /dev/serial/by-id/X serial device - Did not figure out the issue last night but today it is all good following a complete start again from scratch method (not ideal as I ‘need’ to know what broke it but there you go)
The cookbook looks great - will keep it to very close hand.,
Sounds like we’ve had similar experiences with cloud-based systems. One of the main reasons I stuck it out with Homeseer for so long but the most glaringly obvious thing to me was how active the HA community is (as it shows here!)