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
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?
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
System environment:
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
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 ?
Assumption: The broadcast packet is erranously taken as multicast packet. In this case:
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:
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.
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.
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.
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
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)
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. 
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
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:
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.
