Couol you name this option? I cannot find it on github. Not even ‘stop’ word on this page. there is exclude addins option but this different thing.
Here is my configuration screen
o wow, thats smart indeed!
I had just updated my python script to auto create these intermediary input_numbers, but your procedure is even better.
Did you write that out verbosely, or with some templated intelligence (I need some 26 indentically named numbers for these sensors power_daystart/usage_daystart)… 
added the following to the script I posted above:
# and assign to existing input_number
# hass.services.call(
# 'input_number',
# 'set_value',
# {'entity_id': input_idPower,
# 'value': sensor_valuePower}
# )
# and create and assign to input_number
hass.states.set('{}'.format(input_idPower), sensor_valuePower,{
'friendly_name': namePower,
'min': 0,
'max': 3000,
'step': 0.01
})
# hass.services.call(
# 'input_number',
# 'set_value',
# {'entity_id': input_idUsage,
# 'value': sensor_valueUsage}
# )
hass.states.set('{}'.format(input_idUsage), sensor_valueUsage,{
'friendly_name': nameUsage,
'min': 0,
'max': 3000,
'step': 0.01
})
which does seem to do the trick. Though using the hass.states.set() might not compare with actual input_numbers.
You’re mqtt sensors would simply be the value_templates of the trigger_template sensors… wow. really nice, thanks so much.
Since you aren’t using this option you have to turn on “show unused optional configuration options” to see it. That being said, I have no idea which one it is in that screen. I would strongly recommend not trying to use that configuration options tab for that addon. The author has designed and built settings UI within the application that is so much easier to use. Trying to use that panel and configure the settings via YAML seems like a recipe for disaster since none of the options there have any kind of description or doc.
In the settings panel within the addon UI the option is here:
Thank you. Finally found it. It’s available after opening addon GUI.
However I suppose it doesn’t work with sqllite since it’s not an addon. To solve that it would stop HA - but I doubt it does that.
Maybe it works with other databases, cannot verify that.
No. It couldn’t even if it wanted to, there’s nothing to stop. The sqlite db is just a file in /config. There’s a binary which reads and writes from it on demand but when something isn’t actively reading to or writing from it then nothing is running in regards to the DB, there’s just a file sitting there on disk. So the backup just makes a copy of the file as part of backing up /config whenever it gets to that step.
The MariaDB addon is different because it is a container and a service so there’s something to stop.
I know what sqllite is.
Actually it could be achievable if communication between ha and sqllite was secured by additional layer. then shutting down this service would effectivelly give us what we need.
But I’m not aware about such thing in HA.
Likely it’s as you said just plain text HA is connecting to directly with use bult-in sqllite client.
Now question is what db Bill uses. I quess sqllite, cause it’s expected that this feature doesn’t work for sqllite while would work for other databases installed as HA addons
1 Like
“Verbosely”
I normally use a script to create an MQTT Sensor via MQTT Discovery. It’s just a single service call like this:
- service: mqtt.publish
data:
topic: homeassistant/sensor/outdoor_temperature/config
retain: true
payload: >
{
"name": "Outdoor Temperature",
"device_class": "temperature",
"unit_of_measurement": "°C",
"state_topic": "house/thermostat/outdoortemperature",
"unique_id": "envirocan_outdoor_temperature"
}
Create one service call, replicate it another 25 times, then modify each one to represent your 26 sensors. Once this initial tedious work is done, execute the script and you’ll get 26 MQTT Sensors created via MQTT Discovery. Keep the script for future use. In the event your MQTT Broker’s database is ever lost (which will lose all the discovery topics and the MQTT Sensors will disappear from Home Assistant) just run the script again and they’ll be instantly restored (but with default values of course).
FWIW, I checked and a Snapshot of the MQTT Add-on includes the broker’s database (mosquitto.db).
Alternately, create them as YAML in your configuration. It amounts to the same amount of tedious copy/pasting/modifying. The advantage of MQTT Discovery is that it permits you to define the MQTT Sensors as part of a device (YAML configuration doesn’t support that).
3 Likes
There is a recorder.disable service
Thx. I forgot about it. then it should work, if backup addon implements that. It may not since name of its feature suggests it disables addons only.
But it’s the question to Backup addon author. Especially if mentioned feature is found not working in some cases.
I am using the option that is set to stop the MariaDB. Does it work? I do not know, but the option is check to stop it. In any case the restore should do some type of check and if corrupt delete it. This would save a lot of people many troubleshooting steps.
It compensates values and it creates a new sensor. It does not adjust the existing sensor. Expect it in 2021.5.
Top level basically means ‘not in a package’, at the root config directory.
That doesn’t guarantee home assistant has stopped writing to it. Anyways, for what it’s worth, a few people are looking into improving this. Not sure if anything will come out if it.
great. this would replace my current template sensors with the addition of the input_number. Hope it behaves better than the current template sensors 
thanks
I have to admit that the expression “top level” wasn’t clear to me either. I assumed the worst and thought it meant within configuration.yaml exclusively and not even in a separate file as part of a split-configuration! Obviously I was relieved to learn I was wrong about that.
Perhaps the message should simply indicate packages are not currently supported or are their other “non top-level” possibilities?
1 Like
ok let me get this right:
at midnight, an automation publishes the states (values) of my regular power sensors too the broker, and that updates the mqtt sensors for that topic.
Upon restart during the day, the mqtt sensor will simply reload the value of that topic, which is retained on the broker.
that seems very elegant.
since I dont use MQTT discovery yet, could you please explain a bit more what the exact difference is you describe here:
I figured since I have to write the automation anyhow, with all 26 sensors in yaml, writing up these Mqtt sensors for those topics would be an extra 1 time thing. However, if there’s an opportunity to have that process automated, it would be even better… not sure what you mean by the sensors being part of a device?
for all devices, I would have to publish the Power , states('sensor.afzuigkap_zolder_actueel'), and Usage , states('sensor.afzuigkap_zolder_totaal'), to the broker, and make mqtt sensors for xxx.afzuigkap_zolder_power_daystart and xxx.afzuigkap_zolder_usage_daystart respectively with those values.
what would be the topic to publish in those cases? like:
service: mqtt.publish
data:
topic: /homeassistant/sensor/afzuigkap_zolder_power_daystart/state
payload_template: >
{{states('sensor.afzuigkap_zolder_actueel')}}
qos: 2
retain: true
and then
- platform: mqtt
state_topic: /homeassistant/sensor/afzuigkap_zolder_power_daystart/state
name: Afzuigkap zolder power daystart
unit_of_measurement: Watt
?
I see no errors on startup for that.
ok thats good, and not when reloading templates either? (of course my question was because I believed to have understood you use template sensors feeding the Average component)
If it is stopped how / why would Home assistant be writing to it?
If you were to execute these two services, they would create two sensor entities that belong to the same device. That’s because they share the same "device" information.
Click to reveal code
- service: mqtt.publish
data:
topic: homeassistant/sensor/indoor_temperature/config
retain: true
payload: >
{
"name": "Indoor Temperature",
"unit_of_measurement": "°C",
"device_class": "temperature",
"state_topic": "house/indoor/temperature",
"unique_id": "gadget_indoor_temperature",
"device": {
"identifiers": ["msg"],
"name": "My MultiSensor Gadget",
"model": "ABC123",
"manufacturer": "Marius Technologies",
"sw_version": "1.1"
}
}
- service: mqtt.publish
data:
topic: homeassistant/sensor/outdoor_temperature/config
retain: true
payload: >
{
"name": "Outdoor Temperature",
"unit_of_measurement": "°C",
"device_class": "temperature",
"state_topic": "house/outdoor/temperature",
"unique_id": "gadget_outdoor_temperature",
"device": {
"identifiers": ["msg"],
"name": "My MultiSensor Gadget",
"model": "ABC123",
"manufacturer": "Marius Technologies",
"sw_version": "1.1"
}
}
In other words, if you go to Configuration > Devices, you will see a device called “My MultiSensor Gadget” manufactured by “Marius Technologies”. The Indoor and Outdoor Temperature sensors will be associated with that device.
Alternately, each sensor entity can have its own unique "device" configuration and then each one will appear as a separate device. It’s your decision if either of these techniques, to create devices, is of use to you.
EDIT
I still use another home automation system to control a few things (mostly things that do not have integrations in Home Assistant). It communicates with Home Assistant via MQTT. Here’s an example of two ADICON BOBCAT light sensors (hard-wired, 12VDC sensors communicating via RS-485) that appear as two entities of the same device (using the technique I described above):
3 Likes
According to the guy looking into it:
“There can be a recorder queue backlog https://github.com/home-assistant/core/pull/49145 that blocks shutdown long enough that it gets killed. But I expect that case is quite rare. Worth fixing though”