SMA Energy Meter Binding yields unplausible values

Hi,

in the last few days i discovered that the sma energy meter binding yields the value -7222067 for powerIn of my Sunny Home Manager 2.0 every day twice:

I queried my persistence data for the last 5 years and couldnt find any other results like that.

I am currently running openHAB 2.5.7 and my SMA device has

grafik

Could be related to that latest version 2.07.0.5.R (Release Notes) as the issue started on 2021-10-22.

Anyone else discovered this bahviour?

1 Like

I have the same problem

I can report the same issue. I have seen complaints about it in other forums but couldn’t find a solution, so I decided to figure out myself what the root cause may be.

Problem description:
From time to time reading data from the SMA Home Manger 20 using the SMA energy meter binding the result gives unplausible values. Event log output in this case:

2021-12-04 10:34:30.249 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH
2021-12-04 10:34:30.287 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAHomeManager20PowerIn' changed from 205.6999969482422 to 3361995
2021-12-04 10:34:30.287 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAHomeManager20EnergyIn' changed from 885.0010375976562 to -1747646808064
2021-12-04 10:34:30.287 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAHomeManager20EnergyOut' changed from 3630.896240234375 to 0.0
2021-12-04 10:34:30.287 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAHomeManager20PowerOutL1' changed from 93.69999694824219 to 0.0
2021-12-04 10:34:30.287 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAHomeManager20EnergyInL1' changed from 243.31028747558594 to 0.0
2021-12-04 10:34:30.287 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAHomeManager20EnergyOutL1' changed from 5090.23095703125 to 0.0
2021-12-04 10:34:30.287 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAHomeManager20PowerInL2' changed from 158.10000610351562 to 0.0
2021-12-04 10:34:30.287 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAHomeManager20EnergyInL2' changed from 832.591552734375 to 0.0
2021-12-04 10:34:30.287 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAHomeManager20PowerInL3' changed from 141.3000030517578 to 0.0
2021-12-04 10:34:30.287 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAHomeManager20EnergyInL3' changed from 1268.43359375 to 0.0
  • PowerIn and EnergyIn show crazy values while the others are zero. Other users report different values for PowerIn and EnergyIn but in the same system the powerIn value always remain the same, while the energyIn value varies.
  • The wrong readings appear in irregular intervals, fluctuating from 3 to 4 per hour to one per hour or even to no wrong reading for several hours. The following reading gives always correct values.
  • The issue correlates with the latest HM update to revision 2.07.5.R which I received in october 22.

System environment:

  • OS: Debian buster
  • HW: 2 x Raspberry Pi 4B+ with 4 GB
  • openHabian: Release build 3.1.0
  • Java: openjdk version “11.0.12” 2021-07-20 LTS
    OpenJDK Runtime Environment Zulu11.50+19-CA (build 11.0.12+7-LTS)
    OpenJDK Client VM Zulu11.50+19-CA (build 11.0.12+7-LTS, mixed mode)
  • Binding: org.openhab.binding.smaenergymeter 3.1.0

My working hypothesis was that the HM20 protocol has changed slightly with the update.
For debugging I have set up a new openhab installation on my Win 10 desktop PC. I also wanted to see if the problem is system independant (which it is). I used the openHAB 3.1.0 Stable Runtime with Zulu Java 11 for this purpose.
The definition of things, items and rules was text based, stripped down to the bare mimimum needed to read the energy meter values. The polling was rate is set to 2s.
In parallel I started wireshark to monitor the data packets sent out from the HM2 (IP address 192.168.178.39).
Wrong readings are reported to the openhab log file.

My findings

openhab.log

