Plugwise cirle connected to PV panel gives no power data in OH3

bastiaan_van_h · May 31, 2021, 7:00am

Hi,

I’ve recently upgraded to OH3 nad noticed my PV panel isn’t reporting any data anymore. I’ve replaced the module, but again it wont report power. I’ve enabled debugging on the plugwise binding and noted this error message:

Circle (000D6F00007697AD) is in a kind of error state, skipping power information response

2021-05-31 08:42:49.233 [DEBUG] [plugwise.internal.PlugwiseDeviceTask] - Running 'Online state update' Plugwise task for Circle (000D6F00007697AD)
2021-05-31 08:42:49.359 [DEBUG] [plugwise.internal.PlugwiseDeviceTask] - Running 'Current power update' Plugwise task for Circle (000D6F00007697AD)
2021-05-31 08:42:49.359 [DEBUG] [gwise.internal.PlugwiseMessageSender] - Adding UPDATE_AND_DISCOVERY message to sendQueue: Message [type=POWER_INFORMATION_REQUEST, macAddress=000D6F00007697AD, sequenceNumber=null, payload=null]
2021-05-31 08:42:49.360 [DEBUG] [gwise.internal.PlugwiseMessageSender] - Took message from sendQueue (length=0)
2021-05-31 08:42:49.360 [DEBUG] [gwise.internal.PlugwiseMessageSender] - Sending: Message [type=POWER_INFORMATION_REQUEST, macAddress=000D6F00007697AD, sequenceNumber=null, payload=null] as 0012000D6F00007697AD8596
2021-05-31 08:42:49.385 [DEBUG] [se.internal.PlugwiseMessageProcessor] - Received message: messageType=ACKNOWLEDGEMENT_V1, sequenceNumber=41026, payload=00C1
2021-05-31 08:42:49.385 [DEBUG] [se.internal.PlugwiseMessageProcessor] - Adding to acknowledgedQueue: Message [type=ACKNOWLEDGEMENT_V1, macAddress=null, sequenceNumber=41026, payload=00C1]
2021-05-31 08:42:49.386 [DEBUG] [gwise.internal.PlugwiseMessageSender] - Removing from acknowledgedQueue: Message [type=ACKNOWLEDGEMENT_V1, macAddress=null, sequenceNumber=41026, payload=00C1]
2021-05-31 08:42:49.386 [DEBUG] [gwise.internal.PlugwiseMessageSender] - Adding to sentQueue: Message [type=POWER_INFORMATION_REQUEST, macAddress=000D6F00007697AD, sequenceNumber=41026, payload=null]
2021-05-31 08:42:49.485 [DEBUG] [se.internal.PlugwiseMessageProcessor] - Received message: messageType=POWER_INFORMATION_RESPONSE, sequenceNumber=41026, payload=000D6F00007697ADFB82DC1000000000FD289754000B
2021-05-31 08:42:49.485 [DEBUG] [se.internal.PlugwiseMessageProcessor] - Adding to receivedQueue: Message [type=POWER_INFORMATION_RESPONSE, macAddress=000D6F00007697AD, sequenceNumber=41026, payload=000D6F00007697ADFB82DC1000000000FD289754000B]
2021-05-31 08:42:49.485 [DEBUG] [se.internal.PlugwiseMessageProcessor] - Took message from receivedQueue (length=0)
2021-05-31 08:42:49.486 [TRACE] [nternal.handler.PlugwiseStickHandler] - Received unhandled POWER_INFORMATION_RESPONSE message from 000D6F00007697AD
2021-05-31 08:42:49.486 [TRACE] [ternal.PlugwiseThingDiscoveryService] - Received unhandled POWER_INFORMATION_RESPONSE message from 000D6F00007697AD
2021-05-31 08:42:49.486 [DEBUG] [l.handler.PlugwiseRelayDeviceHandler] - Circle (000D6F00007697AD) is in a kind of error state, skipping power information response
2021-05-31 08:42:49.486 [DEBUG] [se.internal.PlugwiseMessageProcessor] - Removing from sentQueue: Message [type=POWER_INFORMATION_REQUEST, macAddress=000D6F00007697AD, sequenceNumber=41026, payload=null]

000D6F00007697AD is the particular plugwise circle connected to my PV panels. I known in OH2 the circle connected to my PV panels gave a negative value for production. Could that be differently processed by OH3 vs OH2?

Otherwise there must be some bug in the new plugwise binding.

Kind regards,
Bastiaan

bastiaan_van_h · May 31, 2021, 7:46am

Some additional notes:

It’s a stealth, not a circle.
Within the Plugwise Source software I get an output of 2,78kW
It looks like it stops at line 458 of this file openhab-addons/PlugwiseRelayDeviceHandler.java at 6ae7f981344355632709d37b5b95f6aaec2891e5 · openhab/openhab-addons · GitHub

@wborn, if possible could you please take a look at this?

wborn · May 31, 2021, 8:36am

What exact OH version do you use?

