@
Raven Ik kan een P1 meter kopen, maar mijn plezier zit juist om hem, (vrijwel) helemaal zelf te maken.
Dus ik vindt het niet leuk om andermans code over te nemen, juist niet, maar zelf bedenken omdat ik daarmee het meest leer.
Toch bedankt voor je aanbod van de python code.
Overigens, vergis ik me als ik stel dat je op een ESP32 in CPP óf in (micro)Python kan programmeren, en niet tegelijkertijd? Of bestaat er ook een hybride mogelijkheid dat je CPP én microPython in één programma kan schrijven?
@
Septillion dat vermoeden had ik al voor 99,999% maar ik denk, ik ben een mens en maak dus fouten, laat ik het toch maar even voor de zekerheid hier vragen. En mogelijk had mijn type meter gewoon een beperkte output, ik heb geleerd als technicus met alles rekening te houden, ook met het (haast) onvoorstelbare.
Dat iederen RTS actief knoopt betekent nog niet dat ik het ook doe

Ik hou er wel van om "de regie te hebben". Dan kom je ook mogelijk niet in tijdnood (procestijdtechnisch, ik geef toe de ESP32 is wel snel) omdat het proces van verwerking mogelijk langer duurt dan 1 sec (ik gebruik ook een oled display via I2C en dat vindt ik behoorlijk traag).
Dus mijn gedachte was: de P1 poort mag pas wat sturen als het programma er aan toe is, waarom zou je het moeilijk doen als het makkelijk kan?
@
Jerdenberg @Raven heeft inmiddels al het antwoord gegeven; privacy matters.
Met jullie opmerkingen heb ik gedacht, zou het dan toch... weet je wat, ik schrijf even een miniprogramma'tje en ik laat RTS gewoon constant actief houden en lees de ruwe data (telegram) uit en dat gooi ik op een webpagina (ik heb een async webserver ook actief op de ESP32). En je raad het al, het telegram is lekker compleet (zie onder)
Ik vermoed dat het gebruik van de arduino serialPort class het probleem opleverde, want dat heeft me vandaag met die ruwe data ook even voor wat denkwerk gezorgd. Maar ik begin het gebruik van SerialPort.read() en aanverwante steeds beter te doorgronden.
Op een of andere manier kwam het processortijdtechnisch zo mooi uit dat het programma bepaalde regels uit het telegram oversloeg (en omdat het zo mooi er uit zag dacht ik niet aan een sreial data verwerkingsprobleem). Dat was het dus toch. Ik ga hiermee aan de slag en heb vandaag weer veel geleerd. Dank jullie allen voor jullie input en hulp.
Onderstaand de data / telegram uit de P1 poort van een ZIV slimme meter model ZIV 5CTA3BCF000AAD0
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| /CTA5ZIV-METER
1-3:0.2.8(50)
0-0:1.0.0(240705211346S)
0-0:96.1.1(***************************)
1-0:1.8.1(003324.436*kWh)
1-0:1.8.2(002379.645*kWh)
1-0:2.8.1(003312.395*kWh)
1-0:2.8.2(007604.497*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(00.158*kW)
1-0:2.7.0(00.037*kW)
0-0:96.7.21(00027)
0-0:96.7.9(00016)
1-0:99.97.0(5)(0-0:96.7.19)(230213161248W)(0001363043*s)(230126082251W)(0000000000*s)(221209091741W)(0000000000*s)(221130031949W)(0000000000*s)(211119070324W)(0000000000*s)
1-0:32.32.0(00000)
1-0:52.32.0(00000)
1-0:72.32.0(00007)
1-0:32.36.0(00950)
1-0:52.36.0(00558)
1-0:72.36.0(00062)
0-0:96.13.0()
1-0:32.7.0(232.0*V)
1-0:52.7.0(232.0*V)
1-0:72.7.0(231.0*V)
1-0:31.7.0(000*A)
1-0:51.7.0(000*A)
1-0:71.7.0(000*A)
1-0:21.7.0(00.097*kW)
1-0:41.7.0(00.000*kW)
1-0:61.7.0(00.072*kW)
1-0:22.7.0(00.000*kW)
1-0:42.7.0(00.039*kW)
1-0:62.7.0(00.000*kW)
!1C56 |
*************************** = data vervangen door asterix vanwege privacy