2021-12-04 09:50:04.559 [WARN ] [ore.model.script.PV.rules::HM20 test] - SMAHomeManager20PowerIn yields a wrong value: 3361995, read the next packet
2021-12-04 09:51:06.554 [WARN ] [ore.model.script.PV.rules::HM20 test] - SMAHomeManager20PowerIn yields a wrong value: 3361995, read the next packet
2021-12-04 10:07:38.557 [WARN ] [ore.model.script.PV.rules::HM20 test] - SMAHomeManager20PowerIn yields a wrong value: 3361995, read the next packet
2021-12-04 10:34:30.550 [WARN ] [ore.model.script.PV.rules::HM20 test] - SMAHomeManager20PowerIn yields a wrong value: 3361995, read the next packet
2021-12-04 10:46:54.548 [WARN ] [ore.model.script.PV.rules::HM20 test] - SMAHomeManager20PowerIn yields a wrong value: 3361995, read the next packet
2021-12-04 12:12:40.542 [WARN ] [ore.model.script.PV.rules::HM20 test] - SMAHomeManager20PowerIn yields a wrong value: 3361995, read the next packet

The wireshark log running in parallel shows two types of UDP packets:

26993	10:34:29,623483	192.168.178.39	239.12.255.254	UDP	650	35938 → 9522 Len=608
26994	10:34:29,823679	192.168.178.39	239.12.255.254	UDP	650	35938 → 9522 Len=608
26997	10:34:30,023156	192.168.178.39	239.12.255.254	UDP	650	35938 → 9522 Len=608
27002	10:34:30,223461	192.168.178.39	239.12.255.254	UDP	650	35938 → 9522 Len=608
27005	10:34:30,286745	192.168.178.39	192.168.178.255	UDP	100	9522 → 9522 Len=58
27008	10:34:30,422973	192.168.178.39	239.12.255.254	UDP	650	35938 → 9522 Len=608
27011	10:34:30,624331	192.168.178.39	239.12.255.254	UDP	650	35938 → 9522 Len=608
27017	10:34:30,822646	192.168.178.39	239.12.255.254	UDP	650	35938 → 9522 Len=608
27020	10:34:31,022682	192.168.178.39	239.12.255.254	UDP	650	35938 → 9522 Len=608
27021	10:34:31,222812	192.168.178.39	239.12.255.254	UDP	650	35938 → 9522 Len=608
27073	10:34:31,422488	192.168.178.39	239.12.255.254	UDP	650	35938 → 9522 Len=608
27078	10:34:31,622976	192.168.178.39	239.12.255.254	UDP	650	35938 → 9522 Len=608
  1. UDP multicast packets to IPV4 multicast address 239.12.255.254, port 9522 with payload length of 608 bytes. The packets are sent in 200 ms intervals (default for HM20) and contain valid energy meter data.
  2. UDP broadcast packets to 192.168.178.255, payload length 58 bytes. The packets are sent in 30 s intervals.

Observation: Always when an unplausible reading is reported in the openhab log, there appears a corresponding broadcast packet in the wireshark log, e.g. see log entries at 10:34:30.

The comparison of the packet content shows interesting results (Address 0X0000 = start of payload data, multicast packet is truncated, original serialnumber changed to 0X01020304):

Multicast packet, sent every 200 ms									
0000	53	4d	41	00					"S", "M", "A", 0
0004	00	04	02	a0					Data length: 4 byte, Tag 0 ??
0008	00	00	00	01					Group 1
000C	02	4c							Data length: 588 bytes
000E	00	10							Tag: „SMA Net 2“, Version 0
0010	60	69							Protocol- ID: Emeter protocol
0012	01	74	01	02	03	04			Emeter ID: SUSy-ID: 0x0174 (373d), Serialnumber: 0x01020304
0018	80	2a	d8	f7					Ticker, ms since start
001C	00	01	04	00					PowerIn identifier, 4 Bytes, resolution 0.1W
0020	00	00	00	00					PowerIn value, 4 Bytes
0024	00	01	08	00					EnergyIn identifier
0028	00	00	00	00	bd	b6	f1	30	EnergyIn value, 8 bytes, resolution 1 WS
....
	Broadcast packet, sent approx every 30s - 31 s								
