* Added note about persistence of messages with embedded broker
The embedded mqtt broker does not save messages between restarts. Because of this the discoverys messages have to be sent after every restart for the devices to show up in HA. I added a note section to make users aware of this.
* Minor change
Added note about testing templates in the template tool
Added section about how `|` has priority over non-bracket operators
Some minor changes to steer people towards `states.('...')` rather than `states...state`.
* All instances of `Mosquitto` are capitalized **outside of** instances that refer to code/configuration blocks/file names to comply with the [docs standardization](https://developers.home-assistant.io/docs/en/documentation_standards.html).
* Standardization for displaying file paths, code/configuration blocks in `plaintext`.
* Simplification of the supported controllers
Stripped it down to the key fact - *static controllers* are all that'll work with OZW.
Noted that Z-Wave Plus controllers are recommended, to take advantage of all the features of Z-Wave Plus.
Noted that S2 and Smart Start aren't supported by OZW
* Controllers restored
Restored the list of confirmed sticks, but taken out the lists of OSs because we just took the list from the OZW pages, and it's clear that's outdated and incomplete
As somebody pointed out on the forum, using different examples adds confusion. Updated both styles to use the same contents, so it's clearer what's going on.
Tested the Zooz z-wave Plus S2 Stick ZST10 with Home-Assistant. Zwave worked, nodes included and communicating using a Raspberriy Pi3 with the latest Hass.io.
Trying to split this into "first class" and "here be dragons". The aim being to make less experienced folks less likely to dive directly into things like Armbian, or Mac, or ...
* FOR DISCUSSION - improving the Securing docs
This probably needs some back and fore to work out what the projects want here, but I thought I'd give it a first pass through to turn this from a "wall of things" that seem equally important into something hopefully more digestible. Particularly as some of the things look like you should do all of them, but they're actually mutually exclusive, or functionally identical.
I've tried to break it into things that people must do (here's the basic minimum) and things they should consider if they want to make it more secure. I've also tried to steer people towards `cloud` where it'll work for them, and if they just want remote access to the UI to use a VPN or Tor (I moved the SSH tunnel option last because it's the most complicated to set up of the three).
* Update based upon feedback
* Added link to fail2ban guide
* Updates
* Update
* ✏️ Tweaks
It's always been a bit of mystery why automations sometimes get turned off. This should shed some light on it.
I appreciate the intent is to fix this, but until it's fixed, it makes sense to document it.
Added info about the alarm_type from the openzwave code. I believe there is some mixed info based on older V1 alarms vs new V2 alarms. V2 have fixed alarm_types so I've separated the two to make it clear which one a user should look at.
