WTH aren't temperature changes to a thermostat stored in the logbook

I am trying to troubleshoot changes to the thermostat on one of my heaters.
Currently I’m using both HA automations, Node-Red in addition to the HomeKit integration to do temperature changes to my heaters.

This heater is supposed to be set to a lower temperature at night, but something is adjusting the temperature back up.
WTH is there no information in the logbook about what automation or integration that changed the temperature?

That sounds unnecessary and prone to problems.

I believe the context data can show it.
You probably need to set up an automation just to monitor and record the context data.

Or just simplify your automations and it will probably sort out itself

Did you check the builtin programming of the thermostat, i.e. outside of HA (if it’s an actual thermostat)?

Typically, a builtin program will override anything you set through HA.

Yes, the thermostat is configured to be remotely controlled only (internal schedules are disabled).

Sure enough, but why not record “Automation/Integration X changed Heater Y to N degrees C/F” to the logbook? :slight_smile:

It does tell you. I can see in your screenshot it was an automation. It even gives the automation name “Skru av etc…”

That’s the change in the start of the graph, at 11:37AM. However, the changes around 9pm, both up and down, are not shown in the logbook display. Nor are the brief spike around midnight, or the short up and down at 5 or 6 am.
To the OP: you say it is supposed to go down at night, and something turns it back up . Whatever turns it down does not seem to be recorded either. Which integration/automation should be doing that?

Then that happened outside home assistant. So Node Red or manual control. Home assistant can’t provide context for events outside itself.

@tom_l , don’t forget that to most users, it is not clear that addons are outside HA. I don’t use NR, but the add-ons I use do keep their own logs accessible from HA. @ricmik If you go to settings/system/logs and in the top right, can you select Node Red? If so, what does the logbook say?

That’s a system/error log not a logbook of events. It is unlikely to help. Maybe if the log level is set to DEBUG?

IDK.

Because you control it from outside HA

Normally HA also includes external changes to the entity state in the logbook, it just doesn’t tell what caused them.

And that is what it does by changing the graph.

Graph is not a logbook. I specifically said logbook. Graph just confirms HA did get the change from the device. I don’t have any thermostats in HA, I’m guessing the temp is not state, but an attribute, and that’s why it’s not logged (at all, not just for external causes). Same as a light entity doesn’t report brightness change in the logbook.

1 Like

Yes, I know. The logbook only tells me if the mode was changed between heat/cool/off etc. but not the temperature changes.

As you can see here, I used two scripts: One script to turn the temp down to 10 degrees, then up to 29 degrees. Nothing in the logbook. It might as well never have happened :smiley:

Then I used the script “Test Script Turn Off” and that one is showing in the logbook.

Let’s say I’m doing a couple of automations and scripts towards the same climate entity. To see which automation or script that did a temperature change, I will have to go into each and one of them to see which of them that triggered the change. Not especially user friendly in my opinion.

Yes, but also no:

Node-Red and the HomeKit integrations directly control the HA entities.

When I turn the heater back on via Node-Red the log says:
image

This could have been more specific by showng “Add-on Name” instead of Supervisor.

When I turn it off again via HomeKit, the logbook correctly shows “HomeKit”
image

So what I wish for is two things:

  • Show the temperature changes in the logbook, not only heat/cool/off-state
  • Show what Add-On that did a change if it was not from HA itself

Attribute changes are not logged in the logbook. If we opened that up, you’d have nothing but attribute changes everywhere and a cluttered logbook.

1 Like

Doesn’t that depend on the implementation?

If it was possible to filter the type of information that is visible in the logbook it wouldn’t really be a problem.

I would argue that a device or entity changing its state is important information. Not just if it was turned on or off.

1 Like

The likely hood of someone adding “Show just this one attribute in logbook” is extremely low. It would be all attributes or nothing. And right now, there is no filter for the logbook outside the entity_id filter. Which would be flooded for some entities if the entity contains a ton of attributes.

Then it could be up to the integration developer to mark certain attributes as visible in the logbook.