Absolutely. Anything that makes it more reliable is better for all. I believe (I could be mistaken) that the google drive add on doesn’t start until the DB is stopped. I have been doing a lot of testing due to my SSD / PI4 issue and trying different configurations. I use the snapshot and more often than not the DB is corrupted. It should not be if it is stopped correctly?
It’s should not be corrupted if it’s stopped correctly.
cool, my own Technology company. Haha, you really made me laugh here.
starting simple, I succeeded doing:
- service: mqtt.publish
data:
topic: /zwave/sensor/afzuigkap_zolder_power_daystart/state
payload_template: >
{{states('sensor.afzuigkap_zolder_actueel')}}
qos: 2
retain: true
and the mqtt sensor for that is online!.
now if only I could create a service that would do something like:
for o in {{expand('group.z_wave_switches')|map(attribute='object_id')|list}}
- service: mqtt.publish
data:
topic: /zwave/sensor/{{o}}_power_daystart/state
payload_template: >
{{states('sensor.~o~_actueel')}}
qos: 2
retain: true
this is no where near correct of course, but I hope you see what I am looking for.
maybe back to the python:
for entity_id in hass.states.get(switches).attributes['entity_id']:
sensor = hass.states.get(entity_id).object_id
sensor_idPower = 'sensor.{}_actueel'.format(sensor);
sensor_valuePower = hass.states.get(sensor_idPower).state
hass.services.call(
'mqtt',
'publish',
{'topic': '/zwave/sensor/{}_power_daystart/state'.format(sensor),
'payload': sensor_valuePower,
'qos': 2,
'retain': 'true'}
)
hass.services.call(
'mqtt',
'publish',
{'topic': '/zwave/sensor/{}_usage_daystart/state'.format(sensor),
'payload': sensor_valueUsage,
'qos': 2,
'retain': 'true'}
)
not yet sure how this can be done in python, and about the mqtt syntax in the service.call… risking Petro’s rage here about Python types and dictionaries, I ask how to get this data set correctly formatted.
edited the above now creating automatic topics 
For future reference, as a script:
publish_sensor_values:
alias: "Publish sensor values"
sequence:
- variables:
switches: "{{ expand('group.z_wave_switches') | map(attribute='object_id') | list }}"
- repeat:
count: "{{ switches | count }}"
sequence:
- variables:
oid: "{{ switches[repeat.index - 1] }}"
entity: "sensor.{{ oid }}_actueel"
- service: mqtt.publish
data:
topic: "/zwave/sensor/{{ oid }}_power_daystart/state"
payload_template: "{{ states(entity) }}"
qos: 2
retain: true
1 Like
GaryK, I followed your advice and replaced all by secrets in the Configuration file. I now have 2021.4.4 installed. It appears I cannot use the !Secrets in my Configuration file any longer. When I tried one secret API key for the Sensibo integration, several other integrations such as Zigby and Ecowitt failed. Is that your experience?
So weird. I have secrets in configuration.yaml and also in a bunch of packages and addons.
I was told by devs this should be ok and it is. I don’t know why your experience differs.
The average component I use is fed by an integration and then used by a template. I have another one that is fed by a rest sensor
I have a question…
In the “Warnings for undefined variables in Templates” frenck says:
So, what if a variable isn’t always there, but I still want to use it? Well, you can give it a default, for example: {{ my_variable | default }} . Or even a default value (10 in this example): {{ my_variable | default(10) }} .
I use defaults extensively but always providing a value.
What does:
{{ my_variable | default }}
do? (i.e. no default value provided)
goodmorning! and thanks again, for this script, which I will certainly store for future reference indeed.
learning how to iterate groups like this is very helpful, coming close to the for loop we can manage in Python.
Regarding the Zwave mqtt sensors I’ll for now stick with a somewhat adapted Python script (and manually created Mqtt sensors, I don’t want to discover and auto-add all other Mqtt topics on the broker to my production system and like to hand pick them)…
hass.services.call(
'mqtt',
'publish',
{'topic': 'ha_zwave/sensor/{}/power_daystart'.format(sensor),
'payload': sensor_valuePower,
'qos': 2,
'retain': 'true'}
)
hass.services.call(
'mqtt',
'publish',
{'topic': 'ha_zwave/sensor/{}/usage_daystart'.format(sensor),
'payload': sensor_valueUsage,
'qos': 2,
'retain': 'true'}
)
gives me a 1 click option in automation and by magic I see these sensors appear:
this has been most educational!
final question on the yaml script: as you can see above I need 2 sensors per object_id, can I do that like this (create an extra variable, and use that in the second service):
publish_sensor_daystart_values:
alias: Publish sensor daystart values
sequence:
- variables:
switches: >
{{expand('group.z_wave_switches')|map(attribute='object_id')|list}}
- repeat:
count: >
{{switches|count}}
sequence:
- variables:
oid: >
{{switches[repeat.index - 1]}}
actueel: >
sensor.{{oid}}_actueel
totaal: >
sensor.{{oid}}_totaal
- service: mqtt.publish
data:
topic: >
ha_zwave/sensor/{{oid}}/power_daystart/state
payload_template: >
{{states(actueel)}}
qos: 2
retain: true
- service: mqtt.publish
data:
topic: >
ha_zwave/sensor/{{oid}}/usage_daystart/state
payload_template: >
{{states(totaal)}}
qos: 2
retain: true
An empty string
Using a secret designation in any config file results in a Fatal config error. I just run without them now. All custom components and integrations are working,
This is only for you and @Dave_Bryant. Unfortunately, only you 2 hold the power to figure out what’s causing it. Many of us are running with secrets all throughout their config without issues. So, until you 2 can get to the root cause of the issue, nothing can be done to rectify the problem.
Yes. That will work.
1 Like
my log keeps growing
Logger: pyShelly
Source: /usr/local/lib/python3.8/site-packages/pyShelly/utils.py:39
First occurred: 3:37:44 AM (1186150 occurrences)
Last logged: 8:36:19 AM
Error update loop, '>' not supported between instances of 'datetime.timedelta' and 'int', Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/pyShelly/__init__.py", line 335, in _update_loop block.loop() File "/usr/local/lib/python3.8/site-packages/pyShelly/block.py", line 141, in loop if self._need_setup_delayed_devices and self._check_delay_load.check(): File "/usr/local/lib/python3.8/site-packages/pyShelly/utils.py", line 29, in check now - self._last_time > self._interval: TypeError: '>' not supported between instances of 'datetime.timedelta' and 'int'
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/pyShelly/__init__.py", line 335, in _update_loop
block.loop()
File "/usr/local/lib/python3.8/site-packages/pyShelly/block.py", line 141, in loop
if self._need_setup_delayed_devices and self._check_delay_load.check():
File "/usr/local/lib/python3.8/site-packages/pyShelly/utils.py", line 29, in check
now - self._last_time > self._interval:
TypeError: '>' not supported between instances of 'datetime.timedelta' and 'int'
I have a problem with my hue dimmer switches since I updated to 2021.4.5.
I am running the automation blueprint of EPMatt (EPMatt/philips_324131092621.yaml).
The switches and the bulbs are implemented via zigbee2mqtt. Everything worked fine bevor the update.
The weird thing is, that the state of the button presses is received in HA but the automation does not fire.
Does someone else have this problem?
1 Like
Almost same here, for now - all motion triggered (zigbee2mqtt) automations are stalling
I am also experiencing this issue.
Upgrading to 2021.4.3 rendered all of my entities across multiple integrations (Open-ZWave, MQTT, Homekit) as unavailable.
Restored back to 2021.3.4 and everything working again.
Ran configuration checker, get
Fatal error while loading config: Secrets not supported in this YAML file Failed config General Errors: - Secrets not supported in this YAML file
have searched all of my packages referencing !secret and all are either in my /config or /config/packages folders. Configuration.yaml file has packages: !include_dir_named packages
Based on my understanding of the breaking change, i should not be having this issue.
I am not using either lovelace_gen or Dwain’s theme
Make sure you don’t have a reference to a secret inside an add-on, for example as a password like below:
Thanks for the suggestion. Unfortunately I have checked that too and any passwords are explicitly defined in the add on (Let’s encrypt, Samba and Mosquito MQTT )