Numbers do not match with Solarman and kWh meter

[Pluimvee]

All,
Initally my inverter did not support the html/js/json/8899 options. As such I was not able to use this plugin from @robbinjanssen and @klaasnicolaas and had to create an Omnik2MQTT proxy which I based on the code from @jbouwh. However the numbers I receive do not add up with the numbers measured using a kWh meter and with the numbers shown on the solarmanpv pages. I have been debugging and frustated for the last weeks.

So far I had different webpages served when running the inverter in STA mode versus when running in AP mode. In STA mode I got a simple, minimal M2M server page in which I can only configure WiFi settings while in AP mode I am able to see much more.

Suddenly - and I have still no clue why - the 'blue' screen previously only served in AP mode is now also available in STA mode !!!
As such both the js/status.js and the 8899 polling method became available and I am now also able to use this plugin.

However: also using this plugin the numbers dont add up. Meaning: the numbers served by the inverter do not match with the numbers measured using a kWh meter or as shown by solarmanpv. I'm now tracking the number for a couple of days, and unfortunate Im unable to find a fixed factor or offset.

Did anyone else see differences in the numbers from the inverter and shown by solarman?
And did anyone else see the different webpages and the behaviour between AP and STA mode?

This is the page I now also have in STA mode, which I previously only had in AP mode

Page I previously had in STA mode

[robbinjanssen]

Are the numbers on the blue screen higher than those in solarmanpv? And where does solarmanpv get its data from?

[klaasnicolaas]

Argggghhh. If you would had given the package a more meaningfull name, like OmnikMessage or something, I would have found it and not have written something myself

The python package is mentioned in the readme, and the name (according to a format that I apply) doesn't detract from findability at all as it quickly pops up at the top of the pypi search results. So maybe you didn't search hard enough 😉

[Pluimvee]

You have just introduced me to the existence of pypi, so you are correct that I didn't know how to search.

[MarijnS95]

@Pluimvee Thanks for clarifying, knowing that the values were in sync before is very important context. Just like the fact that the display and the network reports suddenly changed, and are now mismatching manual measurements: this does point towards an inverter "issue" rather than something we can or should be aware of in the integration... yet solarmanpv knows and corrects for it?

and the numbers on solarman do no longer match with the manual measurements

I thought you said solarman matches manual measurements, only the network messages (and display) mismatch from those? Or do you now have three different reads?

Argggghhh. If you would had given the package a more meaningfull name, like OmnikMessage or something, I would have found it and not have written something myself

And so there are now about 100 message parsers for Omnik 😬

[Pluimvee]

Yes, solarman matched the manual measurements upto march 27. Solarman was configured using logger serial 601xxxx and was in sync with the actuals and inverter display. However in that period I recieved incorrect numbers and was searching for the issue, diving deep into the message decoding.

After march 27 solarman stopped receiving messages from 601xxxx. When I noticed I was recieving messages from a serial 605xxxx I added this serial on their site and now Solarman is also showing incorrect numbers.

Indeed its an inverter issue, it switched firmware with other measurements and serial numbers. Its neither a solarman or plugin issue. Initally I thought solarman was able to correct the incorrect numbers but I now known they were recieving other data. I posted some number to their website directly and see they take over these numbers broadcasted.

I was only able to conclude this serial number switch after finding out the serial was embedded in the message header. As such I could look back at archived messages and noticed solarman was communicating with another serial as I was. As the serial configured at solarman is also printed on the logger (601xxxx), I assume this is the correct firmware and the 605xxxxx is the incorrect, probably rom stored, version

I want to share my experiences for other omnik users with a logger in the 601xxxx range. These loggers do not have the 'blue' screen in STA mode (for json/js/html parsing) and do not have port 8899 enabled. The 601xxxx versions need to use a omnik2mqtt proxy instead.

So after 2 weeks of training myself in python I now have a broken logger firmware to resolve. I might need to use the RS485 interface of the inverter, skipping the WiFi logger.

[MarijnS95]

I was only able to conclude this serial number switch after finding out the serial was embedded in the message header.

Other extensions provide this as entity, perhaps we should too :)

[MarijnS95]

Suddenly - and I have still no clue why - the 'blue' screen previously only served in AP mode is now also available in STA mode !!!
As such both the js/status.js and the 8899 polling method became available and I am now also able to use this plugin.

#117 @Videodok maybe switching to AP mode might solve the issue on 1.5k-TL, rather than it being an "older" inverter? This report shows the same page as in your report on STA mode.

[Pluimvee]

The history:

