Showing signal quality (RSSI) of EnOcean devices, icon "qualityofservice"?

[fnu (Frank)]

Hi there,

I’m mixing EnOcean device with Shelly actuators and CometDECT radiator headers using AVM FritzBox as bridge.

Shellys especially were I don’t want or can’t exchange pole-changing switches, or for multiway switching and especially in basement were I run anyways an WiFi AP. Price and size is also an advantage, but quality seems, well solala. For all Shelly actuator I maintain status and sensor items, e.g. WiFi signal quality.

So I started to maintain something similar for my EnOcean actuators, PEHA, Nodon and Eltako. Two channels spotted my attention, rssi and lastReceived, available equally on all EnOcean things. I came that far:

RSSI does come back in dBm values, what I scale into a signal quality transformation:

]-55..]=4
]-65..-55]=3
]-75..-65]=2
[..-75]=1

The scale are going back to best practise found in WWW and collecting local dBm values I get from actuators sitting almost beneath my RPi @ enoceanpi (OG) and my farthest thing, an ETHSA TF20 in basement.

So, does anybody of you have a more accurate scale here? A “better” best practise?

Second, how could I get openhab property icon “qualityofservices” correctly running here? It seems just to act on the raw values coming out of the channel, what is still dBm value …

And at the last, what I can see PEHA and Nodon actuators do update by themselves occasinal to my EnOCean bridge, even not used for while. The Eltakos (TF61), albeit bidirectional, just update those values at the time they were used … doesn’t matter how “autoupdate” is set, true or false.

[rossko57]

@fnu

It seems just to act on the raw values coming out of the channel, what is still dBm value

By design, it works on raw Item state.
You haven’t said where you apply the SCALE transform, but guessing it’s “for display” i.e.Item state as incoming channel.

You can either apply the transform at channel or profile before the data gets into Item state, or you can create a new set of dynamic icons that can work off a 0-100 scale or whatever.

[fnu (Frank)]

You’re right, I let it actually scale at item level:

Number Esszimmer_Aktor_rssi "Esszimmer Aktor letzte Signalqualität [SCALE(rssi.scale):%s]" <qualityofservice> (EG_Esszimmer_Nodon) {
   channel="enocean:measurementSwitch:gtwy:0514xxxx:rssi",
   autoupdate="false"
}

I have read about to define a profile here, kind of a dummy item, does that make “qualityofservice” acting correctly to the scales 1,2,3,4 resp. 0,1,2,3,4?

[rossko57]

No dummy Item. If you use a profile, it attaches to the link between channel and Item. If you use transform profile, it manipulates the data coming out of the channel before it gets to the Item. So your Item gets state 0-4

[fnu (Frank)]

@rossko57 Hmm, did a little search, you mean like that?

Number Esszimmer_Aktor_rssi "Esszimmer Aktor letzte Signalqualität [SCALE(rssi.scale):%s]" <qualityofservice> (EG_Esszimmer_Nodon) {
   channel="enocean:measurementSwitch:gtwy:0514xxxx:rssi"
   [profile="transform:SCALE”, function=“rssi.scale"],
   autoupdate="false"
}

But doesn’t work on first try.

And something like that in log:

2021-08-14 20:58:58.550 [ERROR] [ernal.transceiver.EnOceanTransceiver] - Exception in informListeners

[rossko57]

Can’t see that message relating to use of profile.
“doesn’t work” isn’t very enlightening.

Let’s go back a step - openHAB version? Transform profiles don’t work with Number Items in OH2.

[fnu (Frank)]

openHABian @ openhab 3.1.0

Can my scale cause an issue in that profile and then that java exceptions … ?

[fnu (Frank)]

@rossko57

Can’t see that message relating to use of profile.

Is that profile:

@fnu

[profile="transform:SCALE”, function=“rssi.scale"]

Correct in semantic and position?

[rossko57]

@fnu

[profile="transform:SCALE”, function=“rssi.scale"]

The quote marks are of weirdly mixed types, but you’d have to check your original as they can get messed up posting here.

Profile documented here

Items

Scale - Transformation Services

[fnu (Frank)]

@rossko57

The quote marks are of weirdly mixed types,

You’re absolutely right … I copied it out of another thread here, but OH doesn’t complain here. It does complain if the quote types are not correct for a channel e.g.

Corrected it to should be:

[profile="transform:SCALE", function="rssi.scale"]

But still doesn’t scale “qualityofservice” …

Not even due adding a zero level to my scale:

]-55..]=4
]-65..-55]=3
]-75..-65]=2
]-90..-75]=1
[..-90]=0

[rossko57]

@fnu

But still doesn’t scale “qualityofservice” …

