1st meter is SMA Home Manager 2.0
2nd meter is SMA Energy Meter 20
Serial numbers are filled in in hex format (8digits)
Only Home manager was detected automatically, Energymeter 20 was added manually
You are using two different types of energymeters: The older SMA energymeter and its successor the home manager, right?
Iâm not sure if they use the same protocol. In the past SMA has added a couple of bytes to the HM 2.0 datagram. I donât know if this has happened for the emeter too. @splatch: Does the binding support both types of protocol? The SUSyID (part of the protocol header) of the energymeter is 0x010E, the id for the home manager is 0x0174.
In general I would recomend to start testing with one home manager only.
Binding checks if header starts from S M A sequence and if later part of header called protocol id (bytes 16 and 17) is equal to 0x6069. If that part of frame doesnât match then âReceived frame with wrong protocol IDâ error is produced. This is only one check which I see in present code, no other checks are being made to differentiate between energy meter and home manager.
@tomE @splatch
I have no doubts about the data that is captured. Both SMA homemanger2.0 and energymeter20 are captured correctly.
The only issue with the new binding is the delay of about 20 min.
I have Openhab 4.1 stable running on NUC/Ubuntu with released binding, and Openhab 4.1 stable running on Raspberry PI with new binding from Lucasz.
See captures of the same events by each system:
Polling freq is 60sec on NUC and 30 sec on Rasp Pi
Sorry for the question: Did you check your Raspi clock? 
Good question. I checked before, and now again.
All clocks are OK, and synchronised via a ntp server
Having the clocks all in sync raises for me the suspicion that the received data are probably delayed in a buffer after reception. You can not recieve the same data at different points in time.
@splatch: I remember having a similar issue in the early days of the new binding, see here: SMA Energy Meter Binding yields unplausible values - #20 by tomE
Could that be the root cause?
The earlier bug with delayed processing was related to different execution flow between old and patched binding. The old binding kept multicast group membership while patches I made joinGroup call for each poll. This has been fixed long time ago and none of builds published should contain frequent join calls.
@tomE I took a look at some of your earlier reports and found that two of your posts contained error message: SMA Energy Meter Binding yields unplausible values - #76 by tomE. This could be related to thing property updates. Since this error is being thrown within initialization of thing handler it will influence polling sequence too. Are you observing this with latest builds?
Another question - does anybody have a reference link with protocol description for both SMA products? Iâve tried to use some of earlier links we had in this topic but they are not working any more due to update of SMA website.
May be, this python script can help you?
I will compare the openhab new sma binding timing with the readings through this script (might take some days due to current holidays)
speedwiredecoder_v0.txt (7.1 KB)
I havenât used the binding since then but my own python script which you can find here: SMA Energy Meter Binding yields unplausible values - #34 by tomE
It gives me more information and control than the binding and makes it easier for me to debug. The script can also be used standalone if you have a python3 intepreter running on your computer. The output is in json format.
The class âSMApacketâ in the script mentioned above can give a quick overview of the content of the SMA datagram. But to make your life easier I have shared a pdf showing a more detailed description together with byte offsets. The content is in german but it should not too difficult for you to translate the few words.
HM20_SMA_packet.pdf (250.9 KB)
@tomE, @fcambron thank you for references, looking at these I see bigger picture of what frame is about. Looking at the ticker field from Tomâs post I think it would be wise to keep an eye to ticker field. Do you know how it behaves when meter gets power cycled? Does it start from 0 or some fairly low value?
I had never an eye on the âtickerâ. From my point of view I see not much benefit with exception of debugging. It is a 32bit value, means after approx. 49 days it starts from the beginning. During this period of time one can use it to check if there were an unexpected restart of the HM firmware aka software bug. In the beginning of the development of my script I used it to verify if I have catched each 200ms packet but removed it later from the script. Which benefits do you see in watching the ticker?
I understand that handling of ticker might get tricky (i.e due to reset), but it could be helpful to determine whether we have stable communication or not, whether packet we just received is out of order.
@tomE @splatch
Please have a look at the data, I captured this morning.
(I can send you the raw data in excel via PM. Excels can not be uploaded here)
All data was captures by the same Raspberry PI:
1/ Captured by Python script (independent from OpenHAB):
Starttime of consumption: 07:31
End time of consumption: 09:25
2/ Data logged by Openhab in the /var/log/openhab/events.log:
Starttime of consumption: 08:25
End time of consumption: 10:09
3/ Data stored in mariaDB (JDBC)
(same time as in 2/)
4/ Graph from openhab
(same time as in 2/ and 3/)
One extra remark. The shape of the last 3 grapsh is different from the first one.
It looks like some data processing is done by the new binding. Look at the âfalse plateausâ which last about 15minutes.
I see the same delay/behavior in the data of the home manager and energie meter.
Is there any to the source code of the updated binding?
Thanks
See [smaenergymeter] Fix handling of broadcast frames by splatch · Pull Request #11718 · openhab/openhab-addons · GitHub for code changes.
Full chronology for you openhab-addons:
- 09-10.2021- SMA began to roll firmware update.
- 21.10.2021 - I spotted bogus readings in one of installations I was supervising.
- ??.11.2021 - I found this thread, with Tomas and others who found a real cause of issue (kudos for them!).
- 06.12.2021 - I provided first version of above PR which fixed bug and introduced support for multiple meters.
- 06.12.2021 - Same day maintainer of binding accepts change request.
- 12.12.2021 - Review of more people is requested.
- 12.12.2021 - Review of second person.
- 13.12.2021 - Requested changes/updates are incorporated, code is updated.
- 04.01.2022 - Change request get labelled as âbugâ fix.
- 09.03.2022 - Change request get labelled as âWork in progressâ.
- 06.11.2022 - Change request receives first review from third person (11 months after first reviews by binding maintainer and second person).
- 06.11.2022 - Requested changes are integrated, I requested follow up review.
- 10.12.2022 - Follow up review of changes from third person.
- 31.12.2022 - Change request get labelled as âAwaiting feedbackâ.
- 08.01.2023 - Iâve integrated needed changes, and disputed some of feedback.
- 05.05.2023 - Iâve explicitly requested re-review of third person.
- 05.05.2023 - Change request get labelled as âpotentially not backward compatibleâ
- 21.09.2023 - Iâve updated code once again.
- 21.09.2023 - Iâve explicitly requested re-review of second and third person.
- 02.01.2024 - The âWork in progressâ label gets removed.
- 02.01.2024 - Copyright header fixes, removal of code in question.
- 11.02.2024 - Follow up review.
It is already 2024, I have once again fix copyright comment because they indicate 2023 and not 2024 and build will obviously fail due to this critical issue 
(even if the code was made in 2021âŠ).
I donât have access to installation where I initially tested binding, I am not nominated maintainer of this binding (I am not maintainer of any of the bindings), thus its beyond my control and I am simply blind when sometimes it comes to debugging.
@fcambron The instability with time shift - for start I just need link to the binary you deployed and confirmation if your jdbc persistence uses âevery updateâ strategy.
Yeah, i agree the PR history is far from great. I can explain much on the how and why, but i donât think it will add anything to get this resolved. Just know that each one that spend time on this, did it in his own time and with the best intentions.
That being said, there are some unresolved comments left from december 2022. I hope we can fix them together and move this PR forward. Just let me know if i can be of any help.
Code which was questioned in December 2022 was removed/updated within next update cycle. Surely, it was hard to find remaining comments within 300 interactions spanning over several years. I marked 4 remaining comments as resolved.
Not entirely sure if we talk about the same. There where some comments about the discovery service. And i might be wrong, but for instance the comment about Thread.sleep(60_000) is now marked as resolved, but it does not look to have any comment or code change.
What am i missing? Maybe some commit was not pushed?
Right, Iâll remove that. The functionality in question allows to force registering packet listener to trigger manual discovery.
Just to be sure, please re-visit those 4 comments. The PR is in good shape and with these iâm confident in a sooner then later merge.