Just be absolutely clear - I am not asking for any new features and/or updates.
My question is:
If I write my custom application will it be possible to change dynamically
subscription(s) for the the triggers?
If "yes" this will be very nice way to minimize number for unnecessary
application cals. Cals will be done depending on application state.
Yes, this will be another way to implement State Machine.
If you're writing a custom app, you're no longer using Rule Machine (although you can call rules via the Rule Machine API), and you're also not technically dealing with "triggers" anymore either, which are a Rule Machine concept. But a typical Rule Machine trigger is usually just an event subscription or a schedule, and I think the answer you're looking for is: yes, you can update those at any time in an app you write, too. The same means that Rule Machine has to subscribe and unsubscribe to device or location eventor create or remove schedules is available to all apps.
Thank you very much.
This is all what I have to know before starting to learn
Groovy and learn how to write an application(s) and drivers(s).
[BETA] Simple State Machines - Developers / Code Share - Hubitat
You might want to check out this before writing your own.
Thank you very much for the info.
I just checked a video - looks good.
Yours State Machine implementation definitely could be useful but
I have very different idea how to implement State Machine in Hubitat.
Dynamically changing subscriptions is a good way to do some things, and works very well. It takes almost no time at all to subscribe() or unsubscribe(), and there is some flexibility to how you do it. RM and Basic Rule both use dynamic subscriptions to implement Wait for Events or Wait for Conditions actions.
Yes, and this is very powerful feature.
I am very happy it does exist and I am using it in my rules.
However these two statements are in the middle of the rule.
In order for rule to fire the events used in the "Wait for Event or Condition"
(well, may be Wait for Condition is not require correspondent Trigger?)
also must be in the Trigger list (or I am wrong?).
If I am correct, this could be very long list of triggers.
But if Triggers are dynamicaly reassigned the rule fill fire only
when specific event(s) happens. Basically the rule will be activated
on specific events depending on the rule state.
If rules can work this way It looks like it will be very nice and simple
implementation for my lovely State Machines.
Yes, no?
The Triggers create event subscriptions that are 'permanent', not dynamic. Irrespective of what the rule's actions do, these subscriptions remain active, and consequently the rule can be triggered at any time, even while it is already running (possibly during a delay).
Waits create event subscriptions on the fly when encountered in the actions. Once the Wait fires, when it is fulfilled, these subscriptions are removed. When such a subscription is for the same device as used in a Trigger, there are two active subscriptions simultaneously, pointing to two different methods. Both will fire, and this can and does create a race condition (which may possibly be benign). The handler for the Trigger event is going to cancel the Wait, and remove its subscription along with that cancellation. However, the subscription for the Wait may have already fired, so it's too late. So, two instances of the rule are running simultaneously, one from the beginning due to the Trigger, and one after the Wait. This needs to be thought through very carefully.
Triggers always cancel pending Waits. But, overlapped use of subscriptions leads to issues.
I sent you a PM you may find interesting.
YES!!!
This is very interesting!
It looks like wording is a bit different but this is
exactly what I was thinking about.
How do I reply to your PM as PM?
Just reply in the PM itself.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