0000	53	4d	41	00					"S", "M", "A", 0
0004	00	04	02	a0					Data length: 4 byte, Tag 0 ??
0008	00	00	00	01					Group 1
000C	00	26							Data length: 38 bytes
000E	00	10							Tag: „SMA Net 2“, Version 0
0010	60	65							Protocol- ID
0012	09	a0	ff	ff	ff	ff			?
0018	ff	ff	00	00					?
001C	74	01	04	03					Emeter ID: SUSy-ID: 0x0174 (373d), Serialnumber: 0x01020304
0020	02	01	00	00					Emeter ID: Serialnumber
0024	00	00	00	00					?
0028	f3	e3	00	02	00	00	00	00	?
0030	00	00	00	00					?

  1. Both packets start with similar headers
  2. In the broadcast packet the SUSy-ID and the Serialnumber are shifted towards addresses used for powerIn and energyIn in the mutlicast packet
  3. SUSy-ID / Serialnumber endianess: Multicast packet: Big endian, Broadcast packet: Little endian

Assumption: The broadcast packet is erranously taken as multicast packet. In this case:

  • powerIn reads to 0X02010000 and energyIn reads to 0XF3E2000200000000.
  • powerIn value divided by ten (as done by the binding) gives 3.361.996 which is equal the reported value + 1.
  • energyIn value divided by 3600000 gives -1.747.646.853.012 which is close to but not equal to the reported value of -1.747.646.808.064.

Looking into the binding source code it seems to me that only the SMA string is checked. (I don’t speak java just C but I tried my best). A datagram length check seems not to be implemented, so different packets with the same SMA string are not differentiated.

String sma = new String(Arrays.copyOfRange(bytes, 0x00, 0x03));
            if (!sma.equals("SMA")) {
                throw new IOException("Not a SMA telegram." + sma);
            }

Conclusion:
My theory is that the binding receives both packets. Since only the SMA string is checked wrong values are read from the broadcast packet.
The theory is supported by the following facts:

  • the broadcast packet appears always at the same time when a wrong value is logged
  • the wrong values appear relatively seldom in irregular intervals due to the long time interval of 30s between the broadcast packets combined with the asynchronous polling of the energy meter
  • the powerIn value remains always the same and differs from the serial number only by one
  • the header of both datagrams start with the “SMA” string and only this string is checked in the code

I have to admit that there are some weak points:
The values reported by the binding are close but not equal to the values found in the multicast packet.
I also have no explanation why the binding receives both packets. However I’m lacking enough knowledge about about java and multicast / broadcast networking to give a final judgement. May be I overlooked something.

So whats next?
I would recommend to check the protocol id in addition to the “SMA” string: ID 0x6069 at position 0x10. All datagrams with a different value should be discarded. As said my java knowledge is close to 0 but hopefully someone else from the community can take the job.
The question is how to proceed when a wrong packet is detected: Reread the multicast datagram or throw an exception?
In the first case the 200 ms time frame must be observed. Worst case the next valid datagram comes 200 ms later. Don’t know if such a long delay is acceptable.
The second case minimizes cpu time of the binding but may result in an unacceptable long time interval until the energy meter values are updated, depending on the polling rate. I use a 10 s polling interval, so worst case the energy meter values remain unchanged for 20 s.

And may be someone else can shed some light on the weak points mentioned above.

3 Likes

This is very good analysis @tomE, I will check if I am able to fix frame handling and check it with meter which started to get odd.
// edit
Following the suggestions I patched binding. It runs since 6 hours without odd values reported. Clearly Thomas analysis was right. I will prepare test build and PR to fix issue. So far I tried to address also handling of multiple meters which is pretty close to UDP handler logic.

PR with fix: [WIP][smaenergymeter] Fix handling of broadcast frames by splatch · Pull Request #11718 · openhab/openhab-addons · GitHub

It also changes the way how binding behaves making it possible to handle multiple meters. Hope, this will help. A testing snapshots:

