and as a consequenct, one can not have an invariant properties over multiple items, as the governor over those multiple items does not have access to a sychronized view of all items.
I hate this, but I will have to make do
Thanks for the discussion. I think, I will side-step the problem.
The device on the bus does send local offset-ticks, when a user locally changes temperatures.
Then I will need a rule to capture those and update the stored temperature for that mode.
Mode update then write the stored temperature as the new base temperature
still has the danger, that the mode has changed, once the if has been entered.
This could only then be solved via using the newer interface with its conditions.
Is there a way to generate the UI-based rules from text-files? After all, as I canât use string manipulations in them, I need to generate 120 of those rulse - which I am liken to do by shell-script.
when Item Offset changed WHILE (RoomMode.state == 1)
then
...
there is still a danger that it has changed between receiving the event and examining the state. Everything takes real time, this is an insoluble problem for you. Best tackle the actual problem.
Am I right that the panel calculates its own T, and always reports that to openHAB?
The pannel takes Offset and BaseTemperature
If in StandBy it subtracts an internally stored value, configured to -2.0;
if in Night-Mode it subtracts an internally stored value, configured to -4.0.
and Reports T to the bus.
Internal temperature-changes, aside mode changes, are reported as offset-ticks and temperature-changes.
Offset and BaseTemperature can be written via the bus.
Just a crazy thought:
One could create a rule that accepts triggers on all involved items,
and it were the sole operator on OpenHAB based changes to all items involved,
as well as the sole operator of a string item.
That string then could be used, like a tape, to aggregate all information, as only one instance of that rule is active at a time.
Within the rule, then one could implement a state-machine based on the string.
Kind of a turing machine evaluating the events passed to it.
No. Every item change would trigger the rule to run, resulting in multiple instances running overlapped.
Stop looking for clever ways of mutexing, it wonât solve your issue.
You still havenât made the decisive step away from thinking synchronous to asynchronous (and context-less if by context you understand other item states, too).
asynchronous is not the problem.
As this point, I am trying to figure out, how to implement the primary goal:
having a set of temperatures stored in OpenHAB for manipulation via the user interface, and coordinating said values with the device on the KNX bus.
At this point, I basically scrapped everything I have, and I am exploring different modes of operation.
Never, the less, the question of
how to I ensure, that whan an item x has some state, items y and z have a derived state of x",
while y and z could change on their own and in consequence change the state of x.
In principle: I want the following equations to hold after some time, if one or more of its values change.
f(x[mode]) â (y,z)
g(y,z) â (x[mode])
f(âŠ) and g(âŠ) are some functions.
While x[], mode, y and z can change (internal to OpenHAB or external on the bus), after non infinite series of events that relation should hold again.
But since I can only change one variable at a time, and this generates and subsequent event again, I need to find a smart solution.
And I am slowly starting to give up. While there may be some room by using sendUpdate and postCommand with different rules, and potentially proxy-items, or s.th. like that, it is becomming a bit complex.
Really, youâve got six elements - openHAB X,Y,Z and Panel X,Y,Z
Each X is derived from some calculation of Y and Z.
My instinct would be to treat Panel as âmasterâ, itâs where the real action is. openHABs role is just supervisory on top of an autonomous panel, yes?
So we can throw away openHABs version of the X if we trust the panel to do its thing.
Of course youâd still have an Item for display etc., but itâs just a mirror of the panel and not calculated at OH.
What else needs to be done?
Users poke buttons on the panel, may affect any and all of X Y Z.
openHAB gets updated over KNX, nothing else to do.
User pokes button at OH UI, generates commands to some Mode Item (or e.g. a time based rule might do the same)
Rule is triggered by command, does some calculation? sends new Y and Z to panel.
We might get two updates for T as new Y and new Z get processed individually at the panel. Who cares.
Use the item mapped to the KNX address in GUI. Itâll update automatically when KNX decides to change it. No need to copy/store anything, that just complicates things. Use the âliveâ item.
The device thinks in base temperature and offset, and maps that to absolut temperatures in its own ui.
In OpenHAB I would like to have also absolute temperatures, i.e. a slider with the temperature, which is more intutive to us humans.
This then needs to be mapped to the device, and updated when the device changes the temperature.
I need think about that. Iâll keep you postet.
Thanks for the valuable input.
Scale in what ways? You can have as many rules defined in any manner as the system can support. Internally they are largely represented the same in memory so take up no more or less resources no matter how you define them.
In OH 3, if I understand your question correctly, each individual rule only.
There is in OH 3. Only one instance of a give rule is allowed to run at a given time. This was indeed not the case in OH 2 where any number (up to the number of rules threads in the pools) of a given rule can be running at the same time. In OH 3 the triggers are queued and worked off in FIFO for a single rule.
Could autoupdate=false be used here perhaps?
When X is commanded from OH it calculates the new Y and Z and sends those as commands to the device, but with autoupdate=false Item Y and Z shouldnât change or update until the device recalculates them itself.
The rule that processes the changes from Y and Z will calculate the new X and update X. It will spend a brief moment at the âwrongâ value perhaps since Y and Z are processed as separate events but within milliseconds X will be right. And because X was updated the X was commanded rule wonât run and new values for Y and Z wonât be calculated.
Using autoupdate=false should save one superfluous round trip on Y and Z.
When we command Y,Z to the panel then autoupdate might set new Y,Z states. Who cares, the panel will report what it thinks in a second.
Changed Y,Z would recalculate local state of X - good, we have a responsive display at OH.