Why, what is it doing instead? i.e. what state is your Item state getting set to. Screenshot shows “3” which seems reasonable.

Remember, if you have transformed the Item state using profile, you probably don’t want to transform it again by [state display description] in the Item label.

[fnu (Frank)]

@rossko57

Why, what is it doing instead?

Does not change its shape like e.g. at WiFi signal quality of a Shelly actuator:

Tested your idea on an EnOcean actuator what has for sure not high level broadcast, like that:

Number Kueche_Aktor_rssi "Letzte Signalqualität [%d]" <qualityofservice> (EG_Kueche_Eltako) {
   channel="enocean:centralCommand:gtwy:0513xxxx:rssi"
   [profile="transform:SCALE", function="rssi.scale"],
   autoupdate="false"
}

resulting like that:

Value “-74” is in the range for “Quality=2” by my scale and icon “qualityofservice” could look like the WiFi example above … showing just 2 beams …

[rossko57]

Don’t forget the profile only gets applied when you actually have an incoming update.

There was a limitation about edited profiles not getting taken into account until reboot; I thought that was fixed at 3.1, maybe not.

[fnu (Frank)]

@rossko57

There was a limitation about edited profiles not getting taken into account until reboot;

Hmm, system reboot or just restart OH?

Does that compete with “persistence:mapdb”, what stores plain last status’s and values being available after an restart/reboot?

Since it doesn’t work, but also doesn’t harm, I left that scaling for 2 EnOcean actuators … and caused quickly an update by using one of them:

2021-08-15 22:02:53.680 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Flur_EG_Aktor_rssi' changed from -55 to -57

2021-08-15 22:02:55.924 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Flur_EG_Aktor_rssi' changed from -57 to -55

So, “Quality=3” equivalent but no changed behavior.

[rossko57]

@fnu

Hmm, system reboot or just restart OH?

Does that compete with “persistence:mapdb”, what stores plain last status’s and values being available after an restart/reboot?

I don’t know what any of that means in this context.

@fnu

So, “Quality=3” equivalent but no changed behavior.

The the transform has not been applied, let’s look closely at why not.

You’ve not mentioned looking in openhab.log for clues, both at Item file load/reload time and at update time, though there may well be none. There should at least be a ‘items file refreshed’ message.

I’ve assumed you must already have the SCALE add-on installed, since you already had it working in the label/display usage.

Maybe simply not applied until reboot we’ve discussed.

Which leaves syntax. Sometimes file parser is picky about silly things;the only oddity now visible is that none of the docs example have spare spaces or newlines i.e.

{
   channel="enocean:centralCommand:gtwy:0513xxxx:rssi"
   [profile="transform:SCALE", function="rssi.scale"],

to

{channel="enocean:centralCommand:gtwy:0513xxxx:rssi"  [profile="transform:SCALE",function="rssi.scale"],

though there seem to be user examples on the forum where that is not a problem at all.

[fnu (Frank)]

Ok, got your point, changed semantic into one line:

Number Flur_EG_Aktor_rssi "Letzte Signalqualität [SCALE(rssi.scale):%s]" <qualityofservice> (EG_Flur_Nodon) {
   channel="enocean:measurementSwitch:gtwy:0516xxxx:rssi" [profile="transform:SCALE", function="rssi.scale"],
   autoupdate="false"
}

and did a real reboot, whereas I think disable/enable the enocean bridge should also do the trick.

Now I guess its visable what you expect the whole time:

2021-08-15 23:58:14.871 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Flur_EG_Aktor_rssi' changed from -55 to 3

2021-08-16 00:00:21.101 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Kueche_Aktor_rssi' changed from -74 to 2

2021-08-16 00:00:23.308 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Kueche_Aktor_rssi' changed from 2 to 1

Icon scaling is still not accurate, that might also go back to one of your inputs, not to scale twice with in the item …

[fnu (Frank)]

Ok, revised to just one SCALE within the items:

Number Flur_EG_Aktor_rssi "Letzte Signalqualität [%d]" <qualityofservice> (EG_Flur_Nodon) {
   channel="enocean:measurementSwitch:gtwy:0516xxxx:rssi" [profile="transform:SCALE", function="rssi.scale"],
   autoupdate="false"
}

Now the value goes along scaling icon “qualityofservice”.

And disable/enable enocean bridge does the trick with refresh in my case, rssi for enocean actuators.

@rossko57 thanks for that support

[fnu (Frank)]

Just to follow up and documentation, I revised my RSSI to “beam” scale like that, after more investigations and collecting test values:

]-60..]=4
]-69..-60]=3
]-79..-69]=2
]-90..-79]=1
[..-90]=0