• I have the same inverter and WiFi logger since 2013
• The WiFi logger is posting since 2013 with serial 601xxxx the correct numbers to OmnikSolar/Solarmanpv
• 2 weeks ago I wanted to add the Omnik inverter to HA and started this project
• Unfortunate I did not have port 8899 open so I tried to configre a second server in Omnik to post status messages to a self-build proxy
• First using an esp8266, later in python
• The messages I received contained incorrect numbers
• Firstly because they dont match with solarmanpv website
• Secondly because they dont match with a DIN-rail mounted kWh meter
• thirdly they dont match with the electricity returned to the power-net
• While researching, rebooting, etc, etc, I suddenly got the 'blue' screen in STA mode
• and I noticed port 8899 to be available
• Since march 27 at 11:20 the posting from the logger with serial 601xxxxxx to Solarman stopped
• I discovered that the message I recieved in my proxy were send by a logger with serial 605xxxxxxx
• So I configured the serial 605xxxx in solarman, which is now also displaying incorrect numbers
• Also the AP SSID changed to match the new serialnumber, (my phone has both AP's stored)
• The sticker on the WiFi logger has the 601xxxxx serial printed on it, but its now communicating using the 605xxxxx serial

Somehow the WiFi logger changed firmware, using a different serial number and broadcasting incorrect numbers.

There was a small period in which both serial numbers were used, the 601xxx to solarman and the 605xxx to my proxy. At that time the logger behaved unstable. As I was using UDP instead of TCP I asumend that was causing missing out of data packages. However: maybe the logger was continously crashing and switching between AP/STA 'modes', or firmware in ROM/RAM using different serials?

Tommorrow I will remove the server B/C configurations to see if it rolls back to serial 601xxxx

[MarijnS95]

Isn't the serial a hardware thing? Could the neighbors have gotten an Omnik installation that is now confusing with yours?

[Pluimvee]

A serial is always software as hardware is only cheap when it's equal for large production numbers.
Software can be on the chip, like microcode or mac-address, or on a device, like a device serialnumber.
Sometimes a wafer number is used to ensure uniqueness of serialnumbers but this is only applied for more expensive chips (cpu's)

There are no nearby neighbors having solarpannels, or having an installation from a bankrupt Omnik manufacturer, or having access to my network.

Theoretically I could have been looking for 10 years to someone else his production numbers however that person has been unable to watch his own numbers for the same period (you cant register the same serial on multiple plants). Moreover the serialnumber printed on the logger matched the serial in the solarman configuration and I should have recieved packages using this same 601 serial.

[robbinjanssen]

This last theory would be hilarious though 😂
I'll have a look tomorrow if the serial on my Omnik matches the one provided by the UI, no idea

[Pluimvee]

I have another theory that the inverter itself may also contain a logger serial, and the WiFi logger has another logger serial. Afterall, one can also communicate with the inverter using RS485 and the WiFi logger just acts as a WiFi to RS485 bridge.
So without using the WiFi logger, directly using the RS485, I may see another serial. Switching the WiFi logger from logger to proxy mode may explain why I see another logger serial and see different web pages

[Pluimvee]

This is where I'm looking at. I'm delivering more to the power net then I'm producing using the Omnik inverter.
One may expect this to be the other way arround, as part of what Im producing is consumed and not delivered

It might just be a factor 10

[Pluimvee]

So the story continues. (Sorry for spamming this repository but starting a new report elsewhere makes it chaotic)

I opened the inverter and gave the WiFi logger a 5 sec reset.......and what do you know, I got my old grey M2M server page back again

Gone is the blue screen, gone is serial 605xxx and back again is serial 601xxxxx. As I didnt remove the 601xxxx serial from solarmanpv I even got the correct metrics online again, including total enegery and operating hours

Even more strange, I even see another MAC address on my network

So there has to be another WiFi logger intern to the inverter...... I have to open it and take a further look.

As this logger gives correct numbers but doesnt have port 8899 and/or secondairy server support, I need to do some core network traffic routing to reroute external destination 176.58.117.69 to my internal proxy2MQTT server

[MarijnS95]

So the story continues. (Sorry for spamming this repository but starting a new report elsewhere makes it chaotic)

It's especially chaotic when GitHub allows you to create a new thread in this discussion versus replying to an existing thread... 🤯

[Pluimvee]

SOLVED !!!

I feel so stupid. While the above was not the exact case it was almost true. For all this time I was playing/testing/developing/configuring an Omnik inverter somewhere in the neighbourhood. With my logger ending up in error-state on march 27 I didnt see it anymore and assumed (the mother of all.....) the AP_605xxxx was mine. BUT IT WASNT

For all this time I was changing the device of a neighbour: adding it to my network, to my plant on solarman, sending messages to servers running on my network, etc, etc. And of course the numbers didnt add up with what I measured myself !!.

The hard reset on my WiFi logger made it available again and I came back in MY OWN grey logger configuration screen. No port 8899, no status page, no additional server to be configured.

I did found out when I was creating an AP and solarman webserver mockup on an ESP8266. While developing I noticed THREE AP_60xxxxxxx in the air which my phone didnt show as it prefers newer high speed connectivity.

For the people creating the OmnikMessage package, here is a package which my Logger sends to Solarman (its actually two messages in one TCP socket transmittion. Using UDP it will be two seperate messages)
68:55:41:b0:8b:e8:dc:23:8b:e8:dc:23:81:2:1:30:30:30:30:30:30:30:30:30:30:30:30:30:30:30:30:1:30:9:41:0:0:ff:ff:0:3:0:b4:ff:ff:0:2:ff:ff:ff:ff:9:3d:ff:ff:ff:ff:13:8d:0:46:ff:ff:ff:ff:ff:ff:ff:ff:3:35:0:0:0:52:0:0:0:b:0:1:0:0:0:0:ff:ff:0:0:0:0:0:0:0:0:0:0:8e:16:68:f:41:f0:8b:e8:dc:23:8b:e8:dc:23:44:41:54:41:20:53:45:4e:44:20:49:53:20:4f:4b:fe:16:

I need to parse this on the ESP using C++ code so have to write yet another package

thanks for all the help and support

[MarijnS95]

Glad you found it in the end, that was quite funny :)