@Heatpump_State value not updated yet when "on @Heatpump_State then" rule fires

[blb4github]

I have a (simplified) rule block:

on @Heatpump_State then
      $hPS = @Heatpump_State;
end

When I switch off the Heatpump via the controller this rule is fired and the $hPS variable gets the value 1. This should be 0. In the screenshot below you see this happening; HeisaMon receives TOP0 0 but $hPS gets value 1.

I have seen this happening with more topics, e.g. also @Operating_Mode_State

I'm running 3.2.4-beta

[McMagellan]

I have also noticed that the TOP triggers do not show the current value but the old value. A simple remedy is to call a timer in the TOP trigger and then query the current value.

I think it comes about like this:

1. Heishamon requests and receives the original complete data set from Jeisha.
2. Heishamon compares the individual TOPs with those from the last run.
3. If a change is made, the value is forwarded as an MQTT ticket with the new value.
4. The trigger event in rules is also triggered. This process is already visible in the console with the new value.
5. The @variables available in rules are only updated when the previous process has ended.
6. If the TOP trigger event is used in rules and there is a query for the same TOP value, the old value is output.

I therefore always call a second timer from a TOP trigger, which is processed with a time delay and then uses the correct value. The time interval e.g. settimer(10,4); should not be less than 3 seconds because in my experience there are runtime problems with the global variables.

You could also see it this way that the rules were packed into the firmware as a subsequent add-on and are operated with the excess resources as second priority.

(German source Text) Ich habe das auch schon festgestellt, das die TOP- Trigger nicht den aktuellen Wert sondern den alten Wert anzeigen. Einfache Abhilfe ist im TOP- Trigger einen Timer aufrufen und dann den aktuellen Wert abfragen.

Ich denke das kommt wiefolgt zustande:

1. Heishamon fordert den altuellen kompletten Datensatz aus der Jeisha an und bekommt ihn auch.
2. Heishamon vergleicht die einzelnen TOPs mit denen vom letzten Drurchlauf.
3. Bei einer Änderung wird der Wert als MQTT- Ticket weitergeleitet mit dem neuen Wert.
4. Dabei wird auch das Trigger- Ereigniss in Rules ausgelöst. Dieser Vorgang ist in der Console sichtbar schon mit dem neuen Wert.
5. Die @Variablen die in Rules verfügbar sind werden aber erst aktualisiert wenn der vorhergehende Vorgang beendet wurde.
6. Wenn das TOP- Trigger- Ereignis in Rules genutzt wird und darin sich eine Abfrage desselben TOP- Wertes befindet bekommt man also den alten Wert ausgegeben.

Aus einem TOP- Trigger rufe ich daher immer einen zweiten Timer auf der zeitversetzt abgearbeitet wird und dann den richtigen Wert verwendet. Der Zeitabstand z.B. settimer(10,4;) sollte nicht unterhalb 3 Sekunden liegen da es meiner Erfahrung nach dann Laufzeitprobleme bei den globalen Variablen gibt.

Man könnte es auch so sehen, das die Rules als nachträgliches AddOn in die Firmware gepackt wurden und mit den Überschussressourcen betriebe werden als 2. Priorität.

[blb4github]

Thanks @McMagellan ! I did try this work-around as well but with a too short delay. I'll put 3 second timers in for now.