Due to amount of changes between 2.5 and 3.0 I was not (yet) able to port it back. Please test and report back. Once you install update you need to provide meter identifier in hex decimal form. If you don’t know it let discovery report it and copy it to your earlier thing.

1 Like

Great, good to hear that we will get a solution. Thanks a lot for taking the job.

In the meantime I also have a python script working which runs outside of openhab. This makes testing easier and proofs that the problem is independant from openhab implementation.
The result is the same: I could clearly identify reception of brodcast packets as root cause. It seems that the socket interface delivers broadcast packets having the same destination port.

Some questions:

Just for my understanding: It seems you have decided to throw an exception and to discard the wrong data. That would mean emeter data remain unchanged until the next poll, right?

The entry for the emeter in my things file looks like this

smaenergymeter:energymeter:0123456789 [pollingPeriod="10"]

Does your comment mean I should change 0123456789 to 75B CD15? Is this for testing purposes only or do you want to keep this in the final version? If yes, it may be a little bit confusing for other users.

And finally: I would like to test your 3.1.0 jar. However, up to now I’m just using the stable version of openhab and I don’t know the procedure how to replace a binding with a test version. Can you give me some hints how to do it or a link where such a procedure is described?

Exception was thrown in earlier code, so I kept it to so we can track it. In case if its get annoying we can ignore wrong data completely or user can mute appropriate log category. I do expect some change in behavior of binding in area of getting thing online/offline. I think I could also switch to asynchronous mode and rely entirely on broadcasts sent by meter itself.
Previous code was putting thing offline when parsing failed and online when it succeeded. Since there might be multiple receivers (meters/handlers) on a single multicast group such way is unreliable - we could get more devices than one, we could get different devices and frame formats. I am sure we can detect thing going offline based on lack of data over certain time. This is quite basic logic and will work individually for each handler/device.

In current dev snapshot - yes, serial is twisted into hex form to avoid troubles with signed/unsigned values I found with device I could test with. Because I didn’t have meter in my hands I don’t know how its serial number looks a like on the case/box. If its unsigned then I can change it from hex to uint.

Upload it to your environment, then connect to shell and do:

karaf@local()> la -l | grep -i smaenergy
353 | Active   |  80 | 3.0.2                   | mvn:org.openhab.addons.bundles/org.openhab.binding.smaenergymeter-3.0.2.jar
karaf@local()> update 353 file:/home/connectorio/org.openhab.binding.smaenergymeter-3.0.2.jar
karaf@local()> la -l|grep -i smaenergy
353 | Active   |  80 | 3.0.2                   | file:/home/connectorio/org.openhab.binding.smaenergymeter-3.0.2.jar

First command finds bundle identifier (353), second updates it using filesystem location (/home/…), third checks if update was fine.

From background perspective - it is quite interesting that issue started to occur at the end of October. It was not present in earlier months. The openHAB installation I got where SMA is active, is deployed from September.
I guess that either new broadcast packets started to be sent or frequency of them have changed. Since UDP is always a gambling, depending on order of packet receiving, we were getting proper or improper values.

Not sure if I understand your point. Serial numbers are always positive, right? At least, in the past the binding worked with decimals and I haven’t seen any compliants.

Thanks for the hints, I will start testing tomorrow.

The issue is from my point of view clearly related to the latest update rev 2.07.5.R. The wrong values appeared in my system exactly after the update. This has been observed by other users too. SMA started the rollout around Oct. 20. so this would explain the end of october time frame. My assumption is, that they have modified the protocol and added the broadcast packets. Before the update, I have never seen such crazy values.

@splatch: I have problems to get the new binding working. What I did:
I have installed the new org.openhab.binding.smaenergymeter-3.1.0.jar in karaf

openhab> la -l | grep -i smaenergy
openhab 3.1.x: org.openhab.binding.smaenergymeter-3.1.0.jar 1 
  1. Try: Using text based configuration
    Changed the serialnumber in the thing file to hex.
   smaenergymeter:energymeter:b348c2e8 [pollingPeriod="36000"]