There haven’t been any changes to the binding for years regarding how it communicates with the Stick or how it decodes messages.

Maybe it is fixed if you restart OH, the binding or cycle the power of the Stealth? That will cause it to use new calibration data that may result in less faulty readings.

bastiaan_van_h · May 31, 2021, 8:50am

Hi @wborn, all the obvious things are already done.

I’m at openHAB 3.1.0 Build #2394

It keeps on erroring out on line 458 with:
Circle (000D6F00007697AD) is in a kind of error state, skipping power information response

I even replaced this stealth with another one, and gives the exact same error.

bastiaan_van_h · May 31, 2021, 10:57am

@wborn I added more debug in your binding, got the watts from the stealth.

2021-05-31 12:55:33.732 [DEBUG] [l.handler.PlugwiseRelayDeviceHandler] - Circle (000D6F00007697AD) is in a kind of error state, watts: 116483.30101915111
2021-05-31 12:55:48.724 [DEBUG] [l.handler.PlugwiseRelayDeviceHandler] - Circle (000D6F00007697AD) is in a kind of error state, watts: 116483.30101915111
2021-05-31 12:56:03.839 [DEBUG] [l.handler.PlugwiseRelayDeviceHandler] - Circle (000D6F00007697AD) is in a kind of error state, watts: 116480.33991103743
2021-05-31 12:56:18.728 [DEBUG] [l.handler.PlugwiseRelayDeviceHandler] - Circle (000D6F00007697AD) is in a kind of error state, watts: 116480.33991103743
2021-05-31 12:56:33.750 [DEBUG] [l.handler.PlugwiseRelayDeviceHandler] - Circle (000D6F00007697AD) is in a kind of error state, watts: 116478.85934164523

So this is wrong, could be the payload of the stealth changes when hit with high amount of watts? It should be around 2,7kW currently.

bastiaan_van_h · May 31, 2021, 2:49pm

I’ve captured the power message of the stealth:

2021-05-31 16:48:23.882 [DEBUG] [l.handler.PlugwiseRelayDeviceHandler] - Circle (000D6F00007697AD) is in a kind of error state, message: Message [type=POWER_INFORMATION_RESPONSE, macAddress=000D6F00007697AD, sequenceNumber=57240, payload=000D6F00007697ADFFA2FD1600000000FB7C4234000F]

bastiaan_van_h · June 7, 2021, 2:28pm

@wborn, are you willing/able to help me out on this? I’ll be more then happy to provide you with all the information you need.

wborn · June 8, 2021, 11:42am

If you’ve replaced the module, you should make sure it runs the most recent firmware as OH only supports the most recent firmware, whereas Source might support multiple.

Since it previously worked for you with OH2, does the new module report correct readings when using OH2 instead of OH3? If that also doesn’t work well, we know it’s not due to some OH regression.

For me the binding still works just as fine with OH3 as it did with OH2.

bastiaan_van_h · June 9, 2021, 7:03am

Ok let me try to draw the whole picture here:

OH2
In OH2 I’ve used multiple stealths but only in usage mode, not connected to my PV panels for production readings. So I have no reference if in OH2 a negative value of a stealth got read correctly. I do had positive value’s of my stealth modules, and they were correct.

I did have a circle connected to my PV panels, and it had correct negative/production readings.

OH3
I’ve connected two stealths to my PV panels, both have the incorrect reading. The same stealth modules worked in OH2 with positive readings. I’ve not yet tested them in OH3 for positive readings and I will test this asap.

Stealths
I have two, the firmware of both stealths are: 2011-06-27
OH2 positive reading: Yes
OH2 negative reading: Unknown
OH3 positive reading: Unknown (will test asap)
OH3 negative reading: Incorrect

Recap
So the thing whats new is OH3 with stealth negative/production reading. I do not think this is a OH3 issue, but a new situation we got a negative reading from a stealth.

Anything else of the binding works just fine.

wborn · June 9, 2021, 2:14pm

Most likely the production measurements then have never worked correctly.

I’ve only been using the binding to measure consumption. The Stealths I have are the regular models, so they can only measure consumption unlike the Stealth M that you probably use.

bastiaan_van_h · June 9, 2021, 2:29pm

Yup indeed, the stealth production measurement is whats missing here.

I’ve got the first version stealths (see this, page 20), the only difference with the M that it has no relais, its just for measurement.

So, shall we implement stealth production in the binding then? What do you need from me?

wborn · June 10, 2021, 7:26am

Yes that would be nice if it also properly works with production measurements.

Obviously we need you for testing the changes. Maybe you already know what messages are used by Source to get this production info?

I’ll also have a look to see if something is already there and needs some tweaking.

bastiaan_van_h · June 10, 2021, 1:10pm

Great!

No, i don’t know how to get those messages form the Source. I’ve posted the some messages above, it’s with 0013 index which comes from the stealth with production.

Perhaps you could create a bit of code for your binding which outputs the messages, I then run it in my setup. Or you tell me what to capture.