From 788e367525554ec234a331b18140f90fe9c71e10 Mon Sep 17 00:00:00 2001 From: Michael Ingraham <34340210+meingraham@users.noreply.github.com> Date: Thu, 19 Sep 2019 11:22:13 -0400 Subject: [PATCH] Updated Tips (markdown) --- Tips.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Tips.md b/Tips.md index bfde7739..6e2a65fc 100644 --- a/Tips.md +++ b/Tips.md @@ -14,15 +14,15 @@ > 1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names". (See RFC-921, "Domain Name System Implementation Schedule", for background). No blank or space characters are permitted as part of a name. No distinction is made between upper and lower case. The first character must be an alpha character. The last character must not be a minus sign or period. A host which serves as a GATEWAY should have "-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as Internet gateways should not use "-GATEWAY" and "-GW" as part of their names. A host which is a TAC should have "-TAC" as the last part of its host name, if it is a DoD host. Single character names or nicknames are not allowed. ## Topic, GroupTopic, and FallBack Topic -Initially I had one MQTT configurable topic planned called TOPIC but soon found out that when two sonoffs come online with the same topic this would be a challenge at least... +Initially Tasmota had one MQTT configurable topic planned called TOPIC. It soon became apparent that when two devices come online with the same topic this would be a challenge, to say the least! -I then introduced a unique, non-configurable topic which I call fallback topic that allows me to always change the MQTT configurable topic to a new unique topic. This fallback topic is just what it is meant to be: A FALLBACK TOPIC in case of emergency. +Tasmota then introduced a unique, non-configurable "fallback topic" that allows to always change the MQTT configurable topic to a new unique topic. This fallback topic is just what it is meant to be: A FALLBACK TOPIC in case of emergency. -All MQTT status messages will be sent using the configurable TOPIC which should be made unique by the user. It might be called bedroom but it could also have been called titanic10 as long as the user knows what it is and where to find it. +All MQTT status messages will be sent using the configurable TOPIC which must be made unique by the user. It might be called `bedroom` but it could also have been called `titanic10` as long as the user knows what it is and where to find it. -Having two sonoffs with the same topic allowed for MQTT commands to be sent once to make them act in conjunction. That inspired me to add a third topic to subscribe to which I call GROUPTOPIC. Sonoffs with the same GROUPTOPIC will react to the same MQTT command. I use it to update firmware to all my sonoffs using separate groups for plain sonoff, pow sonoffs and th sonoffs. +Having two devices with the same topic allowed for MQTT commands to be sent once to make the devices act in conjunction. That inspired a third topic to subscribe to called GROUPTOPIC. The default GROUPTOPIC is `sonoffs`. Devices with the same GROUPTOPIC will react to the same MQTT command. You can use this to take actions (e.g., update firmware) devices using different groups (e.g., sonoff, sonoff-sensors, etc.). -BTW changing TOPIC can be done online using the fallback topic and is only needed once. There is no need to change user_config.h all the time, as many users seem to think they have to do with any new release. All changes are stored in flash and I make a lot of effort to keep these changes available between versions. +Changing TOPIC can be done online using the fallback topic and is only needed once. There is no need to change `user_config_override.h` all the time, as many users seem to think they have to do with any new release. All changes are stored in flash. A lot of coding effort is expended to retain these changes between firmware updates. ## Flash Memory Considerations - To stop saving parameter changes to Flash or Spiffs use command ```SaveData off```.