The openHab thing status reports ‘uninitialized, HANDLER_CONFIGURATION_PENDING’.
The log file shows the discovery running in an endless loop:

2021-12-07 10:25:10.826 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Adding a new SMA Energy Meter with S/N 'b348c2e8' to inbox
2021-12-07 10:25:10.826 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Thing discovered 'DiscoveryResult [thingUID=smaenergymeter:energymeter:b348c2e8, properties={vendor=SMA, serialNumber=b348c2e8}, representationProperty=serialNumber, flag=NEW, label=SMA Energy Meter #b348c2e8, bridgeUID=null, ttl=-1, timestamp=1638869110826]'
2021-12-07 10:25:40.826 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Adding a new SMA Energy Meter with S/N 'b348c2e8' to inbox
2021-12-07 10:25:40.826 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Thing discovered 'DiscoveryResult [thingUID=smaenergymeter:energymeter:b348c2e8, properties={vendor=SMA, serialNumber=b348c2e8}, representationProperty=serialNumber, flag=NEW, label=SMA Energy Meter #b348c2e8, bridgeUID=null, ttl=-1, timestamp=1638869140826]'
2021-12-07 10:26:10.832 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Adding a new SMA Energy Meter with S/N 'b348c2e8' to inbox
2021-12-07 10:26:10.832 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Thing discovered 'DiscoveryResult [thingUID=smaenergymeter:energymeter:b348c2e8, properties={vendor=SMA, serialNumber=b348c2e8}, representationProperty=serialNumber, flag=NEW, label=SMA Energy Meter #b348c2e8, bridgeUID=null, ttl=-1, timestamp=1638869170832]'
2021-12-07 10:26:40.841 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Adding a new SMA Energy Meter with S/N 'b348c2e8' to inbox
2021-12-07 10:26:40.841 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Thing discovered 'DiscoveryResult [thingUID=smaenergymeter:energymeter:b348c2e8, properties={vendor=SMA, serialNumber=b348c2e8}, representationProperty=serialNumber, flag=NEW, label=SMA Energy Meter #b348c2e8, bridgeUID=null, ttl=-1, timestamp=1638869200841]'
2021-12-07 10:27:10.823 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Adding a new SMA Energy Meter with S/N 'b348c2e8' to inbox
2021-12-07 10:27:10.823 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Thing discovered 'DiscoveryResult [thingUID=smaenergymeter:energymeter:b348c2e8, properties={vendor=SMA, serialNumber=b348c2e8}, representationProperty=serialNumber, flag=NEW, label=SMA Energy Meter #b348c2e8, bridgeUID=null, ttl=-1, timestamp=1638869230823]'
2021-12-07 10:27:40.826 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Adding a new SMA Energy Meter with S/N 'b348c2e8' to inbox
2021-12-07 10:27:40.826 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Thing discovered 'DiscoveryResult [thingUID=smaenergymeter:energymeter:b348c2e8, properties={vendor=SMA, serialNumber=b348c2e8}, representationProperty=serialNumber, flag=NEW, label=SMA Energy Meter #b348c2e8, bridgeUID=null, ttl=-1, timestamp=1638869260826]'
2021-12-07 10:28:10.822 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Adding a new SMA Energy Meter with S/N 'b348c2e8' to inbox
2021-12-07 10:28:10.822 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Thing discovered 'DiscoveryResult [thingUID=smaenergymeter:energymeter:b348c2e8, properties={vendor=SMA, serialNumber=b348c2e8}, representationProperty=serialNumber, flag=NEW, label=SMA Energy Meter #b348c2e8, bridgeUID=null, ttl=-1, timestamp=1638869290822]'
2021-12-07 10:28:40.825 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Adding a new SMA Energy Meter with S/N 'b348c2e8' to inbox
2021-12-07 10:28:40.825 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Thing discovered 'DiscoveryResult [thingUID=smaenergymeter:energymeter:b348c2e8, properties={vendor=SMA, serialNumber=b348c2e8}, representationProperty=serialNumber, flag=NEW, label=SMA Energy Meter #b348c2e8, bridgeUID=null, ttl=-1, timestamp=1638869320825]'
2021-12-07 10:29:10.824 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Adding a new SMA Energy Meter with S/N 'b348c2e8' to inbox
2021-12-07 10:29:10.824 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Thing discovered 'DiscoveryResult [thingUID=smaenergymeter:energymeter:b348c2e8, properties={vendor=SMA, serialNumber=b348c2e8}, representationProperty=serialNumber, flag=NEW, label=SMA Energy Meter #b348c2e8, bridgeUID=null, ttl=-1, timestamp=1638869350824]'
2021-12-07 10:29:40.825 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Adding a new SMA Energy Meter with S/N 'b348c2e8' to inbox
2021-12-07 10:29:40.825 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Thing discovered 'DiscoveryResult [thingUID=smaenergymeter:energymeter:b348c2e8, properties={vendor=SMA, serialNumber=b348c2e8}, representationProperty=serialNumber, flag=NEW, label=SMA Energy Meter #b348c2e8, bridgeUID=null, ttl=-1, timestamp=1638869380825]'

