Home Assistant automation question

I've had HA automation set to run for several weeks now - to set my home battery to export between 4pm and 7pm on the Octopus Flux tariff. This has been working fine and started to run as usual this afternoon, but I noticed at about 5.20 pm it stopped exporting. I checked the automation trace and a error was showing...... Call a service 'GivEnergy Local: Activate timed export mode' on
Stopped because an error was encountered at 21 July 2023 at 17:34:00 (runtime: 0.02 seconds)
required key not provided @ data['device_id']

I tried restarting the GivEnergy service, and restarted HA but the error keeps happening. I've manually set the GivEnergy app quick settings to 'discharge now' and this is working okay. Can anyone guide me as to what might be wrong? As already mentioned the automation has been working fine without issues for several weeks, and I haven't touched or altered anything!

J1m I don't know the answer to this but have experienced similar things myself when I've done a HA update. "Breaking changes" isn't like breaking news, it does mean that a change in the HA code will break previously working code. The error message suggests to me that the call service you are using needs the device_id or entity to be specified. If it were me, I'd just go through the automation again and check all the required fields are populated, or safer, create a new duplicate automation so you have the old (now broken) one for reference.

J1m You maybe better off posting this one to the GivTCP facebook group. 🙂

Tim
Thanks for that. That makes a lot of sense and no doubt explains why it's suddenly stopped! Good idea, will duplicate the automation and have a play! Cheers, Jim

thewhalw21 Good point. I shall try Tim's advice above and then go to the FB group if still having issues 👍

J1m i think i had the same error when i was doing an update and changed the YAML incorrectly, i deleted the section and recreated the logic and then it worked. I guess the update to GivTCP would have messed-up with the device ids

deepanshus

That's a good point. I haven't got around to do anything about it today, but will recreate the automation from scratch and give it another go. Thanks 😊

J1m new firmware on the inverter? Think i read that newer firmware requires authentication for some registers. Error reads as an auth failure.
If you are using the cdpuk integration, not givtcp, it may require an update.

As @Arg0t says:
FYI
Gen2:
Up to 909, GivTCP 2.2.x and givenergy_local both work.
911 (910) onwards, you need the currently Beta GivTCP. There is no update for givenergy_local (yet?).

So if you want to continue using givenergy_local, dont go above 909.

In my setup, 911 has pros and cons over 909, so if you want an easy life, stay on 909 :-)

My inverter (Gen 1) says its current firmware is D0.449-A0.449. I can't see any version 9xx. Am I looking in the right place?!

J1m My comment was for Gen2, I don't know what the equivalent Gen1 versions are. Sorry its not applicable to you, but might help others. If you are on a version of firmware that was upgraded via the portal, I would assume ( !) that its not the modbus issue you are seeing. The modbus changes are in firmwares ( at least as far as I know) that are completed, but are being held back until fully supported by App Portal and GivTCP.

J1m you’re on the current production firmware for gen 1, same as us and GivTCP at 2.2.4 within Home Assistant 2023.7.3 is working just fine for us.

Tim Thanks for clarifying this. I found my battery discharge/export automation started okay this afternoon. However it didn't stop! I'd got it set to stop when the battery percentage dropped to 54% but it failed to stop and went below 50% before I realised. I now find that testing that condition in the automation fails - even if I set it to 1%! It seems the battery_percent entity isn't recognised any more. I shall have to have a delve to find out why!
Just to add to this, I have tried other automations that I've used before with other settings set, but the same battery percentage check - and if I test that section it comes up 'condition not met'. This has definitely worked up until now! Could anyone please advise? Is there another way of implementing a battery percentage check in automations?

Here is the YAML code for this particular section of my automation..

condition: numeric_state
entity_id: sensor.battery_percent
above: 54
Update: Tried it again this morning and the condition passes! I have no idea what was wrong but it seems okay now, so apologies for an unnecessary post!

J1m i had a similar behaviour when the automation would not stop even after the battery is below the threshold mentioned. This happened very sporadically and on most days it works fine.

To counter this, i have another automation that only checks the battery percentage and kills off the export if its below the desired value, for eg main automation has threshold as 45, this one has threshold of 43, like a safety fall back.

DeepS

deepanshus
Thanks for the information. I would be interested to see how you have set that second automation - if you don't mind sharing the YAML? Cheers, Jim

deepanshus If you go into the Automation and then into Traces you may be able to see why.

Can cycle through some of the recent attempts, and click the circles on the left, Step Details will show what was evaluated when it ran.

I found sometimes mine was being evaluated as 0 but that was when the inverter was unavailable, so 0 was the default value. Meant I had to use greater than 1% AND less than X% to stop exporting, because occasionally it would stop early when it came back as 0.

LordHippos i tried it but as the automation runs every minute and i did not check it in time so there were no traces left. i just assumed that it must be one time glitch.