Elmätare Garo GNM3D-RS485 mäter rätt men visar helt fel

[stugan_i_skogen]

Lite absoluta tal att titta på:


Mätare 1:
På register 300053 och 300275: 4305 kWh.
Faktisk samt angiven på 301025: 23970 kWh.

Mätare 2:
På register 300053 och 300275: 2809 kWh.
Faktisk samt angiven på 301025: 9362 kWh.

 

[Bo.Siltberg]

För kWh-värdena ser det ut som att registren saknar de övre 16 bitarna i 32-bitarsvärdet!?

>>> v3=93620
>>> v3 & (2**16-1)
28084
>>> v5=239700
>>> v5 & (2**16-1)
43092

Jag ser också att du postade lite värden på momentan effekt ovan, men där ser jag inget samband mellan det korrekta och det felaktiga värdet.

Gör du en sign-konvertering? Maskar du värdena nånstans?

 

[Bo.Siltberg]

Och jag hade fel om LE ovan. Texten från specen säger ju att det är en blandning av LE och BE! Jag tror inte mina ögon...

For all the formats the byte order (inside the single word) is MSB->LSB (BE). In INT32, UINT32 and UINT64 formats, the word order is LSW-> MSW (LE).

Så mitt exempel ovan för värdet 0x12345678 får du en byteström med 0x56 0x78 0x12 0x34. Hur konverterar du värdena du får? Kan du visa oss pythonkoden?

 

[stugan_i_skogen]

Jag påminner också om att utläsningen per fas fungerar utmärkt, och den görs på samma sätt.

 

[Bo.Siltberg]

Men per fas har du troligen tre lägre värden som inte skapar problem, vilka du sedan adderar i ditt program, eller hur? Det är ju lätt att misstänka något problem kring just 16 bitar.

 

[stugan_i_skogen]

Men per fas har du troligen tre lägre värden som inte skapar problem, vilka du sedan adderar i ditt program, eller hur? Det är ju lätt att misstänka något problem kring just 16 bitar.

Exakt, det är ju en bra slutsats att dra, MEN:

Jag tror att den motbevis dock utav att om jag lastar ner en av faserna med t.ex. 5 kW, så kommer värdet stämma när jag läser registret för just den fasen, men inte värdet för hela systemet... Ska gå och undersöka detta med en gång...

EDIT:
Hängde på 3 st 2kW fläktar på L1 - totalt 5.7 kW på mätaren - och nu stämde systemeffekt och effekt för L1 överens
Har bara en fast installerad värmepump på den andra mätaren så det är lite svårare att labba där. Får vänta tills det blir lite kyligare och den drar igång sina 12kW.

Som ni såg på bilden innan så ÄR det faktiskt skillnader ibland. Energivärdena är fortsatt helt fel...

 

[Bo.Siltberg]

Jag tittade hastigt på koden och parse_value() kan inte fungera, om inte byteströmmen har en fast endian åt endera hållet. Det finns en <result>.decode()-funktion i pymodbus som du ska kunna använda där man kan ange endian för words och bytes separat. Du verkar ha tur att resultatvärdet redan har "rätt" ord och byte-endian, eller så är exempelvärdena vi har väldigt olyckliga på nåt sätt.

Så eftersom du använder biblioteksfunktioner som sköter det allra mesta är det svårt att se något fel i ditt program som förklarar de symptom du har.

 

[cpalm]

Texten från specen säger ju att det är en blandning av LE och BE! Jag tror inte mina ögon...

Ja - reagerade också på detta, onekligen udda! Undrar hur de tänkte där...

 

[andersda]

Made in Italy.....

 

[sven s]

Har det löst sig? Om du fortfarande har problem, kanske du kan kontakta supporten på Carlo Gavazzi?

 

[stugan_i_skogen]

Har det löst sig? Om du fortfarande har problem, kanske du kan kontakta supporten på Carlo Gavazzi?

Har inte hunnit jobba mer med det.
Har haft kontakt med Carlo gavazzi tidigare

 

[blackarrow]

Om man använder Word så är ju det 2 bytes åt gången. Med dessa Words skiftas pga endian swap. (Iofs märkligt).
Läser du med fel offset så kan du ju flytta din utläsning ett Word och få dina 2 bytes att hamna rätt i din utlästa räknare I alla fall trots du läser med gel endian typ. Men då gäller det också att det är nollor i de 2 byten (ett Word) som du läser från något annat närliggande register (räknare).

Ligger LSWord högst hamnar det ju be ett Word längre ner om du adderar 1 till adressen.

Byte-adresser
04 : 00 00 MSW word 2,
02 : 12 34 LSW word 1
00 : 00 00 MSW word 0

Läser du ut med fel word-endian kan du få 1234 att hamna på rätt plats genom att läsa ut från fel plats.

 

[stugan_i_skogen]

Jag hällde in specfikationen i chatgpt och frågade:


Yes, the specification does mention the data format, and it provides a clue about why you needed to swap the high_word and low_word.

Relevant Section from the Specification:​

In the document you provided, the data format is described as follows:

• 2.1 Data format representation(Page 7):
  • "For all the formats the byte order (inside the single word) is MSB->LSB. In INT32, UINT32, and UINT64 formats, the word order is LSW-> MSW."

Breakdown:​

• Byte Order Inside a Word: MSB -> LSB
  • This means that within a single 16-bit register, the most significant byte (MSB) comes first, followed by the least significant byte (LSB). This is standard and wasn't the issue.
• Word Order for 32-bit Integers: LSW -> MSW
  • This is the crucial part. It specifies that for 32-bit integers, which are stored across two 16-bit registers, the least significant word (LSW) comes first, followed by the most significant word (MSW).

Explanation:​

• LSW->MSW order indicates that when reading a 32-bit value from two 16-bit registers, the first register contains the least significant part of the value, and the second register contains the most significant part.
• This means that your meter uses little-endian word ordering for multi-register values.

Conclusion:​

The need to swap high_word and low_word aligns with the specification, which specifies that the word order is LSW->MSW for 32-bit integers. This explains why your corrected code, which interprets the first register as the low word and the second as the high word, worked correctly.