Exception thrown difficult to trace

Setup, Configuration and Use Items & Sitemaps
Tags: #<Tag:0x00007faf83d1ab70>
#1

Hi all,
I am seeing some really strange behaviours from OH recently and it sometimes takes two restarts for things to right themselves, I understand this can be because of the way things come up in different ways with no consistency but normally within ten minutes all variables are normally set to the correct value or a default value was initiated, one exception is the Xiaomi temp/humidity sensors that can take up to 50 minutes to call home.

I have just cleared my cache and tmp files and found it went particularly poorly with many items not being recognised even though the .items files loaded successfully with no errors in the log.

This is the background that I post this particular issue I am digging into right now.

ITEM

Number UT_WM_Power "Power" (chartpersist, gPOWPower) { mqtt="<[MQTT:tasmota/UT_WM/tele/SENSOR:state:JSONPATH($.ENERGY.Power)]" }

SONOFF CONSOLE

06:19","Total":124.977,"Yesterday":0.367,"Today":0.139,"Power":2,"ApparentPower":54,"ReactivePower":54,"Factor":0.03,"Voltage":220,"Current":0.245}}
10:49:28 MQT: tasmota/UT_WM/tele/SENSOR = {"Time":"2020-05-24T10:49:28","ENERGY":{"TotalStartTime":"2019-03-30T18:06:19","Total":124.977,"Yesterday":0.367,"Today":0.139,"Power":7,"ApparentPower":44,"ReactivePower":43,"Factor":0.15,"Voltage":220,"Current":0.200}}
10:49:32 MQT: tasmota/UT_WM/tele/SENSOR = {"Time":"2020-05-24T10:49:32","ENERGY":{"TotalStartTime":"2019-03-30T18:06:19","Total":124.977,"Yesterday":0.367,"Today":0.139,"Power":4,"ApparentPower":21,"ReactivePower":20,"Factor":0.17,"Voltage":219,"Current":0.094}}
10:50:05 MQT: tasmota/UT_WM/tele/SENSOR = {"Time":"2020-05-24T10:50:05","ENERGY":{"TotalStartTime":"2019-03-30T18:06:19","Total":124.977,"Yesterday":0.367,"Today":0.139,"Power":2,"ApparentPower":43,"ReactivePower":43,"Factor":0.04,"Voltage":220,"Current":0.195}}
10:50:07 MQT: tasmota/UT_WM/tele/SENSOR = {"Time":"2020-05-24T10:50:07","ENERGY":{"TotalStartTime":"2019-03-30T18:06:19","Total":124.977,"Yesterday":0.367,"Today":0.139,"Power":5,"ApparentPower":58,"ReactivePower":58,"Factor":0.09,"Voltage":220,"Current":0.264}}

LOG

2020-05-24 10:52:01.033 [vent.ItemStateChangedEvent] - UT_WM_Power changed from 9 to 4

2020-05-24 10:52:05.601 [vent.ItemStateChangedEvent] - GR_Freezer2_Power changed from 0 to 2

==> /var/log/openhab2/openhab.log <==

2020-05-24 10:52:05.991 [ERROR] [e.internal.WriterInterceptorExecutor] - MessageBodyWriter not found for media type=text/event-stream, type=class org.glassfish.jersey.media.sse.OutboundEvent, genericType=class org.glassfish.jersey.media.sse.OutboundEvent.

==> /var/log/openhab2/events.log <==

2020-05-24 10:52:06.741 [vent.ItemStateChangedEvent] - KT_Fridge_Power changed from 1 to 0

2020-05-24 10:52:08.043 [vent.ItemStateChangedEvent] - UT_WM_Power changed from 4 to 6

2020-05-24 10:52:09.021 [vent.ItemStateChangedEvent] - LG_Venus_IP_Online changed from ON to OFF

==> /var/log/openhab2/openhab.log <==

2020-05-24 10:52:20.322 [ERROR] [e.internal.WriterInterceptorExecutor] - MessageBodyWriter not found for media type=text/event-stream, type=class org.glassfish.jersey.media.sse.OutboundEvent, genericType=class org.glassfish.jersey.media.sse.OutboundEvent.

==> /var/log/openhab2/events.log <==

It seems the ERROR follows very soon after the item is updated with a new value. Can anyone explain how to solve?

I have already eliminated the WM rules and I think my next task is to comment out the item and see if the ERROR stops.

Regards

Paul

#2

Usual information missing
openHAB version
Java version
OS
Was this a recent version upgrade?

#3

That’s usually a clue that it is to do with a UI,perhaps just needing a refresh since a reboot or upgrade.

#4

no just Openhab started to play up from what I can see, I have been seeing an issue with hue bulbs that only OH had for a while so I figured next step to possible clean up a stack of weird errors like this was to stop, clear the cache and start OH.

It did not go well.

The OH version I am running is
OH version: 2.5.5-1 release build
java version “1.8.0_201”
uname -a Linux openhab 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux

I went down the track of commenting out all 23 of the MQTT _Power items I had defined and it did not really slow down the ERROR frequency. Next, thinking it could be a JSONPATH transformation issue I commented out all 23 of my +Voltage items, that did not slow the error either. I did look at whether I should comment out ALL 119 MQTT JSONPATH items but decided this was a rabbit hole and backed out the commenting I had made.

I am currently thinking my next move is another restart this time without clearing the cache.

Regards
Paul
_

#5

can you elaborate, one of the other weird things I have noticed is if I go to basic UI it looks like it is working but at the base of the home screen it keeps throwing up the message

“Offline: waiting for connection to become available”
Which is quite bizarre, as I do not understand what connection it is referring too.

Regards
Paul

#6

Have you any rules with MQTT Action, do you have it installed? Version 1.x action does not sit well in OH2 with binding v2

#7

Checked add-ons > Actions and MQTT Actions (1.x) is not installed.
Anywhere else I should check?

#8

so this time I stopped OH, did not clear the cache and rebooted the Linux device, and it returned without the errors and the UI message has also gone too.
Unfortunately the original issue that prompted the cache clearance remains :frowning: so I will try the next thing for that.

I am really not sure why OH seems to take multiple restarts before it comes back cleanly, I suspect it could be my setup is somehow impacted more than others with the non-consistent startup order.

Regards
Paul

#9

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