event.log doesn’t show any item updates, the ItemStateChangedEvents are missing:

2021-12-07 10:57:00.466 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH
2021-12-07 10:57:02.469 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH
2021-12-07 10:57:04.474 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH
2021-12-07 10:57:06.476 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH
2021-12-07 10:57:08.479 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH
2021-12-07 10:57:10.460 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH
2021-12-07 10:57:12.464 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH

Openhab.log showing the complete startup process:openhab.3.txt (62.6 KB)

  1. Try: Removed thing file and used automatic discovery
    Now the energymeter appeared in the inbox and could be added.
    event.log shows
2021-12-07 10:36:57.810 [INFO ] [openhab.event.InboxRemovedEvent     ] - Discovery Result with UID 'smaenergymeter:energymeter:b348c2e8' has been removed.
2021-12-07 10:36:57.810 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'smaenergymeter:energymeter:b348c2e8' changed from UNINITIALIZED to INITIALIZING
2021-12-07 10:36:57.995 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'smaenergymeter:energymeter:b348c2e8' changed from INITIALIZING to ONLINE

But still no item updates, as before.:

2021-12-07 10:43:22.836 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH
2021-12-07 10:43:24.824 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH
2021-12-07 10:43:26.829 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH
2021-12-07 10:43:28.833 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH
2021-12-07 10:43:30.837 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH
2021-12-07 10:43:32.824 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SMAHomeManager20PowerIn' received command REFRESH

The openhab.log still reports endless discovery events: openhab.4.txt (54.2 KB)

Any idea?

You need to put there one additional attribute:

smaenergymeter:energymeter:b348c2e8 [pollingPeriod="36000" serialNumber="aabbcc"]

You’re correct, however given the LE/BE and its coding over network I could not confirm with real device if my decoding of serial is proper or not. I can bring it back to number, that’s not an issue, then we just need to make sure byte order is not swapped. :slight_smile:

@splatch

Using above configuration in my things file I get the following warning in my openhab.log:

2021-12-07 18:57:41.634 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'Photovoltaik.things' has errors, therefore ignoring it: [18,61]: missing ']' at 'serialNumber'

Still no item updates in event.log and endless discovery messages in openhab.log.

Maybe it is missing colon?

@splatch
With colon

smaenergymeter:energymeter:b348c2e8 [pollingPeriod="36000", serialNumber="aabbcc"]

during startup new log entry

2021-12-07 22:04:30.579 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key smaenergymeter:energymeter:b348c2e8 in ManagedThingProvider, because it does not exists.

