Replace blocked_if_present

[PhilippImhof]

In https://github.com/Feller-AG/wiser-api/issues/30#issuecomment-2189682102, you mentioned that "blocked_if_present" is deprecated. Existing simulation timers still have that property and after the last app update, these are now executed regardless whether vacation mode is on or off. One has to explicitly deactivate (enabled = false) all those timers. I have contacted customer care for the issue, but I suppose that in the end, I will have to manually convert all those existing timers. (IMHO the issue occurs, because those timers can now be enabled and disabled, whereas prior to the new app version, they had to be moved to the automation timer section in order to be deactivated. The app probably should have done some conversion during the update process.)

Can you give some more explanations about conditions and flags? E.g. the syntax to use when defining conditions that can later be used as arguments to "blocked_by"?

I currently have a system flag (290) with symbol and name "vacation" and, probably since the app update to 2.0.1, I also have a system condition (293) with name "vacation" and expression "(not vacation)". In the API docs, the example is "not absent" without parens. Am I right that the flag name can be chosen freely within certain limitations, but it must be reused in the condition?

Also, is there a documentation on how these flags and/or conditions can be used in jobs; I suppose we can use the "flag_values" attribute in a job, or will that just set the flag to a certain value?

[PhilippImhof]

I just tried to patch an existing timer to remove "blocked_if_present" by setting it to null. The result was an error, because one can only set it to a boolean value. I can, of course, set it to false, but it would IMHO be cleaner to remove it completely, if it's deprecated.

My bad, if the value is set to false, the attribute disappears.

[PhilippImhof]

FWIW, I now did the following to solve the problem with the vacation timers being triggered even though vacation mode was off:

• patch all timers with "blocked_if_present" to set this attribute to false and thus make it disappear
• patch the jobs that were linked to those timers to add "blocked_by": X where X is the system condition "not vacation" (and vacation is the system flag for vacation mode)
• make sure all those schedulers have "kind" set to 2, because in earlier versions, vacation timers did not have a switch and could only be "deactivated" by importing them to normal automation timers and deactivating them over there

I am now testing to see whether this works as expected, i. e. the timers (regardless whether active or not) should not run if vacation mode is not on.

[woodworm]

Yikes... that's a lot of effort. Unfortunately, you're quicker than I am at answering these questions. The new app attempted to migrate the old 'present' flag, which was used with 'blocked_if_present' in timers, to a more generic 'vacation' flag used in jobs with 'blocked_by'. However, it didn’t fully account for the fact that, in older versions of the app, scenes had to be selected for presence simulation.

As a result, there were jobs triggered either by a scene or by a timer, and during the migration, the 'blocked_by': 'vacation' entry was not set for these jobs to avoid blocking scenes. Additionally, it was overlooked that the timers for presence simulation would continue to run.

We are now working on an app update to correct the migration process. If a job was triggered by both a scene and a presence simulation timer, the job will be duplicated. The scene will still reference the original job, while the presence simulation timer will reference the new job (copy), with an additional 'blocked_by': 'vacation' entry.

[woodworm]

Oh and... the deprecated 'blocked_if_present' has no effect if the associated flag is no longer exists.

[PhilippImhof]

Thanks. Yeah, it was some work, but also a good opportunity to better understand the internal stuff of the system. (And also to clean up some stuff, because many scenes are no longer needed now.)

[PhilippImhof]

Speaking of deprecated stuff, is the "sceneButtons" property for scenes deprecated as well? I only have one scene left with that property being set, others use scene_input_channel in the job instead.

[woodworm]

As far as I know, the 'sceneButtons' property is still required for the app. The scene object is only used within the app. For the µGW and the system itself, this object is, let’s say, stored but ignored.

The scene_input_channel in the job is very important. It acts as a 🪄 number that refers to a kPlus binding between devices to activate a scene with a single kPlus telegram.

[PhilippImhof]

That means one could use the API to set the scene_input_channel of multiple jobs to the same value in order to trigger more than one job by pressing a single scene button?

[woodworm]

"scene_input_channel" is an internal reference to process the "target_states" list with a single kPlus telegram. It cannot be written via the API. It is only used for system-internal functionality.