Openhab-js UoM: postUpdate, symbol/unit and persistence

Raspberry Pi 3 with openhabian
openhab 4.0
opnhab-js 4.1.0
ECMA-script 2021

I have been looking into updating my rules to using UoM and openhab-js and make use of the new opportunities offered in openhab-js 4.

There are three issues I can’t seem to solve:

Say these are my Items:

Group:Number:COUNT(ON)  Lighting_SwitchedCircuits 
Number:Power  Lighting_Power 
Number:Energy Lighting_Energy 
Switch  Lounge_Light_Spots_Switch  (GroundFloor_Lights_Count, Lighting_SwitchedCircuits)  {channel="knx:device:__L:SED2", power="420 W" } 
Switch  Lounge_Light_Indirect  "Indirect Lounge"  <light>  (LivingArea_Lights, GroundFloor_Lights_Count, Lighting_SwitchedCircuits)  ["Switch","Light"]  {channel="knx:device:__L:SLL3", ga="Switch", power="5 W" } 
...

1. postUpdate
In a rule, I’m doing this: any time a light is switched on/off (basically adding the individual (metadata value for power, when the light state is ON.

var p = Quantity('0 W');

  items.Lighting_SwitchedCircuits.members.forEach(i => {
      if (i.state == 'ON') 
        try { p = p.add(items.metadata.getMetadata(i, 'power').value);   }             
        catch { p = p.add(items._avgLightPower);}
  });

  items.Lighting_Power.postUpdate(p.float+" "+p.symbol);

This works, but: is there a better syntactic way to update the QuantityType Item by a QuantityType variable. it seems odd to having to decompose the variable into numeric value and symbol and then bring into the QuantityType Item through postUpdate as a String.

2. symbol
While the p.symbol works for the rule-defined and modified var p in the above example, it somehow doesn’t seem to work when reading the quantityState of an Item containing a QuantityType like so:

var e = items.Lighting_Energy;
console.log("e.state",e.state);
console.log("e.numericState",e.numericState);
console.log("e.quantityState",e.quantityState);

console.log("e.quantityState.float", e.quantityState.float);
console.log("e.quantityState.symbol", e.quantityState.symbol);
console.log("e.quantityState.unit", e.quantityState.unit);

gives me that:

2023-03-29 14:13:00.469 [INFO ] [hab.automation.script.ui.powerUpdate] - e.state 3.5 kWh
2023-03-29 14:13:00.477 [INFO ] [hab.automation.script.ui.powerUpdate] - e.numericState 3.5
2023-03-29 14:13:00.487 [INFO ] [hab.automation.script.ui.powerUpdate] - e.quantityState 3.5 kWh
2023-03-29 14:13:00.497 [INFO ] [hab.automation.script.ui.powerUpdate] - e.quantityState.float 3.5
2023-03-29 14:13:00.507 [INFO ] [hab.automation.script.ui.powerUpdate] - e.quantityState.symbol null
2023-03-29 14:13:00.517 [INFO ] [hab.automation.script.ui.powerUpdate] - e.quantityState.unit null

so both the .symbol and the .unit come back as null, why is that?

3. persistence

It seemed to me that from openhab 3 onwards, QuantityType items were also persisted with their UoM. When I do this:

var thirtysec = new Date(new Date().getTime() - ( 30 * 1000));
console.log(e.history.averageSince(thirtysec));

I’m getting either this (i.e. no unit):

2023-03-29 14:17:30.522 [INFO ] [hab.automation.script.ui.powerUpdate] - 3.5

or this (i.e. a null for the value:

2023-03-29 14:20:00.516 [INFO ] [hab.automation.script.ui.powerUpdate] - null

without there being a clear reason on when which one happens.
Any help much appreciated!

I have improved this, so that postUpdate and sendCommand directly accept a Quantity and no ugly workarounds are needed.

symbol and unit are null when the underlying UoM library doesn’t provide them, however I was able to increase the availability of the symbol property.

These changes are in PR [Quantity] Fix `symbol` availability & handling in `sendCommand`/`postUpdate` by florian-h05 · Pull Request #259 · openhab/openhab-js · GitHub, and will be available when I release a new version.

No, AFAIK they weren’t, but openHAB restored the unit when QuantityType Items were queried from persistence. Not all persistence methods (including averageSince) return a Quantity(Type), some only return a number, see ItemHistory - Documentation. This behaviour is from openHAB core and cannot be influenced in the JavaScript library, however it could be discussed to change this at core.

Noted with thanks.

Noted with thanks - I will wait for a new release in due course to use this feature.

Just wondering out of curiosity: so there is currently no actual way to know, which dimension/unit/symbol the returned quantityState from a QuantityType Item actually is in, other than through something like e.state.split(" ").slice(-1) ?

I appreciate that this is not an openhab-js but openhab core question. But, why does .averageSince() sometimes return a number, and sometimes null in the above example, even when the item itself wasn’t updated?
And second non openhab-js question: where can I get the default unit that the persistence service assumes as a default and stores the numbers in?

So let’s say, for Energy that default unit was kWh but I keep on postUpdating Joule or Calory numbers, than the persistence engine will transform the numbers to its default unit and also return in default unit?

Unfortunately yes. However my PR should change that. Doing a simple split and slice like you did would be the next step …

In the above example, you request the average of the last 30 seconds. If there is no entry in persistence in the last 30 seconds, null is returned. What is your persistence strategy?

Currently, the unit is just stripped of when the Item state is persisted. There is no default unit used for persistence, but there is ongoing work to have UoM persisted using a default unit. I am not actively working on or following this UoM refactoring, so at the moment I cannot say how to retrieve the default unit in the future.

If your Item’s state description is set to kWh and you send Joule values, they are converted to kWh and then saved in persistence. If you then request the Item state, it will be in kWh because the state description is in kWh. The current problem (which will be solved by the ongoing UoM refactoring) is, that when you change the state description to Wh, your old persistence units become useless because of they are factor 1/1000 of the new values.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.