In openHab thing shows status ‘initializing’. Disable / enable brings it to status ‘online’ but
still no item updates in event.log and repeated discovery messages in openhab.log.

I recommend to proceed step by step: Take the original code, add the modification for the protocol id, keep the rest as it is and lets test it first. If this is working other modifications may be added.

Warning about managed provider is irrelevant as it is really about making sure that thing properties contain meter serial number.

Please try with discovered meter and see if it goes forward. In mean time I will prepare version which rely on numeric form of serial number.

Maybe it helps: I am also running sw 2.07.5.R on my SHM 2.0 and was faced with the situation described in posting #1. However after applying the snapshot.jar for openhab 3.2 as described I cannot see these spikes anymore. My SMA Energymeter Thing configuration is UI based and a new Thing was discovered automatically. The side effect is that I now have regularly Java exceptions in my oh log (unexpected payload received, received frame with wrong protocol)

You can mute warnings with:

log:set WARN org.openhab.binding.smaenergymeter.internal.packet

Best,
Łukasz

@splatch

As already posted: Both, the setting from thing file and the automatically discovered thing produce the same result: No item updates in event.log and endless repeated discovery messages in openhab.log.

2021-12-08 12:04:00.374 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Adding a new SMA Energy Meter with S/N 'b348c2e8' to inbox
2021-12-08 12:04:00.374 [DEBUG] [overy.SMAEnergyMeterDiscoveryService] - Thing discovered 'DiscoveryResult [thingUID=smaenergymeter:energymeter:b348c2e8, properties={vendor=SMA, serialNumber=b348c2e8}, representationProperty=serialNumber, flag=NEW, label=SMA Energy Meter #b348c2e8, bridgeUID=null, ttl=-1, timestamp=1638961440374]'
2021-12-08 12:04:00.374 [DEBUG] [ternal.handler.SMAEnergyMeterHandler] - Update SMAEnergyMeter b348c2e8 data 'smaenergymeter:energymeter:b348c2e8'

I even tried the 3.2 snapshot, same result.

@splatch Finally I got it working. I forgot to update my items file with the new serialnumber format.
As always: One should never do such things in a hurry. Sorry for the confusion.

@splatch
Watching the emeter values for a while I recognized a strange behaviour.
There are four openhab instances running in parallel:

  • 2 x openhab 3.1 on raspberry with the old emeter binding
  • A python script on my win10 pc running independent from openhab
  • 1 openhab 3.1 on my Win10 pc with the new test binding

The values on the two raspi with the old binding and the python script are in sync. If I switch on an additional consumer, the values of the three react accordingly.
Not the installation with the test binding. The values change, but not in sync with the other three.
Comparing the powerIn graphs of an old and the new implementation it looks like there is a delay of 13 minutes??

Below you can see the powerIn graph produced on the raspi with the original emeter binding:

And this is the graph produced on my win10 PC with the new binding:

The needle appears at 17:08 (old binding) and at 17:21 (new binding).

Then I updated the binding on one of the two raspberries two the new one and compared the graps of the two raspberries again (scaling is the same on both graphs):

Graph produced with the original binding

Graph produced with the new binding

With good will one may say, regarding the overall shape the two graphs resemble each other but there are huge differences in the details. And the graph of the new binding seems toshow also a delay of approx. 12 minutes.

The rules / items / thing files on the two raspberries are exactly the same with exception of the hex serialnumber for the new emeter binding.

Any idea for this strange behaviour?

If you track power alone, it might be different due to how probing is done. Meter values are read every N seconds or minutes. Depending on configuration retrieved power consumption might be in local minimum or maximum. Another poll attempt can see completely different value.
If you would like to trace issue and if delay is really in there… have very frequent polling or look at energy counter. Then it should be close to each other.

I can’t think of eventual reason for the delay. There is a scheduler with re-occurong task (no queue), hence delay is not caused by delay in processing of requests or answers. Updated binding has only one task per multicast group/port to save resources.