Preview 20 - Bugs

[Jeff]

I have yet to debug what is going wrong, will do so later today, but my log is filling with lines like this:

[rest.core.internal.item.ItemResource] - Received HTTP GET request at ‘items/xxxxx’ for the unknown item ‘xxxxx’.

Are you trying to get the members of all groups? I think I have assigned some items to groups that do not exist yet?

And the scene/mode widget seems to causing this?

[WARN ] [rest.core.internal.item.ItemResource] - Received HTTP POST request at ‘items/testMode’ with an invalid status value ‘’.

[igor]

Are you trying to get the members of all groups?

Yes, if an item is a part of a group, that group will be requested on item changes. That’s because OH API does not send group updates when one of the group items changes.

And the scene/mode widget seems to causing this?

Does this happens after interaction with a scene widget?
Did you input values into options when creating scene widget?

[Jeff]

It works! Not sure what I did wrong, but it looks super now.

[igor]

That’s great! Thanks for the update.

[Flole]

Rotini is flooding the Logs with items requests now, once a second it asks for the group updates… I thought that’s what Websockets are for, so whenever a change is detected the change is pushed to the device? Or is this because my values are changing almost every second?

[igor]

@Flole OH doesn’t push updates for group items, which requires to get an update state for those.
Which group items do you have that update every second?

[Flole]

I have a power meter that refreshes the values almost every second. What my nginx logs are showing is

0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Weather HTTP/2.0" 200 4157 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Persistence HTTP/2.0" 200 56926 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/GF_Child HTTP/2.0" 200 12006 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Persistence HTTP/2.0" 200 56926 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:23 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/Energy_Log HTTP/2.0" 200 10034 "-" "okhttp/3.9.1"
0.0.0.0 - - [10/Feb/2018:18:17:25 +0100] "GET /rest/items/GC_Electric HTTP/2.0" 200 10612 "-" "okhttp/3.9.1" 

This is spamming my logs and is completely inacceptable, it causes so much traffic on the wifi and websockets would be so much better for this. Maybe for Group Items this is a good/the only solution but it should not be done for normal items. Requesting /rest/events does not update when group items are updated, it only sends the update from the individual item and not the group item, is this even wanted behaviour or is this a bug in openhab?

[igor]

Maybe for Group Items this is a good/the only solution but it should not be done for normal items.

It should be done only for group items, requests for non-group would be a bug on the app side.
Can you provide your config for GC_Electric and Energy_Log items?

Requesting /rest/events does not update when group items are updated, it only sends the update from the individual item and not the group item, is this even wanted behaviour or is this a bug in openhab?

That’s correct. OH community would be better to answer if that’s wanted behavior or not, I didn’t have a chance to ask that myself yet.

[Flole]

GC_Electric and Energy_Log are Group Items but they are not used, they contain other items which are shown on my Dashboard. As long as I don’t display any Group items in rotini, this is not needed. So it would be perfectly fine to use /rest/events, unless someone adds a Group item to a dashboard, then this fallback is fine (as it doesn’t affect me).

I’m asking the Question in the OH community now, maybe they will fix it so you don’t have to do this workaround.

[igor]

GC_Electric and Energy_Log are Group Items

If it’s possible, please provide config for these items.

I’m asking the Question in the OH community now, maybe they will fix it so you don’t have to do this workaround.

Thanks for following up on this!

[Flole]

If it’s possible, please provide config for these items.

Thats easy:

Group Energy_Log
Group GC_Electric
Number Voltage_L1 "Spannung L1 [%.1f V]" <energy> (GC_Electric, Energy_Log) { mqtt="*******" }
Number Voltage_L2 "Spannung L2 [%.1f V]" <energy> (GC_Electric, Energy_Log) { mqtt="*******" }
Number Voltage_L3 "Spannung L3 [%.1f V]" <energy> (GC_Electric, Energy_Log) { mqtt="*******" }

There are more items like that, I just took these 3 as examples.

[igor]

Btw, I checked group items in OH basic UI, and it doesn’t get updates there either (it does use similar connectivity, so that’s understandable), so I would say it should be considered a bug in OH itself.

[igor]

Upon further investigation: there are now (what looks like undocumented) updates sent for group items, so the app will be updated to use those. It should resolve all issues mentioned above.

[Flole]

When I tested it that wasn’t the case. Where exactly are those items being sent?

So for my dimmers I think I figured out the problem: When I change them from another rotini on a different device, it works. When I ask Alexa to turn on/off the lights, it is not refreshed. That is because then it looks like this
data: {"topic":"smarthome/items/Light_GC_Office_Meeting_1_Direct/state","payload":"{\"type\":\"OnOff\",\"value\":\"OFF\"}","type":"ItemStateEvent"}
while when rotini or the basic UI send dim values it’s
data: {"topic":"smarthome/items/Light_GC_Office_Meeting_1_Direct/state","payload":"{\"type\":\"Percent\",\"value\":\"0.0\"}","type":"ItemStateEvent"}
So I request that ON/OFF is mapped to 100/0 when received as state, and that a switch always sends ON/OFF as that seems to be appropriate in this case (just in case they are handled in a different way in OpenHAB, for example to select the last dim level and so on)

[igor]

When I tested it that wasn’t the case. Where exactly are those items being sent?

The main events stream /rest/events

So I request that ON/OFF is mapped to 100/0 when received as state, and that a switch always sends ON/OFF as that seems to be appropriate in this case (just in case they are handled in a different way in OpenHAB, for example to select the last dim level and so on)

Thank you for detailed report! Will check on this.

[igor]

So I request that ON/OFF is mapped to 100/0 when received as state, and that a switch always sends ON/OFF as that seems to be appropriate in this case (just in case they are handled in a different way in OpenHAB, for example to select the last dim level and so on)

This has been fixed for Preview 22 release.