What the hell is going on with history_stats in all June releases? The values seem to jump all over the place without logic. After restart they seem to be somewhat correct for some time, then suddenly they go haywire again???
Just upgraded to this version, and now my Growatt integration doesn’t work anymore. Growatt page (api-server.growatt.com) was fine. Did a revert to a snapshot of the previous version and it worked fine again. Anyone recognize this ?
That will work, yes. But you can only set history in 5 minute increments. So if you’re looking at very recent, you’re still going to have a scrolling logbook. A pause button would be pretty handy.
1 Like
I am experiencing the same using the custom Average integration.
l’ve mentioned that during the betas and in some of the issues. There were/are a lot of issues with live logbook and the changed behavior in filtering. Because of that, the pause button might have lost attention 
dev team has been working hard to smash those issues, so its not yet a finished product.
It might be good though to add it to a FR and gain some +'s on it.
Hopefully Nick can respond to that if its up.
1 Like
Anyone else experience issues with reloading of MQTT entities (either tirjugh quickbar or dev tools yaml)? even though Fix reload of MQTT yaml config by emontnemery · Pull Request #72901 · home-assistant/core · GitHub, I find that the system hangs and after some time spontaneously restarts…
even after having checked the config to be valid.
Which it is, because upon restart the new mqtt config is loaded correctly and all states are back.
All of my MQTT entities are of the new mqtt: format.
I’m converting my mqtt devices. I understand the new layout and have successfully converted other device types, but I am having issues with lights. I’m using the json schema, but I get the following error on that line (schema: json): Value is not accepted. Valid values: “default”. I then of course get the error that brightness, color_mode and supported_color_modes properties are not allowed. Looking at mqtt light documentation and samples (MQTT Light - Home Assistant) shows that the default, json and template options are still all supported.
mqtt:
light:
- schema: json
name: String
unique_id: light.string_2_mqtt
state_topic: "livingroom/dimmer"
command_topic: "livingroom/dimmer/set"
availability:
- topic: "livingroom/availablity"
brightness: true
color_mode: true
supported_color_modes: ["brightness"]
retain: true
Any ideas on what is causing this?
1 Like
Three latest release has a temporary fix for that I believe.
I created an enhancement post about that. Vote for it.
1 Like
Check your indentation…here is what one of mine looks like:
mqtt:
sensor:
cover:
switch:
light:
# MQTT lights
# Insteon MQTT Lights
- name: "Bonus Room Nook"
unique_id: "36263498" #rng 1-100M
schema: json
state_topic: "insteon/26.ab.cd/state"
command_topic: "insteon/26.ab.cd/level"
brightness: true
Isn’t it same?
option:
- xxx
yyy
zzz
vs
option:
- xxx
yyy
zzz
no, the list definition (- ...) needs to be indented
It shouldn’t be necessary; it’s the relative indentation that’s important to the YAML processor (see petro’s post).
FWIW, most of my automations (and other YAML configs) are indented minimally, like this:
alias: whatever
trigger:
- platform: time
at:
- '08:30:00'
- '20:30:00'
condition: []
action:
- variables:
foo:
- 'cat'
- 'hat'
- choose:
- conditions: "{{ ... etc .. }}"
sequence:
- service: notify.whatever
... etc ..
1 Like
Yep, that’s how I do it. Less left and right movement.
Interesting, I thought it was more strict but that must just be me being anal
@foxy I think your problem is that you’ve used light. in the unique_id when it should just be the id without the light domain.
I could be wrong though, if that doesn’t work maybe try using availability_topic instead of availability: topic just to see if there’s any difference in the error you get
Mine is in zone2. It must depend on the specific model of NUC.
Learn something new everyday 
Did you update average. There have been a couple of fixes recently
This is probably due to me not changing over MQTT sensors yet but I noticed that reloading manual mqtt configuration only updates the sensors not binary sensors. More testing to follow but as of now mqtt binary sensors are only reloaded on restart.
there will be a Reload option on the integration panel some time soon, so all entities can be reloaded from there.
for now I have severe issues with reloading the MQTT entities , see few posts above
maybe it is because I no longer have platform: mqtt sensors and moved them all to the new mqtt: format.
its nasty because I was experimenting with several availability options in the sensors configs, and reloaded, only to find out my whole instance was taken down…
too bad we dont have an availability_template option we can relate to the state topic, and need a special availability topic (which none of my sensors have)
would love to be able to do:
binary_sensor:
- unique_id: amp_left_auditorium_state_binary
state_topic: '70:B3:D5:6F:31:F2/powerswitch-zwave/c5745b57/state'
name: Amp left Auditorium state
<<: &binary
payload_on: 'on'
payload_off: 'off'
device_class: power
availability_template: >
{{ value in ['on','off'] }}
or
- unique_id: temperatuur_living
state_topic: '70:B3:D5:6F:31:F2/sensormultilevel-zwave-airtemp/0c926d01/airtemp'
name: Temperatuur Living
icon: mdi:thermometer
unit_of_measurement: °C
device_class: temperature
value_template: >
{{value|round(1,default=none)}}
availability_template: >
{{ is_number(value) }}