BSH.Common.EnumType.OperationState stays inactive when an alarm is ringing

[liouma]

ekutner said that "If I want to react to a program end event I should listen to events like BSH.Common.Status.OperationState"

Problem: sensor.siemens_xxxxx001_bsh_common_status_operationstate state is :
BSH.Common.EnumType.OperationState.Inactive

And there is no change on this value when the alarm is triggerred.

Definition of "alarm" :
On a Siemens oven, a timer is usualy used with a program. (example: I cood a cake at 180° for 30 mins. The timer is set to 30 mins)

The entity "alarmclock" is a live count down fo this timer.
This seems to be the only value modified when the alarm is ringing but it is not precise.
I would love to do as ekutner says but there is no other value modified when the alarm is ringing.

Problem with this entity: this timer state refreshing frequency is too low, so it is not a reliable way to catch the alarm signal at the end of the countdown.

Describe the solution you'd like
"Jeedom" is a home automation system similar to HA with an integration similar to this one (home connect plugin).
It integrates a binary field 'alarm' that is very reliable, that's why I'm not worried about the capabilities of the api to transmit the required info.
A solution would be to create a binary "alarm ringing" like in this repo:
https://github.com/jmvedrine/homeconnect

[ekutner]

It is very unlikely that the state is always inactive. Did you actually look at it while a program was active?

[liouma]

Yes the state change to "run" when the oven is on.
And then it is "inactive" when you stop the program.
But the alarm does not cut the program. It just rings so you can decide wether cut the program or not.

Alamclock displays a countdown.
This plugin similar to yours for jeedom instead of HA manage to get a very reliable alarm event, not a count down :
https://github.com/jmvedrine/homeconnect

[ekutner]

I don't know what the other integration is doing and it doesn't really matter because I'm not going to change the way this one works. This integration is updating only based on events coming from the HA API, so if the events are not sent by the API the clock will not update.
As a workaround you can just start an automation with the first alarm update and wait for the timer to expire before continuing with the automation. That's probably the best you're going to get.

[liouma]

Except that you often extend the timer. Thanks for being so kind. Have a nice day Le mer. 20 sept. 2023, 18:24, ekutner ***@***.***> a écrit :

…

I don't know what the other integration is doing and it doesn't really matter because I'm not going to change the way this one works. This integration is updating only based on events coming from the HA API, so if the events are not sent by the API the clock will not update. As a workaround you can just start an automation with the first alarm update and wait for the timer to expire before continuing with the automation. That's probably the best you're going to get. — Reply to this email directly, view it on GitHub <#259 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZMY2REYEDCVSG25H4FGIATX3L4DBANCNFSM6AAAAAA463J4DU> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>