Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?

[Eike (Gast)]

schwall schwall Gummiball.....hast heute schon dein Tabletten genommen ?

[Günter H. (gnter_h534)]

@ Eike

Im diesem Thread steht folgendes:

Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Eike (Gast)]

Danke Günther,
leider komme ich gar nicht mehr auf die Oberfläche  sodas ich auch keine 
Bin laden kann :(

[Fritte (Gast)]

Es ist noch lange nicht Alles von Jedem gesagt...

[Gerald R. (visitor)]

Hallo miteinander!

Habe heute Morgen die aktuelle Ahoy 0.5.2 
https://github.com/grindylow/ahoy.git geflasht und war dann schon fast 
am Verzweifeln.

E ist ein Fehler in der defines.h wodurch der Wert für powerlimit mit 
dem Wert von NTP_ADDR überschrieben wird.

in defines.h Zeile 99

#define ADDR_NTP_ADDR       ADDR_INV_MAX_RTRY  + INV_MAX_RTRY_LEN

ändern in

#define ADDR_NTP_ADDR       ADDR_INV_PWR_LIM   + INV_PWR_LIM_LEN

Dann funktioniert das PowerLimit.

Vieln dank an alle! Jetzt kann ich auch in der Nacht einspeisen!

Bitte rasch ändern sonst gibt es einen Schwung nasse Augen heute wegen 
Limit 0W.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Hm, schade, ja. Trotzdem herzlichen Dank für deinen Support bis dahin,
> dann werde ich mir das mal zu Gemüte führen, vielleicht verstehe ich es
> ja...

hallo Jörg

habe mal wieder eine quick&dirty version, dieses mal für MI300/600/1500,

kannst du mal bitte das "SettingsCheckThisFirstOutAndChangeName.h" 
anpassen dann auf "Settings.h" aendern und testen?
einfach ohne wifi,mqtt etc.
bool DEBUG_TX_DATA  = 1;  damit wir was sehen

nach dem wir die daten bekommen, können wir alle andere anpassen

[Ziyat T. (toe_c)]

Hallo Leute

Wir versuchen hier ein Projekt durchzuführen, mit so vielen Beitraegen 
(über 2000) wird es immer schwieriger es zu verfolgen.

Also bitte lass das Gequassel über Tabletten und so!

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> kannst du mal bitte das "SettingsCheckThisFirstOutAndChangeName.h"
> anpassen dann auf "Settings.h" aendern und testen?
WOW, was ein Service! Hatte gestern noch auf das xlsx gestarrt und das 
Projekt abgehakt, und jetzt sowas....

Also, vermutlich suchen wir nach sowas hier, oder:

17 MI600
Send... CH61 11601000132143658700F2.....send res 0
New CMD  8a     CH23 00 8765432101 00C4 18 2  8A FFFFFFE6 F77FD57A BB6AAAD96656A95341A2A6BAA7AAA88634 0
9 MI600
Send... CH75 09601000132143658700EA.....send res 0
17 MI600
Send... CH03 11601000132143658700F2.....send res 0
9 MI600
Send... CH23 09601000132143658700EA.....send res 0
17 MI600
Send... CH40 11601000132143658700F2.....send res 0
9 MI600
Send... CH61 09601000132143658700EA.....send res 0
New CMD  8b     CH61 00 8765432101 0080 10 0  8B E5B35477 59DAB6DB 2D55F1B75EB6B55555 0

PS: spricht was dagegen, wifi.h und mqtt.h auszutauschen? Dann kann man 
alles zentral über Settings.h anfassen, was zu individualisieren ist 
(zumindest mittelfristig...)

EDIT: Es zuckt auch mit aktivem WiFi, ist aber nicht durchgängig 
plausibel, siehe angehängten screenshot

[A.D. (Gast)]

Gerald R. schrieb:
> Bitte rasch ändern sonst gibt es einen Schwung nasse Augen heute wegen
> Limit 0W.

Oh ja, den Schwung hatte ich :D

Danke für die Info!!!

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> kannst du mal bitte das "SettingsCheckThisFirstOutAndChangeName.h"
>> anpassen dann auf "Settings.h" aendern und testen?
> WOW, was ein Service! Hatte gestern noch auf das xlsx gestarrt und das
> Projekt abgehakt, und jetzt sowas....

> 9 MI600
> Send... CH75 09601000132143658700EA.....send res 0
> 17 MI600
> Send... CH03 11601000132143658700F2.....send res 0

also wir senden 0x9 und 0x11 das ist mal gut


> PS: spricht was dagegen, wifi.h und mqtt.h auszutauschen? Dann kann man
> alles zentral über Settings.h anfassen, was zu individualisieren ist
> (zumindest mittelfristig...)

im moment will ich nur über serial/minicom die daten kommen sehen, nehme 
an du hast 2 PV's, die im setting.h definiert sind, dann müsste z.B. so 
was kommen:
CH:3 PV0 MI: xxxW Grd:   0W Lm:   0W  xxxW 38.5V 0.0A  854Wh 245.5ACV 
50.0Hz
CH:75 PV1 MI: xxxW Grd:   0W Lm:   0W xxxW 38.5V 0.0A  854Wh 245.5ACV 
50.0Hz

oder, für data
New CMD  89, New CMD 92

dann für die status meldung
New CMD  88, New CMD 91 kommen

EDIT: ev. schickst du mir ein laengeres minicom log?

[Jörg R. (rejoe2)]

Ja, 2 PV's sind definiert. Wenn man das ganze etwas länger laufen läßt, 
werden auch beide gefüllt, die Daten sind im Moment halt nur mehr oder 
weniger inkonsistent, was diese "Nebeninfos" anbelangt (siehe 
Screenshot).

Per minicom -C habe ich jetzt auch einen Mitschnitt gemacht, blöd ist 
nur, dass man da die ganzen loop-Infos drin hat, die das zum einen sehr 
aufblähen, und zum anderen halt nicht wirklich hilfreich sind... Gibt es 
einen besseren Weg, nur den relevanten Teil mitzuschneiden? Per Maus 
markieren ist auch ziemlich - na ja...

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ja, 2 PV's sind definiert. Wenn man das ganze etwas länger laufen läßt,
> werden auch beide gefüllt, die Daten sind im Moment halt nur mehr oder
> weniger inkonsistent, was diese "Nebeninfos" anbelangt (siehe
> Screenshot).
>
> Per minicom -C habe ich jetzt auch einen Mitschnitt gemacht, blöd ist
> nur, dass man da die ganzen loop-Infos drin hat, die das zum einen sehr
> aufblähen, und zum anderen halt nicht wirklich hilfreich sind... Gibt es
> einen besseren Weg, nur den relevanten Teil mitzuschneiden? Per Maus
> markieren ist auch ziemlich - na ja...

ok, im .ino alles mit "\b\b\b\b" auskommentieren, dann sollten nur die 
daten geloggt werden

so wie ich sehe das PV0 (1.PV) kommt rein, aber das 2. nicht oder?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> so wie ich sehe das PV0 (1.PV) kommt rein, aber das 2. nicht oder?

Kurzzeitig hatte ich mal in beiden PVx plausible Watt-Werte stehen. 
Zwischenzeitlich kamen bei den ganzen Versuchen gar keine Werte rein; 
keine Ahnung, ob ich jetzt den/die nRF geschrottet hatte, oder was grade 
los ist - bzw. jetzt habe ich den nRF wieder auf die pa+nla-Variante 
getauscht, jetzt kommen wenigstens Initial-Werte rein, aber im laufenden 
Betrieb sehe ich grade nur die ganzen Send-Anweisungen.

Problem mit der Spannungsversorgung des Ganzen? (Wie ganz am Anfang 
erläutert, ist da eine Adapterplatine dazwischen mit eigenem 
Spannungswandler 5V->3.3V + diversen Kondensatoren, siehe auch die 
Abbildung bei 
https://arduinoinfo.mywikis.net/wiki/Nrf24L01-2.4GHz-HowTo).

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> so wie ich sehe das PV0 (1.PV) kommt rein, aber das 2. nicht oder?
>
> Kurzzeitig hatte ich mal in beiden PVx plausible Watt-Werte stehen.
> Zwischenzeitlich kamen bei den ganzen Versuchen gar keine Werte rein;
> keine Ahnung, ob ich jetzt den/die nRF geschrottet hatte, oder was grade
> los ist - bzw. jetzt habe ich den nRF wieder auf die pa+nla-Variante
> getauscht, jetzt kommen wenigstens Initial-Werte rein, aber im laufenden
> Betrieb sehe ich grade nur die ganzen Send-Anweisungen.
>
> Problem mit der Spannungsversorgung des Ganzen? (Wie ganz am Anfang
> erläutert, ist da eine Adapterplatine dazwischen mit eigenem
> Spannungswandler 5V->3.3V + diversen Kondensatoren, siehe auch die
> Abbildung bei
> https://arduinoinfo.mywikis.net/wiki/Nrf24L01-2.4GHz-HowTo).

mit der spannungsversorgung habe ich mich überhaupt nicht beschaeftigt, 
bei mir leauft es direkt PC>USB>ESP, ich würde raten, dass du beim 
sw-testen auch so faehrst.

aber immerhin waren die werte mal da und plausible..
ich bin mit dem 2.kanal nicht ganz sicher, ob data receipt 0x091 oder 
0x092 ist, das müssen wir noch verifizieren

[Stefan T. (isnoahoy)]

Jörg R. schrieb:
> Ziyat T. schrieb:
> Also, vermutlich suchen wir nach sowas hier, oder:
>

17 MI600
> Send... CH61 11601000132143658700F2.....send res 0
> New CMD  8a     CH23 00 8765432101 00C4 18 2  8A FFFFFFE6 F77FD57A 
> BB6AAAD96656A95341A2A6BAA7AAA88634 0
> 9 MI600
> Send... CH75 09601000132143658700EA.....send res 0
> 17 MI600
> Send... CH03 11601000132143658700F2.....send res 0
> 9 MI600
> Send... CH23 09601000132143658700EA.....send res 0
> 17 MI600
> Send... CH40 11601000132143658700F2.....send res 0
> 9 MI600
> Send... CH61 09601000132143658700EA.....send res 0
> New CMD  8b     CH61 00 8765432101 0080 10 0  8B E5B35477 59DAB6DB 
> 2D55F1B75EB6B55555 0
>

Hallo Joerg / Ziyat T.
Danke dass ihr Euch um die alten Gen2 MI Wechselrichter kümmert, ihr 
seid da ja die Vorreiter was die antiken Schätzchen angeht.
Ja wie ihr schon herausgefunden habt:
* MI-300 verwendet nur einen MPPT, daher Cmd 09
* MI-600 verwendet zwei MPPT, daher Cmd 09 und Cmd 11
* MI-1200 verwendet zwei MPPT mit je zwei Eingänge, daher Cmd 36, 37, 38 
und 39 wie von Ziyat bereits implementiert.

@Joerg R., d.h. Du wirst die Ehre haben MI-300 und MI-600 zu 
implementieren und beide MPPT testen zu können. Ich glaube die Felder 
die vom WR zurückkommen sind bei MI-300,600 und 1200 ziemlich ähnlich. 
Wenn noch Fragen offen sind schau ich für Euch gerne nochmal in den 
DTU-Pro Source Code.
Das Power Limit hatte Ziyat T. ja m.W. auch schon für die Gen2 
MI-Wechselrichter implementiert, das müsste eigentlich auch für 
MI-300/600 gehen.

Viel Erfolg, wenn ihr wollt können wir dafür dann auch einen dev branch 
im Ahoy Repo aufmachen um Eure Änderungen als miSystem.h, miInverter.h, 
etc. zu importieren. Dann müsste Ziyat T. das nicht selbst maintainen ?

[Ziyat T. (toe_c)]

Stefan T. schrieb:
> Jörg R. schrieb:
>> Ziyat T. schrieb:

> Wenn noch Fragen offen sind schau ich für Euch gerne nochmal in den
> DTU-Pro Source Code.

hallo Stefan
eigentlich für mich alles klar bis auf: ich bin mit dem 2.kanal nicht 
ganz sicher, ob data receipt 0x091 oder 0x092 ist, im 
RF_communication_protocol-V6.6.xlsx stehen beide, aber wir werden es 
rausfinden.

> Viel Erfolg, wenn ihr wollt können wir dafür dann auch einen dev branch
> im Ahoy Repo aufmachen um Eure Änderungen als miSystem.h, miInverter.h,
> etc. zu importieren. Dann müsste Ziyat T. das nicht selbst maintainen ?

ja, einverstanden.
es ist sowieso sinnvoller alle holymoly versionen unter einem dach 
anzubieten.

sobald es für MI600 laeuft kannst du es von meinem git holen und machen 
wir bei dir weiter.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> mit der spannungsversorgung habe ich mich überhaupt nicht beschaeftigt,
> bei mir leauft es direkt PC>USB>ESP, ich würde raten, dass du beim
> sw-testen auch so faehrst.
>
> aber immerhin waren die werte mal da und plausible..
> ich bin mit dem 2.kanal nicht ganz sicher, ob data receipt 0x091 oder
> 0x092 ist, das müssen wir noch verifizieren

Irgendwie ist da der Wurm drin. Im Moment bekomme ich gar keine 
Antworten rein, exemplarisch mal ein paar Zeilen (PA-Level ist egal, 
Ergebnis ist immer dasselbe:

DEBUG_RCV_DATA 1
DEBUG_TX_DATA 1
PA_LEVEL 2
WITHWIFI 0
ZEROEXP 0
INTERRUPT 0
SNIFFER 0
ONLY_RX 0
CHECK_CRC 0

SerialIn: 2 Cmd:2
9 MI600
Send... CH23 0960100013785634120062.....send res 0
17 MI600
Send... CH40 116010001378563412007A.....send res 0
9 MI600
Send... CH61 0960100013785634120062.....send res 1
17 MI600
Send... CH75 116010001378563412007A.....send res 0
9 MI600
Send... CH03 0960100013785634120062.....send res 0
17 MI600
Send... CH23 116010001378563412007A.....send res 0
9 MI600
Send... CH40 0960100013785634120062.....send res 0
17 MI600
Send... CH61 116010001378563412007A.....send res 1
9 MI600
Send... CH75 0960100013785634120062.....send res 0
17 MI600
Send... CH03 116010001378563412007A.....send res 0
9 MI600
Send... CH23 0960100013785634120062.....send res 0
17 MI600
Send... CH40 116010001378563412007A.....send res 0
9 MI600
Send... CH61 0960100013785634120062.....send res 1
17 MI600
Send... CH75 116010001378563412007A.....send res 0
9 MI600
Send... CH03 0960100013785634120062.....send res 0
17 MI600
Send... CH23 116010001378563412007A.....send res 0
9 MI600
Send... CH40 0960100013785634120062.....send res 0
17 MI600
Send... CH61 116010001378563412007A.....send res 0
9 MI600
Send... CH75 0960100013785634120062.....send res 0
17 MI600
Send... CH03 116010001378563412007A.....send res 0
9 MI600
Send... CH23 0960100013785634120062.....send res 0
17 MI600
Send... CH40 116010001378563412007A.....send res 0
9 MI600
Send... CH61 0960100013785634120062.....send res 1
17 MI600
Send... CH75 116010001378563412007A.....send res 0
9 MI600
Send... CH03 0960100013785634120062.....send res 0
17 MI600
Send... CH23 116010001378563412007A.....send res 0
9 MI600
Send... CH40 0960100013785634120062.....send res 0
17 MI600
Send... CH61 116010001378563412007A.....send res 1
9 MI600
Send... CH75 0960100013785634120062.....send res 0
17 MI600
Send... CH03 116010001378563412007A.....send res 0
9 MI600
Send... CH23 0960100013785634120062.....send res 0
17 MI600
Send... CH40 116010001378563412007A.....send res 0
9 MI600
Send... CH61 0960100013785634120062.....send res 1
17 MI600
Send... CH75 116010001378563412007A.....send res 0
9 MI600
Send... CH03 0960100013785634120062.....send res 0
17 MI600
Send... CH23 116010001378563412007A.....send res 0
9 MI600
Send... CH40 0960100013785634120062.....send res 0
17 MI600
Send... CH61 116010001378563412007A.....send res 1
9 MI600
Send... CH75 0960100013785634120062.....send res 0
17 MI600
Send... CH03 116010001378563412007A.....send res 0
9 MI600
Send... CH23 0960100013785634120062.....send res 0
17 MI600
Send... CH40 116010001378563412007A.....send res 0
9 MI600
Send... CH61 0960100013785634120062.....send res 1

Aus der "1" zwischendurch hätte ich jetzt geschlossen, dass der nRF 
prinzipiell ansprechbar ist, aber halt entweder effektiv nichts sendet 
oder "nur" nichts mehr hört.

Prinzipiell ist das mit den Adapterplatinen eine feine Sache (wie 
gesagt, ich habe sowohl Erfahrung bei MySensors@nRF24 wie auch den 
MiLight-Hub von Chris Mullins im Einsatz...), aber dann werde ich das 
mit einem neuen ESP nochmal mit einem fliegenden "Direktaufbau" 
versuchen und notfalls meinen Reserve 3.000m-nRF opfern.

Betr. der 92/91-Frage: die betreffenden Stellen im Code hatte ich 
gesehen und auch den Versuch unternommen, das zu tauschen. Vermutlich 
hatte ich aber nicht alle Stellen im Code erwischt, jedenfalls wurden 
die Payloads entweder gleich als ungültig verworfen, oder es kam 
irgendwas absurdes raus. Werde daher jetzt erst nochmal ESP's suchen 
gehen und ein paar Beinchen anlöten, gehe aber davon aus, dass der 92-er 
Ansatz der zielführende bleibt (siehe auch den screenshot von vorhin; da 
passen zumindest die Leistungsdaten vom 2. Kanal)...

Stefan T. schrieb:
> @Joerg R., d.h. Du wirst die Ehre haben MI-300 und MI-600 zu
> implementieren und beide MPPT testen zu können. Ich glaube die Felder
> die vom WR zurückkommen sind bei MI-300,600 und 1200 ziemlich ähnlich.
> Wenn noch Fragen offen sind schau ich für Euch gerne nochmal in den
> DTU-Pro Source Code.
> Das Power Limit hatte Ziyat T. ja m.W. auch schon für die Gen2
> MI-Wechselrichter implementiert, das müsste eigentlich auch für
> MI-300/600 gehen.
>
> Viel Erfolg, wenn ihr wollt können wir dafür dann auch einen dev branch
> im Ahoy Repo aufmachen um Eure Änderungen als miSystem.h, miInverter.h,
> etc. zu importieren. Dann müsste Ziyat T. das nicht selbst maintainen ?

Na ja, freut mich ja, wenn ich was beitragen kann, und es wäre auch 
klasse, wenn das in das allgemeine Ahoy-Projekt mit reinkäme - ich hatte 
uU. die Idee, meine Solarkapazitäten noch auszubauen, und dazu wäre es 
schön, nicht für jeden WR ein eigenes Interface zu benötigen grins.

Wie man das dann integriert, wäre eine weitere Frage, die zumindest 
derzeit noch außerhalb meiner gefühlten Kompetenz liegt. Mal schauen...

[Ziyat T. (toe_c)]

ich habe was gefunden:

https://github.com/OFreddy/hm_poll

sein copyright in allen sources:
/*
 Copyright (C)
  2022            OFreddy

die sw (inhaltlich) ist mehr oder weniger von hier, sogar die kommentare 
stimmen!

:-)

[Stefan T. (isnoahoy)]

Ziyat T. schrieb:
> aber immerhin waren die werte mal da und plausible..
> ich bin mit dem 2.kanal nicht ganz sicher, ob data receipt 0x91 oder
> 0x92 ist, das müssen wir noch verifizieren

Die Antworten haben i.d.R. das erste (höchstwertige) Bit gesetzt:
* Anfrage 0x09 -> Antwort 0x09|0x80=0x89
* Anfrage 0x11 -> Antwort 0x11|0x80=0x91
* Anfrage 0x36 -> Antwort 0x36|0x80=0xB6
* Anfrage 0x37 -> Antwort 0x37|0x80=0xB7
* Anfrage 0x38 -> Antwort 0x38|0x80=0xB8
* Anfrage 0x39 -> Antwort 0x39|0x80=0xB9

Hoffe das hilft.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:

> Aus der "1" zwischendurch hätte ich jetzt geschlossen, dass der nRF
> prinzipiell ansprechbar ist, aber halt entweder effektiv nichts sendet
> oder "nur" nichts mehr hört.

sniffer mode einstellen, schauen ob etwas rein kommt
auf .....send res 0 ist kein verlass

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> sniffer mode einstellen, schauen ob etwas rein kommt
> auf .....send res 0 ist kein verlass

OK, dann schaut es doch so aus, als würde der nRF was hören:

CH75 00 1234567801 0095 12 2  5A 95D95AD2 A4A25214 5555548D85328AC0001000 0
CH3 00 1234567801 00DA 1B 1  D5 AD6EEE56 572CAAAF A96D57D5377FFFCBB777DED77EA9F5BFFE3959DE 0
CH75 00 1234567801 0124 24 2  24 955AA853 500AA4AC FA8A42A5A1499A481000A404A9452052AC455912220000000000000000 0
CH3 00 1234567801 012B 25 1  3A ABAD9756 959D4656 5A8AD5A5BFBFFC550A4B255B9ACCEAAB62AA72E3B5000000000000000000 0
CH75 00 1234567801 0029 05 0  526B42AA4A85D8 
CH3 00 1234567801 00AA 15 1  C5 5A149581 A750D50E 9D3496D2954AEAA8F346ADCDE1DF 0
CH61 00 1234567801 0165 2C 2  B5 F55B2DBD FFFBFFBD Ill remain 37
CH40 00 1234567801 0135 26 2  26 5290412D 52CB4AB0 2EA52AD56AA96DAE6AD9AAAD5BA5EA4B0EB1D6A7EE00000000000000000000 0
CH75 00 1234567801 01EB 3D 1  F8 85080000 00004000 Ill remain 54
CH40 00 1234567801 0195 32 2  66 D54AC94C B5BDAAD5 Ill remain 43
CH3 00 1234567801 01C5 38 2  65 C5950416 D325610A Ill remain 49
CH3 00 1234567801 0039 07 0  8AD725212AE264AAAA 
CH23 00 1234567801 016A 2D 1  B6 D7CB9D6B 51A0B241 Ill remain 38

Oder ist das eine Fehlinterpretation?

(Wäre schön zu wissen, ob sich das mit dem Lötkolben lohnt...)

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> CH3 00 1234567801 01C5 38 2  65 C5950416 D325610A Ill remain 49
> CH3 00 1234567801 0039 07 0  8AD725212AE264AAAA
> CH23 00 1234567801 016A 2D 1  B6 D7CB9D6B 51A0B241 Ill remain 38
> [/code]
> Oder ist das eine Fehlinterpretation?
>
> (Wäre schön zu wissen, ob sich das mit dem Lötkolben lohnt...)

ich würde sagen er hört etwas, ev. NRF sendet nicht?
morgen nach dem wr reset wieder probieren

[Jörg R. (rejoe2)]

Hmmm, kann es sein, dass den WR die hohe Anfragefrequenz stört?

Hatte zwischendurch wieder den WiFi-Modus an und dann wieder Sniffer. 
Wenn ich es richtig interpretiert habe (?), wird im Sniffer-Mode nichts 
gesendet. Es kommen dann aber noch ein paar Messages rein, danach ist 
wieder ziemlich Ruhe. Vielleicht ist das eine Fehlinterpretation, aber 
ggf. ist es kontraproduktiv, zu viele Anfragen zu senden?
Also: DTU meldet: "ich bin da, sende was!"
WR sendet eine Zeitlang wie angefordert, bis wieder eine Art Ping kommt 
für "DTU ist noch da".
Anders gesagt: Das Dauerfeuer, das wir hier veranstalten kommt mir nicht 
plausibel vor....

Auf die Schnelle wäre ein Hinweis hilfreich, wo man die Sendefrequenz 
für die Anfragen reduzieren könnte?

EDIT:
Wg. der libs - bin da alles andere als erfahren, und bevor ich mich da 
reinzufuchsen versuche wäre ein Wink auch ganz nett, wenn ich mich 
einfach gedulden darf...

EDIT2: habe wieder den WiFi-Modus angemacht und jetzt sind wieder für 
Kanal 1 einigermaßen plausible Daten da (v.a. was die (halbe) Leistung 
angeht...

EDIT3: Jetzt sind mir doch noch ein paar Nachrichten ins minicom-log 
geflogen - vielleicht kann jemand was damit anfangen. Die Frequenzen im 
Web-Interface sind jedenfalls nicht plausibel (anders als (meistens) 
vorhin).

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Hmmm, kann es sein, dass den WR die hohe Anfragefrequenz stört?
>
> Hatte zwischendurch wieder den WiFi-Modus an und dann wieder Sniffer.
> Wenn ich es richtig interpretiert habe (?), wird im Sniffer-Mode nichts
> gesendet. Es kommen dann aber noch ein paar Messages rein, danach ist
>>>>>>>>>>>>>

es kann schon sein dass der wr zu macht,

in void isTime2Send (void) die zeile
  if (millis() >= tickMillis) {
    tickMillis += 300;  <<<<<<< mit der kannst du spielen

vom log file:
status v. kanal B, status 3:
CH3 00 1234567801 0082 10 1  92 60100013 60100013 000300000000913454 1

data v. kanal A:
CH75 00 1234567801 00C4 18 2  89 60100013 60100013 
01310023093A138D040408960179D1B273 1
die sind richtig, siehe screenshot im anhang

also diese zeilen aendern:
      case 0x89:    //1-2 ports
      case 0x91:    //2 ports     <<<<<<<<<<<<<<<<<<
        MI600DataMsg(p);
      break;
       case 0x88:    //1-2 ports
       case 0x92:    //2 ports     <<<<<<<<<<<<<<<<<<
          MI600StsMsg(p);
       break;
und:
 if (p->packet[2] == 0x91)  {PV= 1; TotalP[2]=P_DC; pvCnt[1]=1;}//port 2

[Jörg R. (rejoe2)]

Eine Sekunde eingestellt und die Stellen angepaßt => Leistungsdaten für 
Kanal 2 sind plausibel freu
Kanal 1 ist zwar im Moment noch tot, aber da bin ich optimistisch... 
Vielleicht hängt es doch auch an der Spannungsversorgung, das grade 
aktive pa+nla braucht halt mehr Saft als das kleine, und die Frequenz 
ist vielleicht dann das Tröpfchen...?

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Eine Sekunde eingestellt und die Stellen angepaßt => Leistungsdaten für
> Kanal 2 sind plausibel *freu*
> Kanal 1 ist zwar im Moment noch tot, aber da bin ich optimistisch...
> Vielleicht hängt es doch auch an der Spannungsversorgung, das grade
> aktive pa+nla braucht halt mehr Saft als das kleine, und die Frequenz
> ist vielleicht dann das Tröpfchen...?

ja super,
aber eine sekunde ist definitiv zu lang denke ich..
kannst du mal DEBUG_TX_DATA  = 0 stellen und ein minicom log schicken?

[Jörg R. (rejoe2)]

Anbei mal ein log mit 350.

Hab's jetzt wieder mit 300 laufen - hatte ja mal so funktioniert, mal 
schauen....
Kanal 2 kommt allerdings nichts an Leistung, dafür wieder Kanal 1...

[Peter S. (Gast)]

Hi Danke für all Eure tolle Vorarbeit, ich stamme aus der Hardware Ecke 
und mir ist da etwas aufgefallen:
Irgendwann verabschieden sich meine beiden dauer-laufenden 
Installationen gerne mal mit einem watchdog reset (Ursache noch 
unbekannt) und bleiben hängen. Auch ein manueller Reset behebt dann den 
Hanger nicht, erst nach einem Power Reset läuft alles wieder.
Wenn ich in diesem Fall den Serial Output mit 74880 Bd angucke, dann 
sehe ich einen falschen Bootloader Mode:
 ets Jan  8 2013,rst cause:2, boot mode:(1,6)
verursacht durch einen LOW Pegel auf GPIO0 = D3 = IRQ vom NRF-Modul. Man 
sollte also den IRQ besser woanders hinlegen, meine ich.

[Chris (Gast)]

Hallo, ich habe heute mit meinem Hm-1500 das Powerlimit mit v0.5.2 
erfolgreich getestet. Allerdings habe ich das Limit in den Settings 
gesetzt.
- Ist es möglich das Limit über MQTT vorzugeben?
- Wäre eine Anzeige des aktuellen Limit über MQTT möglich / sinnvoll?

Übrigens läuft seit 0.4.26 MQTT perfekt. MQTT "not connected" gibt es 
seitdem nicht mehr!!
Super Job, Danke!!

[Günter H. (gnter_h534)]

Peter S. schrieb:
> Irgendwann verabschieden sich meine beiden dauer-laufenden
> Installationen gerne mal mit einem watchdog reset (Ursache noch
> unbekannt) und bleiben hängen. Auch ein manueller Reset behebt dann den
> Hanger nicht, erst nach einem Power Reset läuft alles wieder.

Diesen Phänomen kann ich bestätigen. Meine Installation ist stabil 
augebaut, das nRF24L01+-Modul hat wird über einen separaten 
3,3V-Spannungsregler versorgt, dennoch bleiben Abstürze nicht aus. 
Erwähnt werden soll aber auch, dass die Stabilität deutlich größer 
geworden ist - mein "Rekord" liegt bei fünf Tagen.

[Joni N. (hal_9000)]

Chris schrieb:
> Hallo, ich habe heute mit meinem Hm-1500 das Powerlimit mit v0.5.2
> erfolgreich getestet. Allerdings habe ich das Limit in den Settings
> gesetzt.
> - Ist es möglich das Limit über MQTT vorzugeben?

Von drschiffler/discord:

subcribed topics are mTopic + "/devcontrol/#" where # is <inverter_id>/<subcmd in dec>
eg. mypvsolar/devcontrol/1/11 with payload "400" --> inverter 1 active power limit 400 Watt
mTopic ist das was im Setup eingetragen ist.
mit <mTopic>/devcontrol/0/0 + payload beliebig --> einschalten
mit <mTopic>/devcontrol/0/1 + payload beliebig --> ausschalten
mit <mTopic>/devcontrol/0/11 + payload xxx --> Limit auf xxx Watt
mit <mTopic>/devcontrol/0/2 + payload beliebig --> neustart
Beispiele alle mit Inverter Id 0

Achtung: Das Limit per MQTT ist nicht-permanent (find ich auch gut & 
richtig so, sonst wird das EEPROM auf Dauer zerstört).

[Stefan T. (isnoahoy)]

Peter S. schrieb:
> Hi Danke für all Eure tolle Vorarbeit, ich stamme aus der Hardware Ecke
> und mir ist da etwas aufgefallen:
> Irgendwann verabschieden sich meine beiden dauer-laufenden
> Installationen gerne mal mit einem watchdog reset (Ursache noch
> unbekannt) und bleiben hängen. Auch ein manueller Reset behebt dann den
> Hanger nicht, erst nach einem Power Reset läuft alles wieder.
> Wenn ich in diesem Fall den Serial Output mit 74880 Bd angucke, dann
> sehe ich einen falschen Bootloader Mode:
>  ets Jan  8 2013,rst cause:2, boot mode:(1,6)
> verursacht durch einen LOW Pegel auf GPIO0 = D3 = IRQ vom NRF-Modul. Man
> sollte also den IRQ besser woanders hinlegen, meine ich.

Hallo Peter S.,

danke für den Hinweis, wir diskutieren das Problem schon seit geraumer 
Zeit in
https://github.com/grindylow/ahoy/issues/36
Ich werde Deine Antwort dort mal hinzufügen. Eigentlich war die 
ursprüngliche Intention die Pins D1/D2 für I2C oder andere zukünftige 
Anwendungen (ModBus485, etc.) freizuhalten.
Bisher hatte ich als Grund für die WDT Resets meist ein Problem in 
umm_malloc ausgemacht. Ich vermute das hängt mit der Nutzung der 
String-Implentierung im ESP8266 zusammen. Weitere Debug Output dazu 
packe ich auch in das o.g. Issue

Gibt es nicht eine einfache Möglichkeit den GPIO0 / D3 beim Booten auf 
High zu ziehen -> RC-Glied ?

[Jörg R. (rejoe2)]

Moin,

anbei mal das, was so über einen Zeitraum von etwa einer Stunde so via 
minicom reingekommen ist. Im Web-Interface ergibt das keine plausiblen 
Daten, aber immerhin wird "irgendwas" empfangen.

Sieht für mich nach einem Problem in der Auswertung aus.

Werd's mal weiter laufen lassen, aber ein direkter Zugriff ist jetzt 
erst mal nicht möglich.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Anbei mal ein log mit 350.
>
> Hab's jetzt wieder mit 300 laufen - hatte ja mal so funktioniert, mal
> schauen....
> Kanal 2 kommt allerdings nichts an Leistung, dafür wieder Kanal 1...

einige anpassungen, mqtt on/off über settings.h
wenn ZEROEXP = 0, keine mqtt subscription "ImpExpW"
viel glück ;-)

[Fritte (Gast)]

Jörg R. schrieb:
> Sieht für mich nach einem Problem in der Auswertung aus.
>
> Werd's mal weiter laufen lassen, aber ein direkter Zugriff ist jetzt
> erst mal nicht möglich.

Wollt ich auch schon immer mal sagen.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Moin,
>
> anbei mal das, was so über einen Zeitraum von etwa einer Stunde so via
> minicom reingekommen ist. Im Web-Interface ergibt das keine plausiblen
> Daten, aber immerhin wird "irgendwas" empfangen.
>
> Sieht für mich nach einem Problem in der Auswertung aus.
>
> Werd's mal weiter laufen lassen, aber ein direkter Zugriff ist jetzt
> erst mal nicht möglich.

diese sind kanal A daten:
CH23 00 1234567801 00C0 18 0  89 60100013 60100013 
014F00140BF555F7FDDEB6AF5B9772FB37 0
CH40 00 1234567801 00C2 18 1  89 60100013 60100013 
01F6DECABF5B5AF55F7D79EDACAB737557 0
CH3 00 1234567801 00C2 18 1  89 60100013 60100013 
01490029091013860520004D7E57F3D6DF 0

diese sind kanal B daten:
CH23 00 1234567801 00C2 18 1  91 60100013 60100013 
07AAD1FDF9F7EF75FBFDF3DF7AFDB6BB2A 0
CH40 00 1234567801 00C4 18 2  91 60100013 60100013 
01510555F576FD7DBBE7B7EBDD3D6BADBB 0
CH61 00 1234567801 00C6 18 3  91 60100013 60100013 
01CB5AF9767B2BFFF5DAA0912210850421 0

wenn 0x89 oder 0x90 kommen, hier sind sie ja, dann müsste 
"MI600DataMsg(p)" aufgerufen werden, dann müsste im serial monitor so 
was stehen:
PV:1 37.30V 0.40A 15.10W 992.00Wh 233.40V 49.99Hz 31.80C  Sts:3 Cnt:0

[Ziyat T. (toe_c)]

diese sind status msg. kanal A
CH75 00 1234567801 0080 10 0  88 60100013 60100013 0003000000008BD407 0
CH61 00 1234567801 0080 10 0  88 60100013 60100013 0003000000008BD40D 1

diese sind status msg. kanal B
CH3 00 1234567801 0082 10 1  92 60100013 60100013 000300000000913F58 0
H61 00 1234567801 0080 10 0  92 60100013 60100013 000300000000911590 1
CH75 00 1234567801 0080 10 0  92 60100013 60100013 0003000039EEBD6B5B 0

beide kanaele sind ON und produzieren (0003)

also, es kommen schon mal richtige daten, das ist doch mal sehr gut, den 
rest schaffen wir doch auch noch

[Ziyat T. (toe_c)]

hallo Jörg
also ich habe die daten überprüft, die sind nicht plausibel, verwende 
bitte das neue .ino im anhang.
ich würde mal in settings.h die CHECK_CRC = 1 stellen und mal keine wifi 
und so.

[Eike (Gast)]

Ich habe mir den dtu White gekauft und drangesteckt. Hier kommt jetzt 
die Fehlermeldung das die sn des Wechselrichter falsch ist. Kann ich die 
irgendwo ermitteln ? Ja ich habe die richtige vom Aufkleber eingetragen.
Ich kann zwar noch immer nicht auf mein opendtu zugreifen aber das mir 
mittlerweile egal

[Eike (Gast)]

Ist erledigt. Läuft.

[Frank L. (guilligan)]

Joni N. schrieb:
> Chris schrieb:
>> Hallo, ich habe heute mit meinem Hm-1500 das Powerlimit mit v0.5.2
>> erfolgreich getestet. Allerdings habe ich das Limit in den Settings
>> gesetzt.
>> - Ist es möglich das Limit über MQTT vorzugeben?
>
> Von drschiffler/discord:
>
>

subcribed topics are mTopic + "/devcontrol/#" where # is 
> <inverter_id>/<subcmd in dec>
> eg. mypvsolar/devcontrol/1/11 with payload "400" --> inverter 1 active 
> power limit 400 Watt
> mTopic ist das was im Setup eingetragen ist.
> mit <mTopic>/devcontrol/0/0 + payload beliebig --> einschalten
> mit <mTopic>/devcontrol/0/1 + payload beliebig --> ausschalten
> mit <mTopic>/devcontrol/0/11 + payload xxx --> Limit auf xxx Watt
> mit <mTopic>/devcontrol/0/2 + payload beliebig --> neustart
> Beispiele alle mit Inverter Id 0

>
> Achtung: Das Limit per MQTT ist nicht-permanent (find ich auch gut &
> richtig so, sonst wird das EEPROM auf Dauer zerstört).


Hallo,
gute Aufbereitung und Hilfe. Leider komme ich damit nicht klar. Über 
Mqtt bekomme ich das nicht hin (Version 0.5.2).
Ich versuche über mqttfx die Limitierung zu senden, aber ohne Erfolg.
Topic: dtu
name: hm600
dann sollte das für den 1. Inverter doch so aussehen:
"dtu/devcontrol/0/11 + payload 400" oder nicht?

Danke für weitere Hilfe.

[Rene M. (Firma: Bitte wählen) (renmo)]

@Frank
So ist es richtig

devControl commands via MQTT Topic (/devcontrol/subcmd + payload); eg. 
mysolar/devcontrol/1/0 --> turn on inverter 1; eg. 
mysolar/devcontrol/1/1 --> turn off; mysolar/devcontrol/0/11 + payload 
"300" --> set power limit for inverter 1 to 300 W (set power is now 
remanent during inverter power cycle and remanent during power cycle of 
ahoy and power limit is set on each reboot/start up THX: @klahus1)
Set power limit in setup page; Save --> writes to eeprom --> reboot --> 
after reboot set power limit acc. to eeprom
Set power limit to zero --> inverter will not stop working (Reactive 
Power <> 0 VAr) but active power will be zero
During change of power limit eg. 200 W --> 500 W, the Powerfactor is not 
controled
Case "set to unlimited power": NOT working by setting it to large 
numbers or -1 or similar. You have to set it acc. to the specific device 
eg. Mi-1500 --> 1500. There is an error handling because the response 
from inverter differs in case the new power limit is NOT accepted. See 
logs.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> bitte das neue .ino im anhang.

Anbei das log dazu. Da aber erst mal gar nichts passiert ist, habe ich 
doch Wifi zugeschaltet.

Jetzt kann man auch besser erkennen, wie die (m.E. zu) wenigen Messages 
in etwa reinkamen. Wenn nicht verändert, macht FHEM ca. alle 5 Min. ein 
publish.

Kurzfassung: Beide Kanäle werden ausgewertet, aber es sind zu wenige 
Datenpunkte und das "Beiwerk" ist komisch. Effektiv was empfangen wird 
mehr oder weniger nur, wenn auch WiFi läuft, warum auch immer.

Habe die effektiv verwendeten Parts dann auch per pull request an dich 
geschickt.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> bitte das neue .ino im anhang.
>
> Anbei das log dazu. Da aber erst mal gar nichts passiert ist, habe ich
> doch Wifi zugeschaltet.
>
> Jetzt kann man auch besser erkennen, wie die (m.E. zu) wenigen Messages
> in etwa reinkamen. Wenn nicht verändert, macht FHEM ca. alle 5 Min. ein
> publish.
>
> Kurzfassung: Beide Kanäle werden ausgewertet, aber es sind zu wenige
> Datenpunkte und das "Beiwerk" ist komisch. Effektiv was empfangen wird
> mehr oder weniger nur, wenn auch WiFi läuft, warum auch immer.
>
> Habe die effektiv verwendeten Parts dann auch per pull request an dich
> geschickt.

das ist interresant, dass mit wifi "mehr" empfangen kannst, bei mir ist 
das genau umgekehrt!
die daten sind irgendwie in der luft zu fest gestört, darum mit 
CHECK_CRC=1 siehst du selten etwas.

wenn du mein letztes .ino verwendest:
- wir sehen welche und wie viele daten nicht plausibel sind
- in settings.h WITHMQTT = 0 stellen, dann sollten diese meldg. nicht 
mehr kommen:
Attempting to connect to the MQTT broker: 192.168.2.2
MQTT connected = 0
Subscribing to topics..

so haben wir "saubere" logs.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> die daten sind irgendwie in der luft zu fest gestört, darum mit
> CHECK_CRC=1 siehst du selten etwas.

Na ja, hier läuft halt "alles" zusammen: WLAN, BT, ZigBee, (selten 
MiLight) und nun eben (wieder) nRF24. Habe den CRC-Check jetzt mal 
ausgeschaltet und lass das Ding auch über Nacht laufen, eigentlich 
sollte kaum noch was vom WR kommen (vorhin waren 7 Watt oder so).
Der MQTT-Import-Code hat übrigens eine Macke: Immer wenn es eine Stelle 
weniger wird, bleiben die hinteren stehen, aus 101 => 98 werden dann 
981W (leider nicht in der Realität...)

[Carsten B. (carstenb)]

Manuel M. schrieb:
> Ich übertrage die Daten zu meinem FHEM-Hausautomatisierungs-Raspberry
> über MQTT.
>
> Mir sind zwei Dinge aufgefallen:
> 1) IDC und ADC werden je Channel übertragen - es wird aber der gleiche
> Name verwendet. Besser wäre IDC1 und IDC2 ... Sonst wird der 1. Channel
> vom Wert des 2. Channels sofort überschrieben.

Hallo Manuel,

hast du es in FHEM eigentlich noch hinbekommen? Ich kann die Daten 
meiner beiden Wechselrichter und der Channels nicht unterscheiden im 
Fhem. Ich bin allerdings auch totaler Noob, was MQTT angeht. Hast du 
vielleicht ein Beipiel für mich aus deiner Konfig? Oder eine gute 
Quelle, wo ich mich dazu einlesen kann?

Gruß

Carsten

[Jörg R. (rejoe2)]

Carsten B. schrieb:
> hast du es in FHEM eigentlich noch hinbekommen?

Es gibt einen ersten attrTemplate-Vorschlag dazu im FHEM-Forum. Bitte 
ggf. da anhängen.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> die daten sind irgendwie in der luft zu fest gestört, darum mit
> CHECK_CRC=1 siehst du selten etwas.

....da scheint wirklich viel los zu sein, hier mal ein Auszug von dem, 
was ohne CRC-Check vorhin los war. Habe dazu mal PA_MIN eingestellt und 
bin dann etwas weiter weg, dann war das besser.

CH23 00 1234567801 00C6 18 3  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFF56001900CADB78ED 0
New CMD  ff     CH23 00 1234567801 00C6 18 3  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFF56001900CADB78ED 0
CH23 00 1234567801 00C6 18 3  97 FFFFFFFF FFFDCD58 E6C6AA5D2A2151BFC20000000000000000 0
New CMD  97     CH23 00 1234567801 00C6 18 3  97 FFFFFFFF FFFDCD58 E6C6AA5D2A2151BFC20000000000000000 0
CH23 00 1234567801 0080 10 0  89 6FFFFFFF FF4AD0B5 68A85A6C99A45551FF 0
CH23 00 1234567801 00DF 1B 3  FD FFFFFFFF FF7EFFFF FFFFFFFFFFFFFFFFF754001900C9DC20553FFFFF 0
New CMD  fd     CH23 00 1234567801 00DF 1B 3  FD FFFFFFFF FF7EFFFF FFFFFFFFFFFFFFFFF754001900C9DC20553FFFFF 0
CH23 00 1234567801 00C3 18 1  FF FFF02D76 AAAD1CA2 4AA2BED62EC38AFF820000000000000001 0
New CMD  ff     CH23 00 1234567801 00C3 18 1  FF FFF02D76 AAAD1CA2 4AA2BED62EC38AFF820000000000000001 0
CH23 00 1234567801 00FF 1F 3  FF FFFFF4BA 6A8A96F6 AC2A4985F55A3FA40000000000000000000B25ADC9000000 0
New CMD  ff     CH23 00 1234567801 00FF 1F 3  FF FFFFF4BA 6A8A96F6 AC2A4985F55A3FA40000000000000000000B25ADC9000000 0
CH23 00 1234567801 00C4 18 2  9F FFFFFFF7 FFFFFD4A 552EAB8B15496A27F90000000000000000 0
New CMD  9f     CH23 00 1234567801 00C4 18 2  9F FFFFFFF7 FFFFFD4A 552EAB8B15496A27F90000000000000000 0
CH3 00 1234567801 0082 10 1  91 7FFFFBFF FFFFFFFF EFFE5A94B1AC505550 0
CH3 00 1234567801 00C2 18 1  91 67FFFFFF FFFFFFEB FFFFFFFFFFFFC8ADA4FF00000000000000 0
CH3 00 1234567801 00C4 18 2  89 7FF7FFFF FFFDFFFF FDFFFBFFFFFFFFDFFFFFFFAB00CCB19974 0
CH23 00 1234567801 00C4 18 2  9F FFFFFFFF FBFFFFFF FFFFDFFFFFFFFFFFFFFF400900CCB1997C 0
New CMD  9f     CH23 00 1234567801 00C4 18 2  9F FFFFFFFF FBFFFFFF FFFFDFFFFFFFFFFFFFFF400900CCB1997C 0
CH23 00 1234567801 00FF 1F 3  FF D852A545 52AEA8A4 694B45502AEA8DF500000000000000000032B2CAA5000000 0
New CMD  ff     CH23 00 1234567801 00FF 1F 3  FF D852A545 52AEA8A4 694B45502AEA8DF500000000000000000032B2CAA5000000 0
CH23 00 1234567801 01FF 3F 3  FF FFFFFFFF FFFFFFFF Ill remain 56
New CMD  ff     CH23 00 1234567801 01FF 3F 3  FF FFFFFFFF FFFFFFFF Ill remain 56
CH23 00 1234567801 01FB 3F 1  FF FFFFFFFF BFFFFFFF Ill remain 56
New CMD  ff     CH23 00 1234567801 01FB 3F 1  FF FFFFFFFF BFFFFFFF Ill remain 56
CH3 00 1234567801 00C6 18 3  91 6011FFFF FFFFFFFF FFFFFFFFFFF495584BA3FE100000000000 0
CH23 00 1234567801 00FF 1F 3  FF FFFFFFFF FFFFFFFF FFDFFFFFFFF7FFFFFB7C000900CDA831F13FFFFFFF000000 0
New CMD  ff     CH23 00 1234567801 00FF 1F 3  FF FFFFFFFF FFFFFFFF FFDFFFFFFFF7FFFFFB7C000900CDA831F13FFFFFFF000000 0
CH23 00 1234567801 00DF 1B 3  FF FFFFFFFF FFFFFFFF FFFFFFFFFFE6B7FC0000000000000000002CA552 0
New CMD  ff     CH23 00 1234567801 00DF 1B 3  FF FFFFFFFF FFFFFFFF FFFFFFFFFFE6B7FC0000000000000000002CA552 0
CH23 00 1234567801 00FF 1F 3  EF F663A89A 9394B692 AAB52652AA693FD000000000000000000036D54A65000000 FE5F FE5F 42D1 42D1 80
New CMD  ef     CH23 00 1234567801 00FF 1F 3  EF F663A89A 9394B692 AAB52652AA693FD000000000000000000036D54A65000000 0
CH23 00 1234567801 00DF 1B 3  FF FF5368B6 F6AA70EB B5120A32DBA627F80000000000000000002916AD 0
New CMD  ff     CH23 00 1234567801 00DF 1B 3  FF FF5368B6 F6AA70EB B5120A32DBA627F80000000000000000002916AD 0
CH23 00 1234567801 00C0 18 0  8F FFFFFFFF FFFFFFFF FFE2EA98A5359EB7F90000000000000000 0
WRInfo(0x8f) is ok CMD 8f WR ff:ff:ff:ff HWPN: 255.226 HWVers: 234.152 APPFVers: 165.53 GPFCode: 158.183 GPFVers:: 249.0 0
New CMD  ff     CH23 00 1234567801 00CF 19 3  FF FFFD74E5 DCA9152A FB6ADBA54AA9ABFD00000000000000000037 0
CH3 00 1234567801 0080 10 0  91 67FFFFFF DFFFFFFF FFF7FFFFFFFFFFFFFD 0
CH23 00 1234567801 01FF 3F 3  FF FFFFFFFB FFFFF3AC Ill remain 56
New CMD  ff     CH23 00 1234567801 01FF 3F 3  FF FFFFFFFB FFFFF3AC Ill remain 56
CH23 00 1234567801 00C0 18 0  91 7FFFFFFF FEFFFFFF FFFFFFD2D6A3AD5AD7FA00000000000000 0
CH23 00 1234567801 00C0 18 0  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFDA801B00CDC0F2F8 0
New CMD  ff     CH23 00 1234567801 00C0 18 0  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFDA801B00CDC0F2F8 0
CH23 00 1234567801 00C3 18 1  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFFF501C00CDC3EEDE 0
New CMD  ff     CH23 00 1234567801 00C3 18 1  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFFF501C00CDC3EEDE 0
CH23 00 1234567801 00C7 18 3  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFF6A000900CE8C38A4 0
New CMD  ff     CH23 00 1234567801 00C7 18 3  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFF6A000900CE8C38A4 0
CH23 00 1234567801 00C0 18 0  89 FFFFFFFF 7EFFFFFF FFFDFFFFFFFFFBFFFFFFD40900CE8C1032 0
CH23 00 1234567801 00C1 18 0  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFEA800900CE8C1032 0
New CMD  ff     CH23 00 1234567801 00C1 18 0  FF FFFFFFFF FFFFFFFF FFFFFFFFFFFFFFFFFFEA800900CE8C1032 0
CH23 00 1234567801 00FF 1F 3  FF FFFFFFFF FFFFFFFF FFAD94AB0AAACFF60000000000000000002A556B56000000 0
New CMD  ff     CH23 00 1234567801 00FF 1F 3  FF FFFFFFFF FFFFFFFF FFAD94AB0AAACFF60000000000000000002A556B56000000 0
CH23 00 1234567801 00C6 18 3  9F FFFFFFFF FFFEFFFF FFFFFFFFFFFFFFFFFFFF401D00CEFA703D 0
New CMD  9f     CH23 00 1234567801 00C6 18 3  9F FFFFFFFF FFFEFFFF FFFFFFFFFFFFFFFFFFFF401D00CEFA703D 0
CH23 00 1234567801 01FF 3F 3  FF FFFFFFFF FFFFFFFF Ill remain 56
New CMD  ff     CH23 00 1234567801 01FF 3F 3  FF FFFFFFFF FFFFFFFF Ill remain 56
CH23 00 1234567801 00DF 1B 3  FF FFFFFFFF FD514615 A245A5890A11D3FE0000000000000000002A8A4A 0
New CMD  ff     CH23 00 1234567801 00DF 1B 3  FF FFFFFFFF FD514615 A245A5890A11D3FE0000000000000000002A8A4A 0
CH23 00 1234567801 01FF 3F 3  FF FFFFFFFF FFFFFFFF Ill remain 56
New CMD  ff     CH23 00 1234567801 01FF 3F 3  FF FFFFFFFF FFFFFFFF Ill remain 56
CH23 00 1234567801 00FE 1F 3  FF FEF7F7FF FFFFDFFF FFFFFFFFFFFFBFFFFBA3000A00CF63A3273FFFFDFF000000 0
New CMD  ff     CH23 00 1234567801 00FE 1F 3  FF FEF7F7FF FFFFDFFF FFFFFFFFFFFFBFFFFBA3000A00CF63A3273FFFFDFF000000 0
CH23 00 1234567801 00FF 1F 3  FF FFBFFFFF FFFFF7FF FFFDFFDFFFFFFFFFF770001E00CEEE549A3F4AAC94000000 2 CA72 6B2A 6B2A 39E80
New CMD  ff     CH23 00 1234567801 00FF 1F 3  FF FFBFFFFF FFFFF7FF FFFDFFDFFFFFFFFFF770001E00CEEE549A3F4AAC94000000 0
CH23 00 1234567801 00CF 19 3  FF FFFFFFFF F5FFFFFB FFFFFFFFFBFFABFF00000000000000000026 0
New CMD  ff     CH23 00 1234567801 00CF 19 3  FF FFFFFFFF F5FFFFFB FFFFFFFFFBFFABFF00000000000000000026 0
CH23 00 1234567801 00C3 18 1  FF FFFFFFFF 7FF7FFFF FFFFDFEFFFFFFDFFFFB5000A00CE7F92CE 0
New CMD  ff     CH23 00 1234567801 00C3 18 1  FF FFFFFFFF 7FF7FFFF FFFFDFEFFFFFFDFFFFB5000A00CE7F92CE 0
CH23 00 1234567801 00FF 1F 3  FA CD55D16D 6DBEB652 AF1FA155634594FF4100000000000000002B92DAA8000000 0
New CMD  fa     CH23 00 1234567801 00FF 1F 3  FA CD55D16D 6DBEB652 AF1FA155634594FF4100000000000000002B92DAA8000000 0
CH23 00 1234567801 00C2 18 1  8F FDFFDFDF FFFFBFFF FBFFBFEFFFFFFFFFFFFA800A00D066505D 0
WRInfo(0x8f) is ok CMD 8f WR ff:ff:bf:ff HWPN: 251.255 HWVers: 191.239 APPFVers: 255.255 GPFCode: 255.255 GPFVers:: 255.20
New CMD  ff     CH23 00 1234567801 00FF 1F 3  FF FFFFFFFF FDFFEFFF 556AA4B53B3A9FFA0110000000000000003BBFA9BE000000 0
CH23 00 1234567801 00DF 1B 3  FF FFFFFFFF FFC6D510 8D5A9C84500F6FF80000000000000000003D4A75 0
New CMD  ff     CH23 00 1234567801 00DF 1B 3  FF FFFFFFFF FFC6D510 8D5A9C84500F6FF80000000000000000003D4A75 0
CH23 00 1234567801 01FF 3F 3  FF FF504144 8500A452 Ill remain 56
New CMD  ff     CH23 00 1234567801 01FF 3F 3  FF FF504144 8500A452 Ill remain 56

Werde bei Gelegenheit wirklich nochmal neue Hardware aufbauen, irgendwie 
ist das zu wackelig, was ich grade da habe.

[Ha F. (harry_f)]

Für alle die, die die MQTT-Struktur für SubCMD 11 PowerLimit suchen.
Diese muss man selbst anlegen.

Ich benutze den IoBroker. Manchmal funktioniert die Umwandlung der 
Payload in Integer nicht korrekt.
Bsp:  Eingabe 600  und im WebIF steht dann 60000W.

[Ha F. (harry_f)]

Nachtrag zu obigen Post zum Power Limit:

Ein Wert 500 begrenzt nicht auf 500 Watt, sondern auf 50.0% auf die max 
Leistung des WR.

Somit ist die Anzeige in der Visualisierung fehlerhaft mit 500W.
Es sollte 50.0% von X MaxWatt lauten.

Kann das jemand so bestätigen?

[Günter H. (gnter_h534)]

Ich betreibe einen HM600 z. Z. mit einem Modul.

Wenn ich unter 0.5.4 im Setup 150 W Limit einstelle, ist das Limit für 
das eine Modul 75W.

Mit Limit 600 W waren zu diesem Zeitpunkt ca. 230 W für ein Modul 
möglich.

[Frank L. (guilligan)]

Ha F. schrieb:
> Nachtrag zu obigen Post zum Power Limit:
>
> Ein Wert 500 begrenzt nicht auf 500 Watt, sondern auf 50.0% auf die max
> Leistung des WR.
>
> Somit ist die Anzeige in der Visualisierung fehlerhaft mit 500W.
> Es sollte 50.0% von X MaxWatt lauten.
>
> Kann das jemand so bestätigen?

Ich kann das nicht bestätigen.
.../devcontrol/0/11 500   >>>bringt bei mir das 500 Watt Limit.

[Ha F. (harry_f)]

Ha F. schrieb:
> Nachtrag zu obigen Post zum Power Limit:
>
> Ein Wert 500 begrenzt nicht auf 500 Watt, sondern auf 50.0% auf die max
> Leistung des WR.
>
> Somit ist die Anzeige in der Visualisierung fehlerhaft mit 500W.
> Es sollte 50.0% von X MaxWatt lauten.
>
> Kann das jemand so bestätigen?

Ok jetzt ist bei mir das Ergebnis anders wie oben beschrieben.
Jetzt regelt der WR mit dem Wert 300 (aus MQTT) auf 300W 
Ausgangsleistung (+-)

Irgendwie war durch vorherige Experimente das Verhalten heute morgen 
anders.

Oder kann man das irgendwie steuern ob Watt oder % Limitierung?

[Friedhelm E. (fritsche)]

Hallo,
@hubi
Habe die letzte Version Deiner SW aufgespielt, funktioniert sehr gut.
Da ich aber inzwischen einen weiteren HM-800 habe, frage ich mich, wie 
man den
2.WR im Setting einbinden kann. Habe die Anzahl der WR auf 2 eingestellt 
und die Daten für den 2.WR als HM-600 eingegeben. Konnte alles 
programmieren , aber auf die Channelabfrage kommt keine Antwort. Die 
Einzelabfrage vom 1.WR und vom 2.WR funktioniert. Bitte um Hilfe.

einen guten Tag
fritsche

[Gerald R. (visitor)]

Günter H. schrieb:
> Wenn ich unter 0.5.4 im Setup 150 W Limit einstelle, ist das Limit für
> das eine Modul 75W.

Das kann ich bestätigen, ist bei meinem HM 800 auch so.
Leistung pro Eingang = gedrosselte Leistung / 2
Hier wird vermutlich die Gesamtleistung limitiert und intern vom 
Wechselrichter durch die Anzahl der Eingänge dividiert.

[Klaus H. (klahi)]

Gerald R. schrieb:
> Das kann ich bestätigen, ist bei meinem HM 800 auch so.
> Leistung pro Eingang = gedrosselte Leistung / 2
> Hier wird vermutlich die Gesamtleistung limitiert und intern vom
> Wechselrichter durch die Anzahl der Eingänge dividiert.
Das wäre schon wichtig, ob die Ausgangsleistung oder an den Eingängen 
begrenzt wird. Mein Plan mit Ost-West Ausrichtung bräuchte eine 
Begrenzung der Ausgangsleistung. Wenn die Westsonne kräftig scheint, 
möchte ich bis 600W vom Westen nutzen und nicht maximal 300W vom Westen 
und nicht vorhandene 300W vom Osten.
Kann mich da jemand beruhigen?

[Hubi (Gast)]

Friedhelm E. schrieb:
> Konnte alles
> programmieren , aber auf die Channelabfrage kommt keine Antwort. Die
> Einzelabfrage vom 1.WR und vom 2.WR funktioniert. Bitte um Hilfe.

Sorry, das Problem hatte ich schon mal letzte Seite von diesem Thread 
und dachte es wäre gelöst. Ich hatte das mit einer Simulation versucht 
zu lösen,  1WR mit 2 setups und dann jeweils simulierte Serials, und das 
hat auch geklappt. im Moment weiß ich nicht wie ich dir weiterhelfen 
kann, habe eben nur 1 WR. Ich versuche nochmals das ganze zu simulieren.

[Dirk S. (fusebit)]

Habe jetzt meine Panels bekommen.
Ahoy läuft jetzt auf einem RasPi Zero.
Auch mein HM-300 antwortet erst nachdem er 30 Minuten aktiv ist.

Ab jetzt kann ich gerne mithelfen, für mehr als beta-Test reichen meine 
Programmierfähigkeiten aber nicht aus.

[Ha F. (harry_f)]

Klaus H. schrieb:
> Gerald R. schrieb:
>> Das kann ich bestätigen, ist bei meinem HM 800 auch so.
>> Leistung pro Eingang = gedrosselte Leistung / 2
>> Hier wird vermutlich die Gesamtleistung limitiert und intern vom
>> Wechselrichter durch die Anzahl der Eingänge dividiert.
> Das wäre schon wichtig, ob die Ausgangsleistung oder an den Eingängen
> begrenzt wird. Mein Plan mit Ost-West Ausrichtung bräuchte eine
> Begrenzung der Ausgangsleistung. Wenn die Westsonne kräftig scheint,
> möchte ich bis 600W vom Westen nutzen und nicht maximal 300W vom Westen
> und nicht vorhandene 300W vom Osten.
> Kann mich da jemand beruhigen?

Evlt hilft es:

Setup:
Version 0.5.4
HM-600    2x  340Wp Ost/West

Hab mal Bilder gemacht. Man beachte den Unterschied zwischen 300W und 
100W Limit auf den einzelnen Seiten.

[Jörg R. (rejoe2)]

Liest hier eigentlich noch jemand mit von den anderen "MI"-Besitzern?
Es müßte ja neben Ziyat T und mir noch ca. eine Handvoll geben, die WR 
mit "10"-er Seriennummern haben.
Die "ino3" von Ziyat T. ist jedenfalls bereits so ausgelegt, dass man 
neben diversen Zugangsdaten "nur" den WR-Grundtyp passend einstellen 
muss, also falls jemand das bisher frustriert in die Ecke gelegt hatte: 
Welcome on board again!

Irgendwo hier war zu lesen, dass man unbedingt einen nRF24L01+ 
benötigen würde. Wenn meine Interpretation von 
https://forum.mysensors.org/topic/9266/guide-nrf5-nrf51-nrf52-for-beginners 
zutreffend ist, müßte eigentlich auch die "neue Generation" 
(insbesondere nRF52) noch das alte "shockburst"-Protokoll beherrschen, 
so dass z.B. ein E73-Board von Ebyte ebenfalls als Transceiver genutzt 
werden könnte. Ein paar der nRF52-Varianten beherrschen übrigens auch 
ZigBee, so dass man damit ggf. auch eine Art "Universalgateway" basteln 
könnte, das dann auch die APSystems-WR ansprechen könnte... (Siehe 
https://www.nordicsemi.com/-/media/Software-and-other-downloads/Product-Briefs/nRF52832-product-brief.pdf, 
Tabelle auf S. 1)

Habe gestern übrigens noch etwas gelötet, einen anderen ESP geflasht und 
das "gute" 100mW-nRF24 mit shield ausgepackt - das halft alles nichts, 
die empfangenen Packete sind weiter zum großen Teil einfach kaputt. 
Zwischenzeitlich hätte ich auch eine Theorie anzubieten, warum das so 
ist: Mein "Testort" befand sich meistens (leicht schräg, aber) _direkt 
unter der Unterseite_ des MI. Der hat aber keine externe Antenne, also 
muss das Signal nicht nur durch das Gehäuse, sondern ggf. auch "durch" 
das ganze sonstige Elektro-Material => nicht optimal. Vermutlich sind 
die so aufgebaut, dass die auch eher "zur Seite hin" optimiert 
abstrahlen: Die nRF beherrschen ja auch Mesh, und wenn man (wie in den 
Prospekten gezeigt) größere Flächen damit abdecken möchte, muss man ggf. 
eben zwischendurch einen anderen nRF als "Zwischenstation" nutzen. Dazu 
paßt ja auch, dass man immer zwei Adressen übermittelt bekommt: Die 
Sender-Adresse und die des "letzten hop" (so kann man das übrigens auch 
bei MySensors-Repeatern beobachten). Da wir meistens eine direkte 
Kommunikation sehen entspricht der letzte hop einfach der des Senders.

Werde das bei Gelegenheit mal testen, ob ich einen besseren Platz zum 
längerfristigen Testen finde, jedenfalls waren die Zwischenresultate auf 
der Terrasse eher besser als direkt unter dem MI. Für's weitere Testen 
ist eh' der Plan, den Verkehr über ein ausrangiertes MySenors-GW auf 
Arduino-Nano-Basis zu sniffen und den ESP vor sich hin tuckern zu 
lassen... (@Ziyat T: als Watt-"Info" bekommt er dann vorläufig einfach 
den 10-fachen Messwert).

Wird aber dauern, bis wieder Zeit ist, das etwas intensiver zu 
beleuchten (daher auch meine Frage nach weiteren Usern, die ggf. jetzt 
wieder einsteigen möchten).

[Friedhelm E. (fritsche)]

Hallo,
Hubi(Gast) schrieb: 1WR mit 2 setups und dann jeweils simulierte Serials
Habe die setting.h so abgeändert:
#define MAX_ANZ_INV             2

#include "Inverters.h"

#if MAX_ANZ_INV >= 1
#include "HM600.h"
#define WR1_NAME "HM-600"
#define WR1_SERIAL 0x1141xxxxxxxxULL
#define WR1_MEASUREDEF hm600_measureDef
#define WR1_MEASURECALC hm600_measureCalc
#define WR1_FRAGMENTS hm600_fragmentLen
uint16_t WR1_MODULEPEAKS[] = {2, 370, 370};
#endif

// Beispiel für 2. WR
#if MAX_ANZ_INV >= 2
#include "HM600.h"
#define WR2_NAME "HM-600"
#define WR2_SERIAL 0x1141yyyyyyyyULL
#define WR2_MEASUREDEF hm600_measureDef
#define WR2_MEASURECALC hm600_measureCalc
#define WR2_FRAGMENTS hm600_fragmentLen
uint16_t WR2_MODULEPEAKS[] = {2, 370, 370};
#endif
Ich bin mir nicht sicher ob Du das so gemeint hast.
Ist noch eine Eingabe für den 2ten WR notwendig?

Grüße
Fritsche

[Hubi (Gast)]

Friedhelm E. schrieb:
> Ich bin mir nicht sicher ob Du das so gemeint hast.
> Ist noch eine Eingabe für den 2ten WR notwendig?

Eigentlich ist sonst nichts zu machen, wenn du 2xHM600 hast, außer den 
Namen des 2.WR ändern, damit du unterscheiden kannst.
Den Bug habe ich gefunden, warum es mit 2 nicht funzt.
Ändere mal in der loop() die Zeile
  if ((packetBuffer.available() >= totalFragments && packetsComplete())

in
  if ((packetBuffer.available() >= inverters[aktWR].fragmentCount && 
packetsComplete())

ab, dann sollte es gehen. Wenigstens bei mir hat das in der Simulation 
mit 1 WR geklappt.
Änderung ist auch in meinem github drin.

[Klaus H. (klahi)]

Von Ha F.

>Setup:
>Version 0.5.4
>HM-600    2x  340Wp Ost/West
>
>Hab mal Bilder gemacht. Man beachte den Unterschied zwischen 300W und
>100W Limit auf den einzelnen Seiten.

Vielen Dank. Ich bin beruhigt :-) Die Leistungsbegrenzung wirkt auf die 
Leistung am Ausgang "P_AC", nicht auf die Leistungen der Eingänge 
"P_DC".

Zwar gibt es leichte Unterschiede zwischen der Summe aller P_DC und 
P_AC. Das kann durch interne Wandlungsverluste, Messfehler oder 
unterschiedliche Zeitpunkte der Datenabfrage verursacht sein. Das macht 
mir keine Gedanken.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Irgendwo hier war zu lesen, dass man unbedingt einen nRF24L01+
> benötigen würde. Wenn meine Interpretation von
> https://forum.mysensors.org/topic/9266/guide-nrf5-nrf51-nrf52-for-beginners

ich hab beim nordic/devzone auch gelesen:
"The nRF52 is capable of 255-byte payloads in both SB and ESB modes"

>
> Habe gestern übrigens noch etwas gelötet, einen anderen ESP geflasht und
> das "gute" 100mW-nRF24 mit shield ausgepackt - das halft alles nichts,
> die empfangenen Packete sind weiter zum großen Teil einfach kaputt.
> Zwischenzeitlich hätte ich auch eine Theorie anzubieten, warum das so
> ist: Mein "Testort" befand sich meistens (leicht schräg, aber) _direkt
> unter der Unterseite_ des MI. Der hat aber keine externe Antenne, also
> muss das Signal nicht nur durch das Gehäuse, sondern ggf. auch "durch"
> das ganze sonstige Elektro-Material => nicht optimal. Vermutlich sind
> die so aufgebaut, dass die auch eher "zur Seite hin" optimiert
> abstrahlen:

ja, kann es bestaetigen, direkt unter MI ist weniger empfang

 (@Ziyat T: als Watt-"Info" bekommt er dann vorläufig einfach
> den 10-fachen Messwert).
 das habe ich nicht verstanden?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> ich hab beim nordic/devzone auch gelesen:
> "The nRF52 is capable of 255-byte payloads in both SB and ESB modes"
grins - die Frage ist nur, ob einen das wirklich weiterbringt...
Der E73, der hier rumliegt (weil ich erst dachte, "nordic proprietäry 
wäre vielleicht "Gazelle") ist zwar schön anzusehen, aber vermutlich 
schwieriger zu handhaben wie ein einfacher nRF24L01+ (wenn man denn 
keinen fake erwischt!), weil er die (M4?-) MCU gleich mitbringt, dafür 
aber kein WLAN oä...

> ja, kann es bestaetigen, direkt unter MI ist weniger empfang
Na dann bin ich mal positiv gespannt, wie das bei meinem nächsten 
Test-Ort sein wird und ob die "kleinen" (ohne pa etc.) dann doch 
tauglich/ausreichend sind!

Was den Teil der eigentlichen Auswertungen angeht, scheinen wir ja an 
sich soweit zu sein, dass man (ggf. abgesehen von einem gewissen 
Restbestand von echten "new CMD"-Funden beim Sniffen) versuchen könnte, 
den jetzigen Code als "mi-"Bibliotheken in den "ahoy-ESP" einzubinden?
Denn wenn was mit passendem CRC empfangen wurde, war auch die Anzeige im 
Web-Interface soweit ok.
Für's sniffen wäre dann der Arduino das Mittel der Wahl. Oder wie siehst 
du das?

Zugegebenermaßen hat das bisherige Starren auf die NRF24_SendRcv.ino 
(deine V3) einerseits und ahoy/tree/main/tools/esp8266 andererseits 
bisher nicht dazu geführt, dass das Licht besonders hell geworden wäre. 
Immerhin gibt es auch bei hmSystem.h drei (anhand der Seriennummer 
unterschiedene) Klassen von WR. Den Part könnte man also vermutlich 
recht einfach übernehmen, und auch die Nummernbereiche sollten (lt. der 
Excel-Seriennummern-Liste) soweit passen, aber dann....?!?

Vielleicht möchte doch einer der C++-Cracks hier den Versuch unternehmen 
nachobenschau - ich teste herzlichst gerne und habe aktuell auch 3x 
Hardware zur Verfügung (2*D1 mini, 1 Nano)?

>  (@Ziyat T: als Watt-"Info" bekommt er dann vorläufig einfach
>> den 10-fachen Messwert).
>  das habe ich nicht verstanden?
War mir nicht ganz sicher, welche Gründe es gab, unbedingt den MQTT-Teil 
abzuschalten und hatte dann vermutet, dass du darüber vielleicht die 
Leistungsvorgabe machst, was dann eben meinen MI unnötig ausgebremst 
hätte (weil ich da den laufenden Messwert reingeschubst habe). Daher der 
Gedanke, den sicherheitshalber (ohne weitere Code-Analyse) ausreichend 
hoch zu setzen, ohne auf "Aktualität" in der Web-Anzeige verzichten zu 
müssen.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> den jetzigen Code als "mi-"Bibliotheken in den "ahoy-ESP" einzubinden?

das ist wiederum nicht so ganz einfach, zuerst müssen die parser (tx/rx) 
angepasst werden, weil bei den MI's, 2 verschiedene (MI300/600 und 
MI1000/1500) völlig andere tx/rx msgs sind. da müsste grundsaetzlich im 
ahoy-esp etwas geschehen und der adressat ist mmn "isnoahoy" Stefan. den 
rest könnten wir schon noch reinkriegen.
(edit: muss sagen, dass ich die letzte version von ahoy-esp nicht 
angeschaut habe)
>
>>  (@Ziyat T: als Watt-"Info" bekommt er dann vorläufig einfach
>>> den 10-fachen Messwert).
>>  das habe ich nicht verstanden?
> War mir nicht ganz sicher, welche Gründe es gab, unbedingt den MQTT-Teil
> abzuschalten und hatte dann vermutet, dass du darüber vielleicht die

du kannst mqtt laufen lassen, wenn ZEROEXP=0 ist, wird die topic 
"ImpExpW" nicht mehr abonniert, also keine limitierung über 
mqtt/gridmeter

[IsnoAhoy (Gast)]

Hallo Ziyat T. und Joerg R,
Ja es ist tatsächlich so dass da noch etwas auf Ahoy Seite passieren 
müsste um die ein/zwei/vier Commands für die MI-300/MI-600/MI-1200 
Wechselrichter abzufragen. Aktuell haben wir nur das Gen3 Protokoll mit 
Single und MultiFrame Antworten implementiert.
Die Gen2 Kommandos sind idR alles Single Frame Antworten und somit kann 
die CRC16 Prüfsumme über mehrere Pakete unterbleiben. Aber wir müssen 
immer je 1/2/4 Antworten die Pakete häppchenweise in den Strukturen 
ablegen, das ist etwas anders als bei HM-Wechselrichtern bei denen wir 
ja immer alle Werte aus der Gesamtpayload ablegen.
Wie man das am besten macht bin ich auch ein wenig überfragt, aber macht 
doch mal einen Anfang in Form einer miInverter.h und miSystem.h etc.
Wir müssen wie gesagt auch eine miRadio.h und/oder eine miApp.cpp 
anlegen da sich hier die Gen2 und Gen3 Protokolle ein wenig üebrlappen / 
beissen ??
@Lukas und @Andreas S. wir wollen doch auch den Ahoy Code refaktorieren 
damit er mit OpenDTU gemeinsam genutzt werden kann… wäre das nicht ein 
erster Schritt: die app.cpp aufräumen und alles was mit Kommunikation 
mit dem WR an Protokoll/Kommandos da aktuell drin ist wieder auslagern 
in eine hmGen3.cpp und dann eine miGen2.cpp die vielleicht beide ein 
ähnliches Interface haben ?

[Joachim (Gast)]

Ich würde mich über Hinweise freuen, was bei mir falsch laufen könnte. 
Habe den D1 mini laufen, inzwischen produziert der HM-600 auch Strom 
(blinkt im Sekundentakt grün). Abstand D1 zum WR etwa 5m, was ja 
eigentlich kein Problem sein dürfte. Im Setup sollte alles stimmen, die 
SN ist korrekt. Allerdings kann er sich immer noch nicht verbinden:
I: Requesting Inverter SN 114172015695
I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 
00 05 00 00 00 00 A3 5A AF
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 
00 05 00 00 00 00 A3 5A AF
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 
00 05 00 00 00 00 A3 5A AF
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 
00 05 00 00 00 00 A3 5A AF
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 
00 05 00 00 00 00 A3 5A AF
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 72 01 56 95 78 56 34 12 80 0B 00 62 F3 F2 16 00 00 
00 05 00 00 00 00 A3 5A AF
I: Inverter #0 I: no Payload received! (retransmits: 5)

Ich hatte vorher schon die länger gebaute Antenne dran, hab auch mal D3 
und D4 getauscht, alles ohne Erfolg. Hatte die gleiche Situation bereits 
auf sehr kurzer Distanz, allerdings hing der WR damals noch nicht am 
Hausnetz. Momentan ist die eher quadratisch gebaute Antenne dran. 
Danke!!

[Jörg R. (rejoe2)]

Wie man (wiederholt) sieht, ist Stefan an Bord *grins*:

Die Zuweisung zu einem bestimmten Unter-Typen erfolgt hier (?):
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmSystem.h#L50

Wenn ich es richtig interpretiere, sind die 3. Gen.-WR einfach als 
"Objekte" definiert, die dann auch - je nach Modell - intern einfach 
unterschiedliche Routinen verwenden, aber von außen einfach die "ihnen 
gehörenden Messages" erhalten (zur Auswertung) bzw. den passenden 
Sendecode für bestimmte Anweisungen "ausspucken". (Zumindest ist das 
ganze in diese Richtung angelegt?

Wobei auf die Schnelle die einzige Stelle, in der das bei den HM's eine 
Auswirkung hat die Funktion "getAssignment" zu sein scheint, dort z.B. 
die Unterscheidung in 
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmInverter.h#L203
Vermutlich schließt sich daran noch weiteres in der cpp-File an, aber 
wie gesagt: Orientieren im Code geht halbwegs, aber dann wird es schnell 
dünne...

Bedeutet, man würde praktisch erst mal so anfangen, dass man statt der 
hm.*.h's (bzw. cpp-Files) einfach Klone anlegt und die dann an den 
entsprechenden Stellen anpaßt...? Ufff...

Na ja, immerhin könnte man so ggf. dann wenigstens eine fertige firmware 
(MI-Version) mit "backen" lassen...

> du kannst mqtt laufen lassen, wenn ZEROEXP=0 ist, wird die topic
> "ImpExpW" nicht mehr abonniert, also keine limitierung über
> mqtt/gridmeter
ZEROEXP war die ganze Zeit auf 0, aber der ESP wollte den Wert trotzdem 
- was aber auch völlig egal ist, solange nicht weitere Tester hier an 
Bord sind. Ich weiß, wie mit dem Thema umzugehen ist, und habe 
zwischenzeitlich (neben dem "NOMQTT"-Schalter) auch noch eine weitere 
Code-Stelle ausgemacht, an der man die lästigen Connecting-to-Meldungen 
ausschalten kann.

MQTT könnte übrigens hilfreich sein, um einfach auf diesem Weg 
"unbekannte CMD"-Messages zu loggen. Z.B. einfach dieses Reading dann in 
FHEM loggen und gut ist - dann hat das ganze auch gleich einen 
Zeitstempel...

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Wie man (wiederholt) sieht, ist Stefan an Bord *grins*:
>
> Die Zuweisung zu einem bestimmten Unter-Typen erfolgt hier (?):
> https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmSystem.h#L50
>
> Wenn ich es richtig interpretiere, sind die 3. Gen.-WR einfach als
> "Objekte" definiert, die dann auch - je nach Modell - intern einfach
> unterschiedliche Routinen verwenden, aber von außen einfach die "ihnen
> gehörenden Messages" erhalten (zur Auswertung) bzw. den passenden
> Sendecode für bestimmte Anweisungen "ausspucken". (Zumindest ist das
> ganze in diese Richtung angelegt?

es geht in erster linie nicht um das definieren der 2.gen wr, sondern um 
den mechanismus der single frame 1/2/4 antworten und wie man die mit den 
3.gen wr antworten zusammen abarbeitet. gleiches gilt für die request 
meldungen. wie stefan auch geschrieben hat, da müssen sie zuerst mal 
"platz schaffen" und ein sw-interface für die 2.gen zur verfügung 
stellen.

>
> MQTT könnte übrigens hilfreich sein, um einfach auf diesem Weg
> "unbekannte CMD"-Messages zu loggen. Z.B. einfach dieses Reading dann in
> FHEM loggen und gut ist - dann hat das ganze auch gleich einen
> Zeitstempel...
ja sicher könnte man, i.d.regel wenns richtig laeuft sollten keine 
"unbekannte CMD" kommen

[Ziyat T. (toe_c)]

IsnoAhoy schrieb:
> Hallo Ziyat T. und Joerg R,
> Ja es ist tatsächlich so dass da noch etwas auf Ahoy Seite passieren
> müsste um die ein/zwei/vier Commands für die MI-300/MI-600/MI-1200
> Wechselrichter abzufragen. Aktuell haben wir nur das Gen3 Protokoll mit
> Single und MultiFrame Antworten implementiert.
> Die Gen2 Kommandos sind idR alles Single Frame Antworten und somit kann
> die CRC16 Prüfsumme über mehrere Pakete unterbleiben. Aber wir müssen
> immer je 1/2/4 Antworten die Pakete häppchenweise in den Strukturen
> ablegen, das ist etwas anders als bei HM-Wechselrichtern bei denen wir
> ja immer alle Werte aus der Gesamtpayload ablegen.
> Wie man das am besten macht bin ich auch ein wenig überfragt, aber macht
> doch mal einen Anfang in Form einer miInverter.h und miSystem.h etc.

man könnte sich zuerst ein high-level kommunikation interface überlegen, 
das alle wr-typen verstehen: z.B. get_data,set_data,get_status usw.

darunter quasi je einen spez. driver für jedes modell, 2.gen a b c, 
3.gen a b c etc.

[Frank L. (guilligan)]

Hi. Also die Limitierung mit 0.5.4 funktioniert gut. Hat jemand 
Erfahrung wie oft/schnell der hm mit Befehlen aus mqqt zu recht kommt 
und ob das Auswirkungen auf die Lebensdauer hat?
Ich meine kein Sekundengenaue Limitierung Aber so alle 15/30/45 
Sekunden.
Ja es dauert ein wenig bis er reagiert (1500 scheint schneller zu sein 
als der 600), aber verträgt der Inverter häufige Befehle zur Änderung?
Echt super Sache bis jetzt und wer nur mitliest sollte es endlich 
ausprobieren. Ich bereue bis jetzt noch nichts.
VG Frank

[Ziyat T. (toe_c)]

Frank L. schrieb:
> Hi. Also die Limitierung mit 0.5.4 funktioniert gut. Hat jemand
> Erfahrung wie oft/schnell der hm mit Befehlen aus mqqt zu recht kommt
> und ob das Auswirkungen auf die Lebensdauer hat?
> Ich meine kein Sekundengenaue Limitierung Aber so alle 15/30/45
> Sekunden.
> Ja es dauert ein wenig bis er reagiert (1500 scheint schneller zu sein
> als der 600), aber verträgt der Inverter häufige Befehle zur Änderung?
> Echt super Sache bis jetzt und wer nur mitliest sollte es endlich
> ausprobieren. Ich bereue bis jetzt noch nichts.
> VG Frank

- eine zeroexport funktion macht das ja immer
- der wr , zumindest die 2.gen wr, reagiert sofort, wenn der wr den mmpt 
suchen muss dann natürlich es dauert bisschen laenger

[Stefan T. (isnoahoy)]

Hallo Joachim,
Du kannst gerne mal D1/D2 ausprobieren, es gab Hinweise dass es damit 
klappt. Wenn Du die Pins tauschst dann auch das Setup anpassen.
Vielleicht auch zwischenrein mal MQTT abschalten, da es Vermutungen gibt 
dass PubSubClient uns immer noch in die Suppe spuckt.
Optional kann man auch das nRF24L01+ Modul mit einem 10/100uF Elko 
zwischen VCC & GND Pins des Moduls, ein bißchen besser für die 
notwendige Sendeleistung des kleinen Funkzwerges kompensieren.

[Stefan T. (isnoahoy)]

Hallo Jörg & Ziyat T.,

>> Die Zuweisung zu einem bestimmten Unter-Typen erfolgt hier (?):
>> https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmSystem.h#L50
>>
>> Wenn ich es richtig interpretiere, sind die 3. Gen.-WR einfach als
>> "Objekte" definiert, die dann auch - je nach Modell - intern einfach
>> unterschiedliche Routinen verwenden, aber von außen einfach die "ihnen
>> gehörenden Messages" erhalten (zur Auswertung) bzw. den passenden
>> Sendecode für bestimmte Anweisungen "ausspucken". (Zumindest ist das
>> ganze in diese Richtung angelegt?

> es geht in erster linie nicht um das definieren der 2.gen wr, sondern um
> den mechanismus der single frame 1/2/4 antworten und wie man die mit den
> 3.gen wr antworten zusammen abarbeitet. gleiches gilt für die request
> meldungen. wie stefan auch geschrieben hat, da müssen sie zuerst mal
> "platz schaffen" und ein sw-interface für die 2.gen zur verfügung
> stellen.

Ja, das habt ihr beide richtig verstanden!
Die Implementierung einfach mal in miDefines.h, miInverter.h und 
miSystem.h vornehmen.
Dann für die Anpassungen am Protokoll miRadio.h anpassen. Hierzu müssen 
m.E. viele Code Teile die aktuell in app.cpp sind (warum eigentlich ?) 
und für die Abhandlung der einzelnen Kommandos bzw. Erstellung und 
Parsen der Pakete/Frames notwendig sind hierhin bzw. in hmRadio.h oder 
eine neue hmProtokoll.h und für Euch in eine miProtokoll.h ausgelagert 
werden.

Ich weiß nicht ob sich Lukas oder Andreas sich hieran beteiligen, den 
bestehenden Code mal aufzuräumen, aber wenn ihr schon mal die ersten 
drei miDefines/Inverter/System erstellen könntet, dann geht das andere 
bestimmt auch noch irgendwann.

[Rene M. (Firma: Bitte wählen) (renmo)]

Frank L. schrieb:

> Ja es dauert ein wenig bis er reagiert (1500 scheint schneller zu sein
> als der 600), aber verträgt der Inverter häufige Befehle zur Änderung?


Bei mir dauert es schon eine Zeitlang bis der HM1500 reagiert. Ist aber 
auch schwer nachzuvollziehen, da Ahoy so selten die Werte ausliest und 
MQTT noch seltener.

Machst du die quasi Nulleinspeisung mit einem Blockly auf iobroker?

[Friedhelm E. (fritsche)]

Hallo,
@Hubi(Gast)
Habe die neue Version mit den entsprechenden Daten eingegeben und 
festgestellt das nur der WR1 dargestellt wird. Erst mit Änderung der 
define Anzahl WR = 2
hat er beide Tabellen ausgegeben.
Danke fürs Bearbeiten.
Ist schon etwas über eine Leistungsbegrenzung angedacht?
Hintergrund: Der 2te.WR soll auf dem 2ten. Eingang eine Akkueinspeisung 
bekommen, der entweder mit einer Leistungeinstellung im WR oder extern 
funktioniert. Die externe Strom-/Spannungsbegrenzung funktioniert 
bereits mit einem E-Bike Akku (36V). Eine WR interne Begrenzung wäre mir 
lieber.

wünsche einen guten Tag
fritsche

[Ziyat T. (toe_c)]

Stefan T. schrieb:
> Hallo Jörg & Ziyat T.,
>

hast du irgend ein klassen-diagram oder ablauf-diagram von ahoy-esp? 
oder verwendest du irgendein UML-tool?
dann könnte ich mal das ganze anschauen..

[Volker.B. (Gast)]

Hallo.

Was sagt eigentlich der Wert "ALARM_MES_ID" in der Ahoy Version 0.5.5 
aus?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> auf .....send res 0 ist kein verlass
Hmm, irgendwie läßt mich das nicht so ganz los....

Hatte jetzt testweise den Standort etwas verlagert, und ja, die Daten 
waren etwas besser, aber im Prinzip immer noch grottig. Anscheinend sind 
die ersten paar Bytes oft noch ok, aber je weiter nach hinten man kommt, 
desto zufälliger scheint das zu werden.
Da es "irgendwie" manchmal klappt, dürfte das ganze kein reines 
Hardware-Problem sein, sondern irgendwas anderes.

Hier mal die Schnippsel, die bei mir in meinem Laien-Verständnis vom 
Ganzen hängen geblieben sind:
- Manche haben in den frühen Sketchen gar kein Channel-Hopping 
vorgesehen, aber trotzdem Daten bekommen. Am "zufriedensten" scheinen 
die zu sein, die ein "poor man's channel hopping" machen (hab's nicht 
nachgeschlagen, was das konkret bedeutet);
- die auf den WR vercodeten Channels liegen in dem Bereich, in dem auch 
2.4GHz-WLAN rumfunkt (ab 86? wäre in der EU nicht mehr zulässig);
- eng nebeneinanderliegende Channels bedeuten Interferenzen;

Was wir mit dem MI-Sketch aktuell machen, ist "Dauer-Channel-hopping", 
"res = 1" kommt keinerlei Bedeutung zu. Das ist m.E. Teil des Problems, 
jedenfalls, wenn meine graue laienhafte Theoriewelt nicht komplett 
danebenliegt:
- Ein Hardware-ACK (das verbirgt sich hinter der "1") bedeutet doch, 
dass wir ein starkes Indiz dafür haben, genau den Channel erwischt zu 
haben, auf dem der WR grade lauscht?
- Wenn das so ist, sollten wir erst mal auf diesem Channel bleiben, 
sowohl, was das Senden wie auch das Empfangen angeht. Das würde die 
Chance erhöhen, dass der WR mit seinen Infos "durch den Nebel" kommt. 
Erst, wenn länger nichts sinnvolles kommt, fangen wir an, wieder einen 
passenden Kanal zu suchen. (Für das ganze Netz, wohlgemerkt, s.U.).

Die sehr kurze Gesamtdurchlaufdauer des Ganzen bis zum nächsten 
Gesamtdurchlauf scheint mir für den 4-Kanaligen ok zu sein, aber 
eigentlich läge mir eine Logik ala "jeden WR nur alle 5 Sekunden 
abfragen" näher. Würde bedeuten, dass man den "tickMillis" weniger 
statisch handhaben sollte: Wenn der WR "durch" ist, könnten es 5 
Sekunden sein, wenn der nächste Kanal abzufragen ist, kann man das m.E. 
eigentlich direkt (im Auswertungscode für die Antwort-Messages?) auf "0" 
setzen, oder?

Werde mal versuchen, den Sketch entsprechend anzupassen, das sollte noch 
im Bereich meiner Skills liegen.

Ach so, vielleicht noch zum gedanklichen Hintergrund des ganzen: An sich 
sieht ein MI/HM-"Netzwerk" nicht anders aus als das, was man unter 
https://www.mysensors.org/about/network findet. Sowas funktioniert 
erwiesenermaßen ganz ordentlich - (@MySensors-nRF) vorausgesetzt, man 
kann einen statischen Kanal festlegen, auf dem nichts anderes heftig 
rumfunkt. Nach meinem Verständnis dienen die mehreren festen Kanäle nur 
dazu, Ausweichmöglichkeiten zu haben, aber das eigentliche "Ziel" des 
Codes müßte eigentlich sein, sich für alle WR in diesem Netz auf einen 
Kanal zu einigen (ähnlich zu dem, was für WLAN gilt, nur dass da eben 
(prinzipiell) mehr Kanäle wählbar sind). Auf diesem teilt dann die DTU 
die "Sendezeiten" zu, was uU. auch mal bedeuten kann, etwas geduldiger 
zu warten, bis Nachrichten "aus dem letzten Eck" ihr Ziel erreicht 
haben.
Das findet sich aber m.E. in der MI-Fassung derzeit nicht so recht 
wieder, das ist mehr auf eine 1:1-Kommunikation angelegt, deren Gelingen 
wohl auch  davon abhängt, dass die äußeren Rahmenbedingungen in etwa 
gleich sind.

Kann aber natürlich sein, dass ich einmal mehr sehr auf dem Holzweg 
bin...

[Frank L. (guilligan)]

Rene M. schrieb:
> Frank L. schrieb:
>
>> Ja es dauert ein wenig bis er reagiert (1500 scheint schneller zu sein
>> als der 600), aber verträgt der Inverter häufige Befehle zur Änderung?
>
> Bei mir dauert es schon eine Zeitlang bis der HM1500 reagiert. Ist aber
> auch schwer nachzuvollziehen, da Ahoy so selten die Werte ausliest und
> MQTT noch seltener.
>
> Machst du die quasi Nulleinspeisung mit einem Blockly auf iobroker?

nein über node red auf raspi. Quasi den Zähler im Schrank auslesen mit 
ir-lesekopf und dann verrechnen und über mqtt und wemos+nrf an die 
wechselrichter. iobroker hab ich nicht in Gebrauch.

[Günter H. (gnter_h534)]

Volker.B. schrieb:
> Was sagt eigentlich der Wert "ALARM_MES_ID" in der Ahoy Version 0.5.5
> aus?

Diese Frage hatte ich mir auch gestellt - auf Discord 
(https://discord.com/channels/984173303147155506/992031772328075375/1006955462580781217)

bekam ich diese Antwort:

drschiffler — gestern um 18:01 Uhr
Diese Zahl erhöht sich um 1 wenn eine neue Warnung bzw ein neuer Alarm 
hinzukommt. Welcher Alarm oder welche Warnung kann man noch nicht sehen

[Friedhelm E. (fritsche)]

Hallo,
@Hubi(Gast)
Habe einen eigenartigen Effekt festgestellt. Die Original SNr. werden 
abwechselnd mit der 1141 72600000 bei der Ausgabe auf dem Handy 
angezeigt,
sowohl bei WR1 als auch WR2. Die Daten im Ausgabefeld veändern sich 
nicht.
Soweit mein Testlauf.
einen guten Tag,
fritsche

[Joachim (Gast)]

Stefan T. schrieb:
> Stefan

Hallo Stefan, einen ganz großen Dank für Deinen Tipp, der war mir 
irgendwo auf den letzten Seiten wohl entgangen. Kurz: mit meinem D1 mini 
pro funktioniert die Antenne nur mit D1/D2 (CE/IRQ), nicht aber mit 
D3/D4. Muss ich weiter nicht verstehen, aber ich freue mich sehr, dass 
es endlich klappt! Großes Lob an alle (Mit-)Entwickler, ein klasse 
Projekt!

[Freddy (Gast)]

Hallo , erstmal vielen Dank das ihr eine so tolle Arbeit kostenlos zur 
Verfügung stellt . Ich bin begeistert .
Ich hoffe meine Fragen passen hier rein .
Ich habe einen HM 1200 auf 600w über das setup limitiert . Meine Frage 
ist , wie oft aktualisiert ahoy diesen Wert und überschreibt diesen im 
wr ?
Gibt es einen Wert mit dem man den wr wieder auf max limitieren kann ? 
Also wie auf Werkseinstellung.
Ihr seid da so hinterher mit den Verbesserungen und bug fix dass kaum 
nach kommt .
Danke

[Jörg R. (rejoe2)]

@MI-Mitleser:
Das mit dem "Beharren" auf einem Channel scheint jedenfalls besser zu 
funktionieren, bin ganz begeistert. Sogar mit dem "kleinen" nRF klappt 
es, die Daten zu empfangen, in minicom ist das Verhältnis Sende- zu 
Emfangszeilen sogar mit diesem Modul (HIGH-Sendelevel, CRC an (!)) 
gefühlt bei 4:1, mit dem geshieldeten (LOW) sogar 1:1 - und das am 
vermeintlich funktechnisch schlechtesten Ort...

Aus irgendeinem Grund hopt das Ding immer noch sendseitig (kommt das aus 
der hm-lib?) und den Status sieht man auch nicht (die "3"), vermutlich 
habe ich versehentlich was abgeschaltet, das das anfragt?

Aber als Zwischenergebnis dürfte es trotzdem interessant sein grins.

Hier noch ein paar Zeilen aus minicom (mit dem "kleinen"):

Send... CH61 0960100013785634120062.....send res 0
Send... CH75 116010001378563412007A.....send res 0
Send... CH03 0960100013785634120062.....send res 0
Send... CH23 116010001378563412007A.....send res 0
Send... CH40 0960100013785634120062.....send res 0
CH3 00 1234567801 00C2 18 1  89 60100013 60100013 013200180936138503170891017FF88FCA 1
CH: 3 PV0 MI: 157W Grd:1480W Lm:   0W 79.1W 30.6V 2.4A 2193Wh 235.8ACV 50.0Hz 38.3C S:0 
Send... CH61 116010001378563412007A.....send res 0
Send... CH75 0960100013785634120062.....send res 0
Send... CH03 116010001378563412007A.....send res 0
Send... CH23 0960100013785634120062.....send res 0
Send... CH40 116010001378563412007A.....send res 0
CH3 00 1234567801 00C2 18 1  91 60100013 60100013 013200180938138502DE08B6017D034E92 1
CH: 3 PV1 MI: 152W Grd:1480W Lm:   0W 73.4W 30.6V 2.4A 2230Wh 236.0ACV 50.0Hz 38.1C S:0 
Send... CH61 0960100013785634120062.....send res 0
Send... CH75 116010001378563412007A.....send res 0
Send... CH03 0960100013785634120062.....send res 0
Send... CH23 116010001378563412007A.....send res 0
Send... CH40 0960100013785634120062.....send res 0
CH3 00 1234567801 00C2 18 1  89 60100013 60100013 013200170938138502E30891017E0D062A 1
CH: 3 PV0 MI: 147W Grd:1480W Lm:   0W 73.9W 30.6V 2.3A 2193Wh 236.0ACV 50.0Hz 38.2C S:0 
Send... CH61 116010001378563412007A.....send res 0
Send... CH75 0960100013785634120062.....send res 0
Send... CH03 116010001378563412007A.....send res 0
Send... CH23 0960100013785634120062.....send res 0
Send... CH40 116010001378563412007A.....send res 0
CH3 00 1234567801 00C2 18 1  91 60100013 60100013 013100170938138502BB08B6017D6A3144 1
CH: 3 PV1 MI: 143W Grd:1480W Lm:   0W 69.9W 30.5V 2.3A 2230Wh 236.0ACV 50.0Hz 38.1C S:0 
Send... CH61 0960100013785634120062.....send res 0
Send... CH75 116010001378563412007A.....send res 0
Send... CH03 0960100013785634120062.....send res 0
Send... CH23 116010001378563412007A.....send res 0
Send... CH40 0960100013785634120062.....send res 0
CH3 00 1234567801 00C2 18 1  89 60100013 60100013 013200170936138402C00892017E22CDB4 1
CH: 3 PV0 MI: 140W Grd:1480W Lm:   0W 70.4W 30.6V 2.3A 2194Wh 235.8ACV 50.0Hz 38.2C S:0 
Send... CH61 116010001378563412007A.....send res 0
Send... CH75 0960100013785634120062.....send res 0
Send... CH03 116010001378563412007A.....send res 0
Send... CH23 0960100013785634120062.....send res 0
Send... CH40 116010001378563412007A.....send res 0
CH3 00 1234567801 00C2 18 1  91 60100013 60100013 013200170936138302B908B6017E607A81 1
CH: 3 PV1 MI: 140W Grd:1480W Lm:   0W 69.7W 30.6V 2.3A 2230Wh 235.8ACV 50.0Hz 38.2C S:0 
Send... CH61 0960100013785634120062.....send res 0
Send... CH75 116010001378563412007A.....send res 0
Send... CH03 0960100013785634120062.....send res 0
Send... CH23 116010001378563412007A.....send res 0
Send... CH40 0960100013785634120062.....send res 0
CH3 00 1234567801 00C4 18 2  89 60100013 60100013 013200180935138302BF0892017E569B95 1
CH: 3 PV0 MI: 140W Grd:1480W Lm:   0W 70.3W 30.6V 2.4A 2194Wh 235.7ACV 50.0Hz 38.2C S:0 
Send... CH61 116010001378563412007A.....send res 0
Send... CH75 0960100013785634120062.....send res 0
Send... CH03 116010001378563412007A.....send res 0
Send... CH23 0960100013785634120062.....send res 0
Send... CH40 116010001378563412007A.....send res 0
Send... CH61 0960100013785634120062.....send res 0
Send... CH75 116010001378563412007A.....send res 0
Send... CH03 0960100013785634120062.....send res 0
Send... CH23 116010001378563412007A.....send res 0
Send... CH40 0960100013785634120062.....send res 0
CH3 00 1234567801 00C2 18 1  89 60100013 60100013 0133001A0935138502DE0892017E32DDD6 1
CH: 3 PV0 MI: 143W Grd:1480W Lm:   0W 73.4W 30.7V 2.6A 2194Wh 235.7ACV 50.0Hz 38.2C S:0 
Send... CH61 116010001378563412007A.....send res 0
Send... CH75 0960100013785634120062.....send res 0
Send... CH03 116010001378563412007A.....send res 0
Send... CH23 0960100013785634120062.....send res 0
Send... CH40 116010001378563412007A.....send res 0
CH3 00 1234567801 00C2 18 1  91 60100013 60100013 013300190936138502F908B7017C2A02F5 1
CH: 3 PV1 MI: 149W Grd:1480W Lm:   0W 76.1W 30.7V 2.5A 2231Wh 235.8ACV 50.0Hz 38.0C S:0 
Send... CH61 0960100013785634120062.....send res 0

[Frank L. (guilligan)]

Limitierung über mqtt
Ich habe heute noch ein wenig rum probiert wie eine "Nulleinspeisung" 
über mqtt funktionieren könnte.
Ergebnis: scheint zu viel traffic zu sein. Meine 2 WR (600 und 1500) 
reagieren nur sporadisch. Das "kleben" des Limits (Limit 6000W statt 
600) ist immer noch drin bei v0.5.6.
Manuelles setzen über mqtt geht gut (mit warten von ca. 1 min). Nachdem 
jedoch die automatische Datenflut über mqtt erfolgt ist, hilft meist nur 
ein reboot über ahoy.
Mal schauen wie es weiter geht... heute wird es erst mal "dunkel" bei 
mir.

[Jörg R. (rejoe2)]

Boah, jetzt scheinen die sich auf Kanal 61 geeinigt zu haben, und da 
geht es nur noch so ab in der Kommunikation zu dem MI...

Aber nur noch 89/91-Messages. Kann es sein, dass man die 88/92 extra 
bestellen muss? (An einen anderen Channel dafür mag ich nicht so recht 
glauben, oder braucht man den doch?).

Update der ino anbei. (EDIT *2)

Mit etwas millis() in der Debug-Ausgabe (CRC-Check ausgeschaltet)...

360453 Send... CH61 360454116010001378563412007A.....send res 0
CH61 00 1234567801 00C2 18 1  89 60100013 60100013 012600070930138700D508D801595915A0 1
360490 CH:61 PV0 MI:  42W Grd: 300W Lm:   0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 
CH:61 PV0 MI:  42W Grd: 300W Lm:   0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 
CH61 00 1234567801 00C2 18 1  89 60100013 60100013 012600070930138700D508D801595915A0 1
360510 CH:61 PV0 MI:  42W Grd: 300W Lm:   0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 
CH:61 PV0 MI:  42W Grd: 300W Lm:   0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 
CH61 00 1234567801 00C2 18 1  89 60100013 60100013 012600070930138700D508D801595915A0 1
360534 CH:61 PV0 MI:  42W Grd: 300W Lm:   0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 
CH:61 PV0 MI:  42W Grd: 300W Lm:   0W 21.3W 29.4V 0.7A 2264Wh 235.2ACV 50.0Hz 34.5C S:0 
360549 Send... CH61 3605510960100013785634120062.....send res 0
365549 Send... CH61 365549116010001378563412007A.....send res 0
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 01240007092F138700DA08FC015876172F 1
365631 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 01240007092F138700DA08FC015876172F 1
365651 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH61 00 1234567801 00C2 18 1  91 60105557 6AB48057 036C400F1B6F378F00DA8AFD0B5AF6376F 0
365675 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 87.6V 1639.9A 35581Wh 702.3ACV 142.2Hz 290.6C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 87.6V 1639.9A 35581Wh 702.3ACV 142.2Hz 290.6C S:0 
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 01240007092F138700DA08FC015876172F 1
365699 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 01240007092F138700DA08FC015876172F 1
365723 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 01240007092F138700DA08FC015876172F 1
365747 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 01240007092F138700DA08FC015876172F 1
365771 CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0 
CH:61 PV1 MI:  43W Grd: 300W Lm:   0W 21.8W 29.2V 0.7A 2300Wh 235.1ACV 50.0Hz 34.4C S:0

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Boah, jetzt scheinen die sich auf Kanal 61 geeinigt zu haben, und da
> geht es nur noch so ab in der Kommunikation zu dem MI...
>
> Aber nur noch 89/91-Messages. Kann es sein, dass man die 88/92 extra
> bestellen muss? (An einen anderen Channel dafür mag ich nicht so recht
> glauben, oder braucht man den doch?).
>
moment mal wieso sehe ich das?
360549 Send... CH61 3605510960100013785634120062.....send res 0
das ist die abfrage "cmd36" für MI1500!! das sollete beim MI600 nicht 
sein! irgendwas stimmt nicht da.


also die einigen sich überhaupt nicht für einen kanal, wir senden  und 
empfangen (channel hopping) auf ch {3,23, 40, 61, 75}, wenn der wr z.b. 
auf 11 beantwortet werden wir nicht erfahren. ich beheaupte schon lange, 
dass die wr's mit der zeit auf andere kanaele wechseln. ich bin mir 
nicht sicher, z.b. bei ahoy-esp wird nur auf ch3 empfangen, dann kann es 
natürlich lange dauern bis etwas kommt.
ich denke die 88/92 antworten sind ev. auf einem anderen kanal.

[Jörg R. (rejoe2)]

Es ist definitiv nicht auszuschließen, dass ich irgendwas grundlegend 
verbogen habe.
ABER: Ziel der Änderungen in dem Code war es, das channel-Gehopse für 
die Fälle auszuschalten, in denen was als Antwort zurückkommt. 
rx-Channel und tx-Channel sollten dabei immer gleich sein. Gesendet wird 
dabei (in Summe) sehr viel langsamer!
Kann man an den millis()-Ausgaben vor den debug-Meldungen ablesen, 
besser sogar noch, wenn CRC eingeschaltet ist.

Was ich sehen kann, ist dass der MI seit ungefähr 2 h immer auf die 
898/91-Anfragen unter Kanal 61 antwortet, und das relativ zuverlässig, 
einzelne Anfragen gehen verloren.

Ergo kann es schon sein, dass die anderen Infos unter einem anderen 
Kanal verfügbar wären, eher glaube ich daran, dass das einfach 
"Zufallstreffer" auf "unser Gerausche" waren (Fehlinterpretationen der 
Anfrage-Ziffer, sowas habe ich hier "rückwarts" teilweise auch 
gesehen...).

Die Änderungen im Code sind übrigens überschaubar - ein diff oder der 
Vergleich in notepad++ würde ggf. helfen zu verstehen, wie meine "Denke" 
dazu ist. Und bitte immer das Bildchen von MySensors gedanklich mit 
diesen Modifikationen vergleichen.
Ich behaupte, das Gehopse der MI selbst dient wirklich nur dazu, sich 
auf einen Kanal zu verständigen, und zwar "einen für alle" (!). Wenn HM 
das mit 03 hinbekommt, ohne dass sich jemand beklagt, gilt dies m.E. 
umso mehr.

Dass man damit eigentlich die ganze Abfragelogik umstellen müßte, ist 
ein anderes Thema (also irgendwie verwalten, zu was man schon eine Info 
hat und wo man ggf. nochmal nachhaken müßte etc.).

EDIT:
Das "es kommt nichts mehr, also wird gehoppt" funktioniert übrigens - es 
ist Nacht:

2901299 Send... CH61 29012990960100013785634120062.....send res 0
2906299 Send... CH75 2906299116010001378563412007A.....send res 0
2911299 Send... CH03 29112990960100013785634120062.....send res 0
2916299 Send... CH23 2916299116010001378563412007A.....send res 0
2921299 Send... CH40 29212990960100013785634120062.....send res 0
2926299 Send... CH61 2926299116010001378563412007A.....send res 0
2931299 Send... CH75 29312990960100013785634120062.....send res 0
2936299 Send... CH03 2936299116010001378563412007A.....send res 0

Bin mal gespannt, ob und wo die sich morgen finden.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> ABER: Ziel der Änderungen in dem Code war es, das channel-Gehopse für
> die Fälle auszuschalten, in denen was als Antwort zurückkommt.
> rx-Channel und tx-Channel sollten dabei immer gleich sein. Gesendet wird
> dabei (in Summe) sehr viel langsamer!
> Kann man an den millis()-Ausgaben vor den debug-Meldungen ablesen,
> besser sogar noch, wenn CRC eingeschaltet ist.

ok, ich kann deine gedanken folgen. aber wie am anfang dieses projektes 
"bewiesen" wurde, dass der dtu statistisch meistens auf kanaelen {3,23, 
40, 61, 75} sendet, darum haben wir es so gemacht.
ich habe für mich durchs sniffen heraus gefunden, dass z.B. mein MI1500 
manchmal den ganzen tag nicht auf CH3 antwortet, darum hab ich hopping 
auch beim rx eingeführt.
ich bin mir nicht sicher, ob ein ack  immer auf dem gleichen kanal kommt 
oder kommen muss.

aber wieso sendest du den timer mit?? das verstehe ich nicht, so 
bekommst du doch keine antworten, oder?
2936299 Send... CH03 [2936299]116010001378563412007A
2931299 Send... CH75 [2931299]0960100013785634120062

[Sebastian (Gast)]

Hallo,

Ich hab seit einer Woche ein Hoymiles HM-1500 Inverter, den ich gerne 
auslesen möchte per Ahoy DTU.

Heute kamen  alle Teile an, der  Az Esp8266
und das Az Antennenmodul.

Ich hab erstmal ein Prototyp gebaut um das ganze zu testen, aber ich 
bekomme einfach keine Verbindung zum Wechselrichter?

Die Seriennummer geht los mit 1161xxxxx

Das Pinout hatte ich mehrfach kontrolliert.

[Steffen D. (steffen_d)]

Sebastian schrieb:
> Hallo,
>
> Ich hab seit einer Woche ein Hoymiles HM-1500 Inverter, den ich gerne
> auslesen möchte per Ahoy DTU.
>
> Heute kamen  alle Teile an, der  Az Esp8266
> und das Az Antennenmodul.
>
> Ich hab erstmal ein Prototyp gebaut um das ganze zu testen, aber ich
> bekomme einfach keine Verbindung zum Wechselrichter?
>
> Die Seriennummer geht los mit 1161xxxxx
>
> Das Pinout hatte ich mehrfach kontrolliert.

Wie weit ist Ahoy vom WR entfernt?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> 2936299

Ziyat T. schrieb:
> ok, ich kann deine gedanken folgen. aber wie am anfang dieses projektes
> "bewiesen" wurde, dass der dtu statistisch meistens auf kanaelen {3,23,
> 40, 61, 75} sendet, darum haben wir es so gemacht.
Das ist ja vermutlich auch nicht kompletter Unsinn. Solange keine 
Antwort zurückkommt, oder wenn da Teilnehmer sind, die bestimmte 
Frequenzen nicht können, wäre das eine Option. Irgendwo meine ich 
gelesen zu haben, dass die originale DTU ein paar Bugs hat, und als 
solchen würde ich es bezeichnen, wenn die das grundlos macht. Bis 
jedenfalls dato habe ich noch keinen triftigen Grund gefunden für's 
hoppen, es sei denn, jeder WR hätte "seine" Frequenz...
Aber dann müßte es gewisse Zeitbudgets geben, und die Reichweite wäre 
sehr viel begrenzter wie mit der Mesh-Option, die afaik nur 
funktioniert, wenn alle beteiligten nRF auf derselben Frequenz funken.

> ich habe für mich durchs sniffen heraus gefunden, dass z.B. mein MI1500
> manchmal den ganzen tag nicht auf CH3 antwortet, darum hab ich hopping
> auch beim rx eingeführt.
> ich bin mir nicht sicher, ob ein ack  immer auf dem gleichen kanal kommt
> oder kommen muss.
Das Hardware-Ack (ganz am Anfang der loop) "kann" gar nicht anders, "des 
khert so!". Und Es macht m.E. auch keinen Sinn, die Antwort auf eine 
Anfrage auf einem anderen Kanal zu machen (es sei denn, es gäbe eine 
explizite Verabredung über Frequenz und timing (!). MAn. viel zu 
kompliziert...)
Bei meinem "guten" nRF hatte ich einige HW-Acks gesehen, beim "kleinen" 
nicht und auch nicht mehr beim ungeshieldeten. Aber wenn er da ist, ist 
es m.E. der "Jackpot" - eindeutiger geht es nicht...

> aber wieso sendest du den timer mit?? das verstehe ich nicht, so
> bekommst du doch keine antworten, oder?
> 2936299 Send... CH03 [2936299]116010001378563412007A
> 2931299 Send... CH75 [2931299]0960100013785634120062
Falsche (doppelte) Stelle für die Info erwischt, hinter if 
(DEBUG_TX_DATA){  muss man die eine Zeile auskommentieren, sorry; 
gesendet wird das nicht.

Wenn es gut gemacht ist, müßte es auch einen Code geben, mit der die DTU 
den WR (allen "zuhörenden" per broadcast?) mitteilt, dass ab demnächst 
ein anderer Kanal zu verwenden ist, wobei ich bei 5en dann eher immer 
einen überspringen würde (also Start=23, dann 61, 3, 40, 75, 23). So 
könnte man auch einen schnellen stabilen nächsten Gesamtzustand 
erhalten. (Denkt sich jedenfalls der Laie).

Bin mal gespannt auf morgen...

[Sebastian (Gast)]

Steffen D. schrieb:
> Sebastian schrieb:
>
>> Hallo,
>> Ich hab seit einer Woche ein Hoymiles HM-1500 Inverter, den ich gerne
>> auslesen möchte per Ahoy DTU.
>> Heute kamen  alle Teile an, der  Az Esp8266
>> und das Az Antennenmodul.
>> Ich hab erstmal ein Prototyp gebaut um das ganze zu testen, aber ich
>> bekomme einfach keine Verbindung zum Wechselrichter?
>> Die Seriennummer geht los mit 1161xxxxx
>> Das Pinout hatte ich mehrfach kontrolliert.
>
> Wie weit ist Ahoy vom WR entfernt?

Zum testen war ich ganz nahe am Wechselrichter ca 3m entfernt.

Die Sonne war schon  weg, es lagen vielleicht noch 26 Watt an, damit 
müsste das Funkmodul doch noch arbeiten im Wechselrichter.

[Jörg R. (rejoe2)]

Nachtrag noch: Wie sähe denn die Anfrage nach den Werten aus 88/92 aus? 
Und in welchem Intervall würde man solche Infos erfragen wollen?

Sebastian schrieb:
> Die Sonne war schon  weg, es lagen vielleicht noch 26 Watt an, damit
> müsste das Funkmodul doch noch arbeiten im Wechselrichter.
Habe vorhin bei dem MI noch Nachrichten empfangen bei nahe 0 W....

[Sebastian (Gast)]

Jörg R. schrieb:
> Nachtrag noch: Wie sähe denn die Anfrage nach den Werten aus 88/92
> aus? Und in welchem Intervall würde man solche Infos erfragen wollen?
> Sebastian schrieb:
>
>> Die Sonne war schon  weg, es lagen vielleicht noch 26 Watt an, damit
>> müsste das Funkmodul doch noch arbeiten im Wechselrichter.
>
> Habe vorhin bei dem MI noch Nachrichten empfangen bei nahe 0 W....

Sehr komisch, den ESP hatte ich bestellt
https://www.amazon.de/gp/aw/d/B074Q2WM1Y?psc=1&ref=ppx_pop_mob_b_asin_title

Das Funkmodul dazu
https://www.amazon.de/gp/aw/d/B075DBDS3J?psc=1&ref=ppx_pop_mob_b_asin_title

[Jörg R. (rejoe2)]

Sebastian schrieb:
> Das Funkmodul dazu
> https://www.amazon.de/gp/aw/d/B075DBDS3J?psc=1&ref=ppx_pop_mob_b_asin_title

Wenn du wirklich DIESE Funkmodule bestellt, hast, ist das möglicherweise 
die falsche Ausführung, das muss eines mit "+" sein, also nicht 
"NRF24L01", sondern "NRF24L01+"! Auf dem Aufdruck auf dem Chip sollte es 
zu erkennen sein. Da muss ein + mit draufstehen, und optimalerweise 
sollte die ganze Schrift klar sein (=früher war "verwaschen" ein 
Anzeichen für fake chips").

Wie gesagt: Es ist möglicherweise "overdone", aber ich würde immer für 
"richtige Projekte" (aus vielerlei Gründen) sicherheitshalber zu den 
"großen geshieldeten Modulen" raten (und ausreichend Power uVa. 
Kondensator-Kapazität vorschalten!). (Willkürlich gegriffen!) sehen die 
Dinger so aus: https://www.ebay.de/itm/162822272150.

Hat sich auch jetzt wieder gezeigt: So ein Teil + diese hier teilweise 
abgewerteten Adapterplatinen (ebenfalls willkürlich: 
https://www.ebay.de/itm/144491901516) haben sich als einigermaßen robust 
erwiesen, das ist die Kombi (optisch), die Hardware-ACKS ausspuckt...

[Jörg R. (rejoe2)]

...ohne weitere Worte - das log von heute morgen...

[Steffen D. (steffen_d)]

Jörg R. schrieb:
> Sebastian schrieb:
>> Das Funkmodul dazu
>> https://www.amazon.de/gp/aw/d/B075DBDS3J?psc=1&ref=ppx_pop_mob_b_asin_title
>
> Wenn du wirklich DIESE Funkmodule bestellt, hast, ist das möglicherweise
> die falsche Ausführung, das muss eines mit "+" sein, also nicht
> "NRF24L01", sondern "NRF24L01+"! Auf dem Aufdruck auf dem Chip sollte es
> zu erkennen sein. Da muss ein + mit draufstehen, und optimalerweise
> sollte die ganze Schrift klar sein (=früher war "verwaschen" ein
> Anzeichen für fake chips").

Die Funkmodule sind in Ordnung. Ich verwende sie auch. In der 
Beschreibung steht folgendes " Set bestehend aus 3 x NRF24L01+! ".

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> ...ohne weitere Worte - das log von heute morgen...

das sieht ja recht ordentlich aus:-)

> Falsche (doppelte) Stelle für die Info erwischt, hinter if
> (DEBUG_TX_DATA){  muss man die eine Zeile auskommentieren, sorry;

ja, habe auch schon gefunden

also, deine überlegungen müsste man schon verfolgen, es sieht ja so aus, 
wenn sich die beiden auf einen kanal "einigen" laeuft es schon besser.

edit:ich schaue mal nach, warum bei dir die status meldungen nicht gehen

[Ziyat T. (toe_c)]

@Jörg R.

also wir schicken 0x09/0x11, erwarten 0x91/0x89(data) UND 
0x92/0x88(status), es gibt keine sep. status abfrage

du hattest ja am anfang diese auch mal gesehen
CH3 00 1234567801 0082 10 1  92 60100013 60100013 00[03]00000000913454 1
diese [03] ist status = producing

villeicht sind die 0x92/0x88 auf anderem kanal?

[Jörg R. (rejoe2)]

Steffen D. schrieb:
> Die Funkmodule sind in Ordnung. Ich verwende sie auch. In der
> Beschreibung steht folgendes " Set bestehend aus 3 x NRF24L01+! ".
Komisch, dass ein eher größerer Importeur wie AZDelivery bei der 
Beschreibung leicht schlampig vorgegangen ist, aber auch die Bilder sind 
teilweise eindeutig "mit +".

Wenn es nicht klappt, ggf. mal den Ping-Pong-Sketch aus der RF24-lib 
suchen (oder war der von MySensors?). Damit sollte sich feststellen 
lassen, ob die HW an sich ok ist.

Ziyat T. schrieb:
> Jörg R. schrieb:
>> ...ohne weitere Worte - das log von heute morgen...
>
> das sieht ja recht ordentlich aus:-)
grins

Ziyat T. schrieb:
> villeicht sind die 0x92/0x88 auf anderem kanal?
Habe eine andere Theorie: Man muss nur lange genug ohne Anfrage 
warten, dann kommen die automatisch!

Wenn diese Theorie richtig ist, müßte es ausreichen, nur die 
0x08-Anfrage an die MI-600 zu senden (und entsprechend die untere 
Status-Anfrage an die MI-300 bzw. MI-1xxx). Wir bräuchten also uU. gar 
keine 0x09/0x11!

Mich beschäftigen in diesem Zusammenhang ein paar Fragen:
- Warum kamen die "anderen" Messages überhaupt, wenn sie nicht angefragt 
waren?
- warum waren in dem Log mit ausgeschaltetem CRC gestern relativ viele 
an sich "gute" (gleiche) Messages?
- warum empfängt man im reinen sniffer-Modus noch recht lange Daten vom 
WR, obwohl es keine Anfrage mehr geben dürfte?

Daraus ergibt sich für mich folgendes vorläufiges Bild:
- Wir brauchen einen gemeinsamen "Nenner", was den Kanal angeht. Steht 
der mal, haben die WR ein größeres "Beharrungsvermögen" auf diesem Kanal 
- der MI-600 hat jedenfalls mit einiger Sicherheit da angefangen, wo er 
abends aufgehört hatte...
- Einmal "angepingt" senden die unaufgefordert (vermutlich: in einem 
vereinbarten Interval) ihre Daten, möglicherweise etwas zeitiger, wenn 
es irgendwelchen signifikanten Änderungen gibt;
- als "Ping" ist möglicherweise bereits ein (Hardware-!)-ACK für eine 
beliebige Message des WR ausreichend, in jedem Fall aber eine beliebige 
Anfrage eines einzelnen Werts aus dem Gesamtpaket. Das mit dem 
Hardware-ACK deswegen, weil vermutlich das Senden der "immer gleichen 
Message" dann aufhört, wenn der Sender sein angeforderte ACK gehört 
hat...

Ergo würde ich die Zeit bis zur nächsten aktiven Anfrage mal deutlich 
verlängern (15-20 Min!), sobald wir eine Antwort vom WR haben (ACK 
genügt).

Weiß nicht, ob das so ist, aber wir sollten mAn. alle Anfragen mit 
ACK-Anforderung versenden.

Weiter könnte es eine gute Idee sein, sich das Routing jedes WR zu 
merken. Wenn wir "wissen", dass es einen Repeater braucht, müßte man 
mAn. den direkt anpingen und darum bitten, das weiterzugeben. Auch das 
müßte eigentlich mit ACK vom _End_-Empfänger gehen. Code dazu müßte 
(einmal mehr) bei MySensors zu finden sein.

Nachtrag: Das mit dem ACK ist übrigens der Grund warum ich davon 
ausgehe, dass es eine sehr gute Idee ist, dieses Projekt mindestens mit 
einem Modul mit PA+LNA auszustatten...

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Wenn diese Theorie richtig ist, müßte es ausreichen, nur die
> 0x08-Anfrage an die MI-600 zu senden (und entsprechend die untere
> Status-Anfrage an die MI-300 bzw. MI-1xxx). Wir bräuchten also uU. gar
> keine 0x09/0x11!
>

du hast mich falsch verstanden, nochmals:
es gibt nur die 0x09(PV1)/0x11(PV2) zum abfragen

nach der abfrage müssten 0x91/0x89(data) danach
0x92/0x88(status)kommen
edit:oder umgekehrt, das wissen wir (noch) nicht

es gibt keine sep. status abfrage

[Ziyat T. (toe_c)]

Jörg R. schrieb:

> - Einmal "angepingt" senden die unaufgefordert (vermutlich: in einem
> vereinbarten Interval) ihre Daten, möglicherweise etwas zeitiger, wenn
> es irgendwelchen signifikanten Änderungen gibt;
> - als "Ping" ist möglicherweise bereits ein (Hardware-!)-ACK für eine
> beliebige Message des WR ausreichend, in jedem Fall aber eine beliebige
> Anfrage eines einzelnen Werts aus dem Gesamtpaket. Das mit dem
> Hardware-ACK deswegen, weil vermutlich das Senden der "immer gleichen
> Message" dann aufhört, wenn der Sender sein angeforderte ACK gehört
> hat...

bisher kann ich das für den MI1500 nicht bestaetigen, beim sniffen der 
DT-Pro/MI1500, tut der WR einfach mal den kanal wechseln, warum auch 
immer

man muss immer daran denken, dass der MI300/MI600 schon einiges aelter 
sind, und der MI1500 der letzte von 2.gen ist, kann durchaus sein, dass 
das verhalten auch anderes ist

>- Einmal "angepingt" senden die unaufgefordert (vermutlich: in einem
> vereinbarten Interval) ihre Daten, möglicherweise etwas zeitiger, wenn
> es irgendwelchen signifikanten Änderungen gibt;

der MI1500 hört schnell auf, wenn nichts abgefragt wird

edit: hab gerade nachgeschaut, wr sendete etwa 10min lang auf ch61, dann 
jetzt plötzlich auf ch3

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> du hast mich falsch verstanden, nochmals:
> es gibt nur die 0x09(PV1)/0x11(PV2) zum abfragen
>
> nach der abfrage müssten 0x91/0x89(data) danach
> 0x92/0x88(status)kommen
> edit:oder umgekehrt, das wissen wir (noch) nicht
>
> es gibt keine sep. status abfrage
Habe offenbar den Mechanismus dann fehlinterpretiert, hatte das hier von 
neulich im Hinterkopf und daraus geschlossen, dass es evtl. möglich ist, 
auch die 0x08 als Anfrage zu versenden:
Stefan T. schrieb:
> Die Antworten haben i.d.R. das erste (höchstwertige) Bit gesetzt:
> * Anfrage 0x09 -> Antwort 0x09|0x80=0x89
> * Anfrage 0x11 -> Antwort 0x11|0x80=0x91
> * Anfrage 0x36 -> Antwort 0x36|0x80=0xB6

Ziyat T. schrieb:
> bisher kann ich das für den MI1500 nicht bestaetigen, beim sniffen der
> DT-Pro/MI1500, tut der WR einfach mal den kanal wechseln, warum auch
> immer
>
> man muss immer daran denken, dass der MI300/MI600 schon einiges aelter
> sind, und der MI1500 der letzte von 2.gen ist, kann durchaus sein, dass
> das verhalten auch anderes ist
>
> edit: hab gerade nachgeschaut, wr sendete etwa 10min lang auf ch61, dann
> jetzt plötzlich auf ch3
Hmm, sendest du die Anfragen weiter unter allen Channels raus? Bzw. die 
DT-Pro? Wenn ja, ist das uU. einfach ein bug der DTU. Es kann zwar sein, 
dass der MI1500 irgendwie speziell ist, aber warum sind die Gen-3-Geräte 
dann gut erreichbar, wenn man nur ch03 verwendet? (So macht das ahoy, 
oder?) Wäre nur zu erklären, wenn sich das (neue) Prinzip nicht bewärt 
hätte.
Oder kannst du zwischendurch was sniffen, was nach Aufforderung zum 
"Kanalwechsel" aussieht?

Und kannst du den aktuellen rx-Kanal sehen/sichtbar machen, über den die 
0x88/0x92-Infos reinkommen? Wie ist der Zeitstempel im Verhältnis zur 
zugehörigen "Hauptmessage"?

>der MI1500 hört schnell auf, wenn nichts abgefragt wird
Unter welchen Rahmenbedingungen hast du das getestet? Mit oder ohne 
rx-hop?
Und was ist "schnell"? (uU. können/müssen wir eben passende Timings 
konfigurieren).
EDIT: ok, das waren in dem Fall 10 Minuten, wenn ich es richtig 
interpretiert habe.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:

> Hmm, sendest du die Anfragen weiter unter allen Channels raus? Bzw. die
> DT-Pro? Wenn ja, ist das uU. einfach ein bug der DTU. Es kann zwar sein,
> dass der MI1500 irgendwie speziell ist, aber warum sind die Gen-3-Geräte
> dann gut erreichbar, wenn man nur ch03 verwendet?

weil die 2.gen und 3.gen WRs andere SW haben, in der ein völlig anderer 
mechanismus implementiert ist, sonst waere ja alles gleich und einfach

> Unter welchen Rahmenbedingungen hast du das getestet? Mit oder ohne
> rx-hop?

sniffer-mode

übrigens: wenn wir auf ack warten, dann funktioniert der sniffer nicht, 
aber das ist egal, andere baustelle

edit: ich bau mal die sw um, rxCH=txCH und hopping wenn ein SW-ack 
kommt, mal schauen

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> weil die 2.gen und 3.gen WRs andere SW haben, in der ein völlig anderer
> mechanismus implementiert ist, sonst waere ja alles gleich und einfach
Na ja, aus bestimmten Limitierungen der nRF-Hardware kann auch die 
3.Gen-firmware nur schlecht raus, das klingt (von sehr weit weg 
vermutet) irgendwie eher danach, als wäre da halt eine stricktere 
Abfolge von geringfügig weniger Messages erforderlich.
Eigentlich glaube ich, dass das auch für die 2. Gen-Geräte richtig wäre:
1. Paket anfordern, auswerten, gleich das 2. anfordern, dann warten bis 
3+4 kommen, alles zusammen auswerfen. Kommt Paket 1 oder 2 nicht: 
nochmal anfordern, erst beim 3. Mal aufgeben, diesen Teil der Daten 
nicht ausgeben.

> sniffer-mode
>
> übrigens: wenn wir auf ack warten, dann funktioniert der sniffer nicht,
> aber das ist egal, andere baustelle
Ähm, fyi: gestern morgen war ich noch der festen Überzeugung, ich hätte 
die nRF geschrottet, weil ESP1 (im sniffer-Mode!) nichts (!) von dem 
gesehen hat, was ESP2 gesendet hat, und auch nichts von dem, was der WR 
vielleicht geantwortet hat. Aber auch ESP2 hat keine Antworten 
bekommen...

> edit: ich bau mal die sw um, rxCH=txCH und hopping wenn ein SW-ack
> kommt, mal schauen
Bin gespannt.

Nachtrag noch zu den Fragen von vorhin: während du für 10 Minuten nichts 
gesendet hattest - hat da der WR irgendwas zum Status der einzelnen 
Eingänge von sich gegeben?

[Ziyat T. (toe_c)]

Jörg R. schrieb:

> Nachtrag noch zu den Fragen von vorhin: während du für 10 Minuten nichts
> gesendet hattest - hat da der WR irgendwas zum Status der einzelnen
> Eingänge von sich gegeben?

wenn ich max 1 min nichts sende, hört der auf

[Sebastian (Gast)]

Steffen D. schrieb:
> Jörg R. schrieb:
>
>> Sebastian schrieb:
>>
>>> Das Funkmodul dazu
>>> https://www.amazon.de/gp/aw/d/B075DBDS3J?psc=1&ref=ppx_pop_mob_b_asin_title
>>
>> Wenn du wirklich DIESE Funkmodule bestellt, hast, ist das möglicherweise
>> die falsche Ausführung, das muss eines mit "+" sein, also nicht
>> "NRF24L01", sondern "NRF24L01+"! Auf dem Aufdruck auf dem Chip sollte es
>> zu erkennen sein. Da muss ein + mit draufstehen, und optimalerweise
>> sollte die ganze Schrift klar sein (=früher war "verwaschen" ein
>> Anzeichen für fake chips").
>
> Die Funkmodule sind in Ordnung. Ich verwende sie auch. In der
> Beschreibung steht folgendes " Set bestehend aus 3 x NRF24L01+! ".

So ein Update, soweit läuft jetzt alles mit der Hardware. Der Fehler lag 
daran ohne Kondensator läuft der NRF nicht an.

Nun hab ich das Problem das das Webinterface nach einiger Zeit nicht 
mehr erreichbar ist bzw der ESP arbeitet weiter.

[Jörg R. (rejoe2)]

Oha, das ist (gefühlt) kurz...

Wenn wir den also "sicher" auf dem aktuellen Kanal halten wollten, 
müßten wir spätestens nach unter 50 Sekunden anfangen, den anzupingen, 
soweit so schlecht. Dann sollte die "hopping-Frequenz" unseres Codes 
irgendwie so versetzt sein, dass wir entweder mind. 5 Minuten warten* 
(dann wäre er ggf. wieder da?) => 5:30 beginnen, ggf. hinterherzulaufen 
(oder entgegen?), was umso besser gelingen könnte, wenn wir dann die 
Reihenfolge wüßten, in die wir ggf. zu gehen haben oder wir müßten nach 
einem Verbindungsabbruch dann eben wieder relativ schnell durch die 
Kanäle zappen (1-3 Sekunden?).

*Warten wäre ggf. die bessere Variante, wenn wir bereits eine "Herde" 
haben, die auf Kommandos auf dem betr. Kanal warten. Macht im Moment 
für's Testen noch keinen Unterschied, aber m.E. sollte man diesen Aspekt 
im Hinterkopf behalten. Es kann ja Gründe geben, warum einer "unseren 
Kanal" nicht mehr will (Interferenzen wg. anderem Sender in der Nähe des 
WR etc.). Dann könnte man den auf dem Fuße folgen und darauf warten, 
dass der Rest nachkommt.

Oder es bekommt eben jeder WR "seine" Frequenz?

Na ja, bißchen viel auf einmal, oder? Für's erste müßte es erst mal 
genügen rauszufinden, ob man dem MI1500 einfach auf einem Kanal halten 
kann, und wie viele Anfragen es braucht, damit er "alles" sendet. Dto 
für den MI-600. Kann grade nur sporadisch schauen, aber das sieht 
plausibel aus, und es gibt bei einem der Kanäle sogar eine "3"-Info...

Werde daher vielleicht als erstes die 5 Sekunden aus meiner Fassung des 
Sketches zu 25 Sekunden ausweiten?

[Rene M. (Firma: Bitte wählen) (renmo)]

@Sebastian
versuche ein anderes stärkeres Netzteil.
Welche Version hast du genau installiert?

[Ziyat T. (toe_c)]

Jörg R. schrieb:

> Wenn wir den also "sicher" auf dem aktuellen Kanal halten wollten,
> müßten wir spätestens nach unter 50 Sekunden anfangen, den anzupingen,
> soweit so schlecht.

das hatte ich schon früher gesehen, jetzt auch wieder, der wr sendet auf 
allen kanaelen, bin ziemlich sicher.

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> das hatte ich schon früher gesehen, jetzt auch wieder, der wr sendet auf
> allen kanaelen, bin ziemlich sicher.

Es irritiert mir zwar immer noch, aber du wirst das mit deinen 
Erfahrungen besser wissen. Es erscheint mir nicht logisch, effektiv >80% 
der Zeit "blind" zu fliegen und dabei zu behaupten, dass man auch 
größere Netze überwachen könnte (so hatte ich das im Hinterkopf als 
Inhalt eines Werbefilmchens von denen mal abgespeichert).
Vielleicht ist es ähnlich wie bei manchen von diesen Temperatursensoren, 
die die Hälfte der Zeit mit der einen Methode senden und die andere mit 
einer anderen? Also: Hauptinfo auf Kanal 1, Statusinfo auf Kanal 2 (oder 
3). Bricht einer weg, wechselt der Hauptkanal auf den anderen, und es 
wird ein neuer fallback ausgehandelt?

Mir fehlt nur grade eine Idee, wie man sowas austesten könnte. Wenn die 
Theorie aufgeht, dass man auch den MI-1500 auf dem einen Hauptkanal 
halten kann, wenn man nur regelmäßig genug 0x36-0x39 abfragt (?), müßte 
es doch gehen, den Regelablauf so zu machen, dass man erst auf dem 
Hauptkanal die 4 Werte abfragt, und dann auf den übrigen scannt, wobei 
es Zufall sein mag, dass vorhin der Wechsel im Hauptkanal von 61 nach 03 
ging (relativ großer Abstand wie oben bereits theoretisiert).
Das ergäbe sowas wie: <20 Sekunden für die 4 Anfragen samt Warten auf 
Antwort, dann je 2 Durchläufe über die übrigen Kanäle à je knapp 5 
Sekunden. Hat man einen Treffer, auf diesem Kanal die restlichen 40 
Sekunden lauschen?
(Modell für einen WR, klar...).

Oder gibt es für sowas bessere, standardisierte Methoden?

[Sebastian (Gast)]

Rene M. schrieb:
> @Sebastian
> versuche ein anderes stärkeres Netzteil.
> Welche Version hast du genau installiert?

Ahoy 0.5.8 und Netzteile habe ich schon etliche versucht. Sehr komisch, 
jetzt lief der ESP mal eine Stunde durch und verschwindet.

[Rene M. (Firma: Bitte wählen) (renmo)]

gibt schon eine neuere ahoy Version.
Hast du MQTT aktiviert?

[Highlander (Gast)]

@AHOY

Über welche serielle Schnittstelle läuft die Debug Ausgabe beim ESP8266?
Über die am USB Anschluß (Darüber versorge ich ihn gerade mit einem Ipad 
Ladegerät mit 5V)?

Ist die immer aktiviert oder im Sourcecode freizuschalten?
Wenn wo?

Eine ältere Version 3.6 oder so läuft bei mir seit Monaten ohne jedes 
Problem.

Seit ein paar Tagen keine Daten mehr vom HM1500.

Ich hoffe so auf aussagekräftige Informationen.
Ich sehe das permanent angefragt wird, aber vom HM1500 kommt nichts 
zurück.
Ich hoffe der WR ist nicht nach 6 Monaten schon im "Himmel".
Er speist aber noch artig ein.

2-3 Tage vorher sah ich auf einem der 3 Panels plötzlich nur noch ein 
paar Watt Abgabe.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> das hatte ich schon früher gesehen, jetzt auch wieder, der wr sendet auf
>> allen kanaelen, bin ziemlich sicher.
>
>
> Mir fehlt nur grade eine Idee, wie man sowas austesten könnte.

ich habe leider nur 1 esp+nrf aber,
wenn du 2 esp+nrf hast, könntest so testen:
-ESP1 sendet nur auf einem CH
-ESP2 empfaengt alle CH

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> wenn du 2 esp+nrf hast, könntest so testen:
> -ESP1 sendet nur auf einem CH
> -ESP2 empfaengt alle CH
Stimmt eigentlich...

Frage noch zu dem Mi-1500-Teil des Codes. Es gibt keine separate 
Auswertung der "Status"-Messages? Diese Infos sind bei diesem Typ Teil 
der "normalen" Messages aus 0x36-0x39, oder ist mir was rausgegangen?

Und wenn das so ist: wieso bist du dir sicher, dass die nicht (z.B.) per 
0x08-Anfrage gesondert abzurufen wären? Die gesendeten Daten aus einem 
MI-600 hatte ja bis zu diesem Punkt noch keiner von uns hier gesehen, 
oder?

[Ziyat T. (toe_c)]

@Jörg R.
kannst du bitte diese variante mal testen?

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Ziyat T. schrieb:
>> wenn du 2 esp+nrf hast, könntest so testen:
>> -ESP1 sendet nur auf einem CH
>> -ESP2 empfaengt alle CH
> Stimmt eigentlich...
>
> Frage noch zu dem Mi-1500-Teil des Codes. Es gibt keine separate
> Auswertung der "Status"-Messages? Diese Infos sind bei diesem Typ Teil
> der "normalen" Messages aus 0x36-0x39, oder ist mir was rausgegangen?
ja

> Und wenn das so ist: wieso bist du dir sicher, dass die nicht (z.B.) per
> 0x08-Anfrage gesondert abzurufen wären?

ich kenne keine 0x08-anfrage für MI

> Die gesendeten Daten aus einem
> MI-600 hatte ja bis zu diesem Punkt noch keiner von uns hier gesehen,
> oder?

du hattest ja auch mal gesehen
CH3 00 1234567801 0082 10 1  92 60100013 60100013 00[03]00000000913454 1
diese [03] ist status = producing

[Marki (Gast)]

Hallo,
ich habe zwei Hm-400. Gestern habe ich mir mal die Ahoy version 0.5.4 
geflasht und das erste mal getestet. Funkverbindung über ca 25m ging auf 
anhieb. nur hatte ich vergessen das ich bei Produktion der 2 WR die 
0Watt in der Setup Seite auf 400 ändere. Seitdem produziert einer der 2 
WR nicht mehr.
Gibts irgendein reset befehlt? Das er wirklich nicht mehr produziert 
sehe ich an den SDM120, also stimmt die Anzeige in der Ahoy Software.

[Sebastian (Gast)]

Sebastian schrieb:
> Rene M. schrieb:
>
>> @Sebastian
>> versuche ein anderes stärkeres Netzteil.
>> Welche Version hast du genau installiert?
>
> Ahoy 0.5.8 und Netzteile habe ich schon etliche versucht. Sehr komisch,
> jetzt lief der ESP mal eine Stunde durch und verschwindet.

So gibt es wieder ein Update,  ein 2. Kondensator hat geholfen am 5 V 
Anschluss vom ESP,  bis jetzt läuft er stabil.

[Sigi S. (sermon)]

Hallo Leute,

das ist eine völlig neue Umgebung für mich.
Ich fühle mich verloren.

Gibt es eine etwas detailliertere Step By Step Anweisung um das Projket 
zu importieren, erfolgreich zu compilieren, als auch auch zu flashen 
(denke das geht direkt aus Visual Studio Code heraus?), als diese hier:?
Ich benötige Hilfe, Danke

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This code can be compiled using Visual Studio Code and PlatformIO Addon. 
The settings were:

    Board: Generic ESP8266 Module
    Flash-Size: 1MB (FS: none, OTA: 502kB)
    Install libraries (not included in the Arduino IDE 1.8.19):
        Time Arduino Time library (TimeLib.h)
        RF24 Optimized high speed nRF24L01+ driver class documentation
        PubSubClient A client library for MQTT messaging. By Nick 
O'Leary
        ArduinoJson Arduino Json library

[Tobi (Gast)]

Marki schrieb:
> Funkverbindung über ca 25m ging auf
> anhieb.

Bei mir geht nicht mal 50 cm stabil.

Kannst Du bitte mal schreiben welchen ESP und welchen NRF24 du genau 
verwendest (am besten mit Produktlink). Ob Du Kondensatoren verbaut 
hast. Besonderheiten. Etc.

Danke!

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> du hattest ja auch mal gesehen
> CH3 00 1234567801 0082 10 1  92 60100013 60100013 00[03]00000000913454 1
> diese [03] ist status = producing
Soweit ist es klar, der WR meldet das übrigens jetzt grade auch auf 
beiden Kanälen, die hinteren beiden Felder sind (vermutlich unverändert) 
jeweils auf 0.

Die (für mich noch nicht ganz geklärte) Frage ist ja gerade, warum die 
mit dem "Gerausche" eher häufiger zu sehen gewesen waren - dafür aber 
mit "kaputtem Beiwerk", und jetzt so selten.
Komme auf die Schnelle auf zwei Varianten: Entweder haben wir den WR 
verwirrt und er hat eben "kaputte Messages" als (undokumentierte...) 
Aufforderung akzeptiert, oder es gab zwischendurch einen Kanalwechsel, 
bei dem dann mehr oder weniger zufällig so eine "reguläre Statusmessage" 
abgefangen wurde.

Beides möglich, vielleicht knödle ich testweise mal ergänzend einen 
0x08-Anfrageversuch rein. Wenn ich den Code richtig verstanden habe, 
müßte man halt statt des "flip-flops" noch eine dritte (bzw. falls das 
wider Erwarten klappt: und 4.) Variante einbauen.

Danke vorab für Code und die Erhellung, was den MI-1500 angeht.

[Marki (Gast)]

Tobi schrieb:
> Marki schrieb:
>> Funkverbindung über ca 25m ging auf
>> anhieb.
>
> Bei mir geht nicht mal 50 cm stabil.
>
> Kannst Du bitte mal schreiben welchen ESP und welchen NRF24 du genau
> verwendest (am besten mit Produktlink). Ob Du Kondensatoren verbaut
> hast. Besonderheiten. Etc.
>
> Danke!

diese nrf24+ Module
https://www.aliexpress.com/item/32719545755.html?spm=a2g0o.order_detail.0.0.598e6368s2llpG

und dieses 5er pack
https://de.aliexpress.com/item/1005003722134215.html?spm=a2g0o.order_list.0.0.21ef5c5fU9zuSa&gatewayAdapt=glo2deu

kein Kondensator, und Netzteil war von einen alten FireTV Stick, glaub 
das macht so um die 2A. Aber auch an der USB 2 buchse von meinen 
Thinkpad T430 kommt genug Strom raus.

die Funkmodule hatte ich schon im Oktober gekauft bin aber am schlechten 
bzw dunklen Wetter gescheitert da irgendwas zu machen und als ich jetzt 
im Sommerurlaub mal schauen wollte bin ich hier über den Beitrag 
gestolpert und hab mir viel zeit gespart.

Ich werde mir auch mal das OpenDTU anschauen, da ich hier einige ESP32 
mit Ethnernet und POE habe und dann kann ich auf das WLAN verzichten.

[J. S. (jojos)]

Kann man mit den Erkenntnissen hier einen HM-1500 auf 600 Watt drosseln 
für den Betrieb als BKW? Oder habt ihr die als Festinstallation laufen?

[Dirk K. (millenniumpilot)]

hätte die gleiche Frage. Hoymiles 1500 bekommt man noch relativ gut, die 
Brot und Butter Modelle 300 und 600W sind alle ausverkauft

[Rene M. (Firma: Bitte wählen) (renmo)]

Drosseln kann man sie, aber vereinfacht anmelden kann man sie nicht.

[Ziyat T. (toe_c)]

Jörg R. schrieb:

> Beides möglich, vielleicht knödle ich testweise mal ergänzend einen
> 0x08-Anfrageversuch rein. Wenn ich den Code richtig verstanden habe,
> müßte man halt statt des "flip-flops" noch eine dritte (bzw. falls das
> wider Erwarten klappt: und 4.) Variante einbauen.

mich nimmt es wunder woher du diese 0x08 hast, die ist im 
RF_communication_protocol-V6.6.xlsx "Data collection instructions" nicht 
beschrieben, oder sehe ichs falsch?

[Günter H. (gnter_h534)]

Sigi S. schrieb:
> das ist eine völlig neue Umgebung für mich.
> Ich fühle mich verloren.
>
> Gibt es eine etwas detailliertere Step By Step Anweisung um das Projket
> zu importieren, erfolgreich zu compilieren, als auch auch zu flashen
> (denke das geht direkt aus Visual Studio Code heraus?)

Mein Vorschlag ist, hier

https://github.com/lumapu/ahoy/actions

die aktuelle (oberste) bin-Datei herunterzuladen (vorher bei GitHub 
anmelden) und mit einem (fast beliebigen) Flash-Programm zu flashen.

Die weitere Inbetriebnahme ist dann hier

https://github.com/lumapu/ahoy/tree/main/tools/esp8266#readme

beschrieben. Zukünftige Updates können dann über die Weboberfläche 
angestoßen werden.

Für eine allgemeine Einführung in PlatformIO bitte im Internet nach 
Tutorials suchen.

[Sigi S. (sermon)]

Günter H. schrieb:
> Mein Vorschlag ist, hier
>
> https://github.com/lumapu/ahoy/actions
>
> die aktuelle (oberste) bin-Datei herunterzuladen (vorher bei GitHub
> anmelden) und mit einem (fast beliebigen) Flash-Programm zu flashen.
>
> Die weitere Inbetriebnahme ist dann hier
>
> https://github.com/lumapu/ahoy/tree/main/tools/esp8266#readme
>
> beschrieben. Zukünftige Updates können dann über die Weboberfläche
> angestoßen werden.
>
> Für eine allgemeine Einführung in PlatformIO bitte im Internet nach
> Tutorials suchen.

Danke,

Compilieren in Platformio bekomme ich nun hin, nur flashen geht nicht.
Mit Nodemcu flasher geht es.
Ich finde kein Eingabefeld für den Inverter Typ mehr, habe einen 1500.
Ist das nicht mehr nötig?

Danke

[Ziyat T. (toe_c)]

@Jörg R.

hier ist das sniffer log von DTU-Pro und MI1500, wegen der ch-hopping

[Günter H. (gnter_h534)]

Sigi S. schrieb:
> Ich finde kein Eingabefeld für den Inverter Typ mehr, habe einen 1500.
> Ist das nicht mehr nötig?

Doch. Siehe Screenshot.

Hilfe zum Ausfüllen gibt es auch hier:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

[Marki (Gast)]

Marki schrieb:
> von
>
>         Marki

mit der 5.9.10

Marki schrieb:
> Hallo,
> ich habe zwei Hm-400. Gestern habe ich mir mal die Ahoy version 0.5.4
> geflasht und das erste mal getestet. Funkverbindung über ca 25m ging auf
> anhieb. nur hatte ich vergessen das ich bei Produktion der 2 WR die
> 0Watt in der Setup Seite auf 400 ändere. Seitdem produziert einer der 2
> WR nicht mehr.
> Gibts irgendein reset befehlt? Das er wirklich nicht mehr produziert
> sehe ich an den SDM120, also stimmt die Anzeige in der Ahoy Software.

0.5.10 mal getestet und als Limit 400 eingestellt, dann hat der eine WR 
wieder angefangen zu Produzieren, scheint also in der 0.5.4 ein Bug 
gewesen zu sein.

Wäre es möglich einzubauen, ob die Limitierung überhaupt an den WR 
geschickt wird? Wenn die regelmäßig da hin geschickt wird, ist das 
EEPROM bald kaputt, zumindest bin ich mit fast sicher das es keine 5 
Jahre halten wird.

Ich glaub mal irgendwo in einen Solarforum gelesen zu haben dass die DTU 
Pro zwei verschiedene Möglichkeiten hat, eine Permanente (zb für die 70% 
hier in DEU) und eine für die Nulleinspeisung, die wird aber blos ins 
RAM geschrieben.


Auch wenn die Ahoy-DTU nur einmal am Tag das schicken würde wären es 
schon 365mal in Jahr... Wäre also vielleicht nicht schlecht wenn man die 
Limitierung vielleicht mit einen Button einmal wegschicken kann oder so?

[Marki (Gast)]

Achso, wenn ich mehr als 3 WR will, muss ich irgendwo in einer .h die 
Zahl erhöhen oder?

[Ziyat T. (toe_c)]

Marki schrieb:
> Ich glaub mal irgendwo in einen Solarforum gelesen zu haben dass die DTU
> Pro zwei verschiedene Möglichkeiten hat, eine Permanente (zb für die 70%
> hier in DEU) und eine für die Nulleinspeisung, die wird aber blos ins
> RAM geschrieben.

es gibt keine permanente limit-konstante für den wr, wenn im 
smiles-cloud z.b. 70% eingestellt wird, schickt dtu diese jeden tag 1x.
bei zero-export, es wird dauernd (sie sagen es so, aber leider alle 
15min)  der smartmeter abgefragt, danach wenn nötig der wr limitiert

[Sorbit (Gast)]

Günter H. schrieb:
> Sigi S. schrieb:
>> Ich finde kein Eingabefeld für den Inverter Typ mehr, habe einen 1500.
>> Ist das nicht mehr nötig?
>
> Doch. Siehe Screenshot.
>
> Hilfe zum Ausfüllen gibt es auch hier:
> Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

In dem Screenshot steht nichts vom Typ des WR.
Das war doch die Frage!
Oder erkennt er das über die Seriennummer?

[Günter H. (gnter_h534)]

Stimmt, im Screenshot steht nichts vom Typ des WR - der Typ des WR wird 
über die Seriennummer zugeordnet. Das wird über den verlinkten 
Screenshot deutlich.

[M. P. (matze7779)]

Hallo,

ich habe gerade die 0.5.5 installiert.
Nach dem Update war im Setup das Power Limit auf 0 --> Alles normal
Zum Test auf 300 gesetzt --> WR regelt auf 300 herunter.
Beim Versuch das wieder auf 0 zu stellen bleibt der Wert nach dem Reboot 
auf 300.
Ein Wert von 800 wird angenommen.

WR: HM-800

Gerade auf 0.5.10. Auch hier wird eine "0" bei "Active Power Limit (W)" 
nicht angenommen um das Limit zu deaktivieren.

Und wie bekomme ich den Power Limit Wert in iobroker?

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> @Jörg R.
> kannst du bitte diese variante mal testen?

Komme ich vermutlich erst morgen dazu, aber hier noch was interessantes:

15869 Send... CH61 0960100013785634120062.....send res 0
20769 Send... CH61 116010001378563412007A.....send res 0
20985 CH40 00 1234567801 0082 10 1  92 60100013 60100013 000300000000913454 1
ImpExpW Watt 1660.0Watt  | All PVs received?:0
ImpExpW Watt 1440.0Watt  | All PVs received?:0
25669 Send... CH61 0960100013785634120062.....send res 0
25704 CH40 00 1234567801 0082 10 1  88 60100013 60100013 0003000000008BF5C9 1
30569 Send... CH61 116010001378563412007A.....send res 0
30601 CH40 00 1234567801 0080 10 0  92 60100013 60100013 000300000000911590 1
ImpExpW Watt 1600.0Watt  | All PVs received?:0
35469 Send... CH61 0960100013785634120062.....send res 0
ImpExpW Watt 1760.0Watt  | All PVs received?:0
40369 Send... CH61 116010001378563412007A.....send res 0
ImpExpW Watt 2490.0Watt  | All PVs received?:0
45269 Send... CH61 0960100013785634120062.....send res 0
ImpExpW Watt 2890.0Watt  | All PVs received?:0
ImpExpW Watt 2690.0Watt  | All PVs received?:0
50169 Send... CH61 116010001378563412007A.....send res 0
55069 Send... CH61 0960100013785634120062.....send res 0
55101 CH40 00 1234567801 0080 10 0  88 60100013 60100013 0003000000008BD40D 1
ImpExpW Watt 2840.0Watt  | All PVs received?:0
59969 Send... CH61 116010001378563412007A.....send res 0
60005 CH40 00 1234567801 0082 10 1  92 60100013 60100013 000300000000913454 1
ImpExpW Watt 2520.0Watt  | All PVs received?:0
ImpExpW Watt 2200.0Watt  | All PVs received?:0
64869 Send... CH61 0960100013785634120062.....send res 0
ImpExpW Watt 2020.0Watt  | All PVs received?:0
69769 Send... CH61 116010001378563412007A.....send res 0
ImpExpW Watt 1620.0Watt  | All PVs received?:0
69984 CH40 00 1234567801 0080 10 0  92 60100013 60100013 000300000000911590 1
ImpExpW Watt 1390.0Watt  | All PVs received?:0
74669 Send... CH61 0960100013785634120062.....send res 0
74703 CH40 00 1234567801 0082 10 1  88 60100013 60100013 0003000000008BF5C9 1
79569 Send... CH61 116010001378563412007A.....send res 0
79602 CH40 00 1234567801 0080 10 0  92 60100013 60100013 000300000000911590 1
84469 Send... CH61 0960100013785634120062.....send res 0
84502 CH40 00 1234567801 0086 10 3  88 60100013 60100013 0003000000008BB641 1
ImpExpW Watt 1230.0Watt  | All PVs received?:0

Sketch dazu (ziemlich wild (!) anbei. Rahmenbedingungen: der andere ESP 
tuckert munter vor sich hin (seit neulich schon). Die scheinen sich also 
auf CH61 geeinigt zu haben.
Und in der Tat kann man 0x08-Anfragen nicht als solche erfolgreich 
durchführen.

ABER: die 003-er-Antwort kommt soweit ersichtlich immer verlässlich auf 
CH40. Ergo müßte tatsächlich man einen kurzfristigen Switch 
zwischendurch einplanen, und zwar vermutlich immer auf den vorherigen 
(so ist es ja auch im "channel-hop" angelegt). Muss mal bei Gelegenheit 
die Zeitstempel ansehen, ob man erst nach Erhalt der eigentlich 
angefragten Info umschalten sollte, oder erst kurz für die 003-er. 
(falls man die überhaupt braucht. Mit dem Content habe ich mich bisher 
nicht beschäftigt...). Auf die 11-er-Anfrage sehe ich übrigens auch 
häufig die Antworten für beide (zeitlich sehr eng beeinander). Es könnte 
also reichen, nach der 11-er-Anfrage kurz rx umzuschalten (für ca. 
300ms?). Kann aber auch Zufall sein, und es sind Antworten auf die 
Anfragen vom anderen ESP.

Für ein "echtes" Durchrollieren sehe ich im Moment jedenfalls keine 
Veranlassung, und warum die 003-er hin und wieder auch so empfangen 
werden, wissen vermutlich nur die Wifi-Götter....

[Carsten B. (carstenb)]

Jörg R. schrieb:
>> hast du es in FHEM eigentlich noch hinbekommen?
>
> Es gibt einen ersten attrTemplate-Vorschlag dazu im FHEM-Forum. Bitte
> ggf. da anhängen.

Danke, das hat prima funktioniert :-)

https://forum.fhem.de/index.php/topic,121282.0.html

[Jörg R. (rejoe2)]

Carsten B. schrieb:
> Danke, das hat prima funktioniert :-)

:-) Im svn ist übrigens ein update (kommt dann morgen, wenn man es nicht 
manuell holt). Das sollte dann ein paar zwischenzeitlich erkannte 
Problemchen lösen, etwas mehr erläutern und auch für 1- bzw 4-kanalige 
passen.

Ziyat T. schrieb:
> @Jörg R.
> kannst du bitte diese variante mal testen?
läuft grade im Solo-Betrieb seit ca. 20 Minuten. Aber außer 
Sendeanweisungen und Kanalwechseln war da nichts interessantes an 
output.

Habe dann den "normal-Sketch" von vor ein paar Tagen auf dem anderen ESP 
wieder angeschaltet. Der findet den WR anscheinend direkt wieder. Dann 
bekomme ich auch mit diesem Sketch eingehende Nachrichten, aber nur je 
einmal unter CH23 und CH40, direkt nach dem Kanalwechsel, wobei CH23 
dann die 3-Info 88 geliefert hat und CH40 die 3-Info 92 (!)...

Bringt dich das irgendwie weiter?

Nachtrag: Habe mir jetzt den anderen nochmal per mincom angesehen und 
die Zeitstempel betrachtet. Danach scheint es so zu sein, dass der WR 
erst die Statusmessage auf dem unteren Kanal sendet, und dann die 
weiteren Daten. Ergo müßte man (nur!) nach dem Senden der 09/11-Anfragen 
auf den vorherigen Kanal umschalten (längstens für 200 ms?), und könnte 
dann direkt nach dem Empfang der Status-Message wieder auf den 
"default", um den Rest einzufangen.

[Ziyat T. (toe_c)]

Jörg R. schrieb:
>> kannst du bitte diese variante mal testen?
> läuft grade im Solo-Betrieb seit ca. 20 Minuten. Aber außer
> Sendeanweisungen und Kanalwechseln war da nichts interessantes an
> output.

NRF24_SendRcvMIesp4.zip laeuft bei mir recht gut, wenn dein setting ok 
ist dann müsstest du etwas empfangen, oder ist esp+nrf sendet nicht

edit: wegen dieser ch beibehalten geschichte: das gefaellt mir nicht, 
weil  wir für solchen probleme, wie bei deinem MI600 data und status 
pakete, immer andere spez. lösungen haben müssen.
es steht für mich fest (wie wir früher auch herausgefunden haben), dass 
der wr die antworten auf allen ch's schickt, wir müssen halt dann auch 
schnell ch wechseln

[Jörg R. (rejoe2)]

Hmm, weiß nicht...

In den sniff von der DTU habe ich kurz reingeschaut, weiß aber nicht so 
richtig, wie ich das interpretieren soll. Die sendet Anfragen an den 
konkreten WR raus und nimmt dabei scheinbar keine Rücksicht darauf, 
ob/wie sie was empfängt. Ergo geht sie jedenfalls nicht davon aus, dass 
ein bestimmter Kanal besser wäre wie andere (ch09 kommt allerdings vor, 
wenn auch selten, k.A., warum). Auf was sie dann hört wissen wir nicht, 
der Code mit dem "Rücksprung" scheint aber aus dem DTU-Quellcode zu 
kommen.

Die WR ihrerseits haben ein gewisses Beharrungsvermögen auf einem 
bestimmten Channel und wechseln dann "irgendwann", wenn keine Anfrage 
kommt.

Du musst die firmware für die Nutzung iVm. der DTU in jedem Fall so 
auslegen, dass deren "Gefunke" dir nicht ins Gehege kommt. 
Nachvollziehbar.

Für mich stellt sich die Situation anders dar:
Ich habe keine DTU und will "einfach nur" den WR auslesen. Ich brauche 
auch nicht alle Nase lang aktualisierte Daten, mir würde es reichen, 
wenn z.B. alle Minute Daten kämen, aber dafür verläßlich.

Bedeutet ggf.: wir bilden eine Queue für alle WR, und versuchen dabei. 
möglichst alle auf einem Kanal zu halten und die Zahl der Umschaltungen 
dabei gering zu halten.
Für alle WR - mit Ausnahme des MI-600 (?) genügt dabei eine Frequenz 
-ergo bekommt der die niedrigste Prio. Ist die Queue soweit durch, dass 
der MI-600 dran ist, fangen wir erst die STS-Msg ab, dann möglichst 
direkt auch
die zugehörige Haupt-Info (1x direkt umschalten, dann zurück). Dto. für 
den 2. Kanal.
Sind wir durch, können wir für den Rest der Zeit gerne hopsen.
Nach jedem WR senden wir die "geballte Info" für diesen WR raus (Wunsch 
wäre JSON-encoded (!)), ggf. auch jeweils pro Kanal. Ggf. versuchen wir 
es ein 2. oder 3. Mal, wenn einer nicht antwortet, aber dann brechen wir 
ab und versenden, was wir haben (falls wir was haben).

Oder habe ich was grundlegend missverstanden?

PS: Die Meinungen der anderen hier, die mehr Erfahrung mit der ganzen 
Sache haben würden mich auch sehr interessieren. Es ist so still...

[Ziyat T. (toe_c)]

Jörg R. schrieb:
> Hmm, weiß nicht...

> Die WR ihrerseits haben ein gewisses Beharrungsvermögen auf einem
> bestimmten Channel und wechseln dann "irgendwann", wenn keine Anfrage
> kommt.

das wissen wir nicht, weil wir nicht gleichzeitig mehrere ch's hören 
können. wir "beharren" beim hören auf einen kanal, dann sieht es so aus 
als der wr  diesen auch "gut" findet.
so wars am anfang, wir hörten nur auf CH3, funktionierte schon, aber 
langsam, damit hatte ich ein problem und zwar:

> Ich habe keine DTU und will "einfach nur" den WR auslesen. Ich brauche
> auch nicht alle Nase lang aktualisierte Daten, mir würde es reichen,
> wenn z.B. alle Minute Daten kämen, aber dafür verläßlich.

ich brauche die zeroexport funktion:
da genügt es nicht (mit 4 PVs), irgendwann zu wissen wieviel der wr 
produziert, ich muss schnell (am besten alle 15 sek) wissen was die pv's 
bringen. darum bin ich aufs "ch hopsen beim rx" umgestiegen, so habe ich 
schneller 4 pv's erfassen können.
hier darf man nichts ins netz einspeisen, bzw. es wird als bezug v. netz 
verrechnet, es gibt nur eine art v. zaehler!!

ich habe eine DTU-pro; meine erwartung war, ich sage ihr mach die 
zeroexport mit 0W, und sie macht das. nein, sie kontrolliert eben alle 
5-15min, in der zeit, alles was du nichts konsumierst, wird schön 
eingespeist.
dann hat sie auch das problem mit MI1500, weil er nicht unter 150w 
(10%)limitert werden kann, sie schaltet ihn einfach aus, aber 
einschalten tut sie erst ab 300W konsum und zwar irgendwann!! (edit:über 
dieses problem schweigt der hersteller immer noch)

darum habe ich pi/python/modbus485, damit limitiere den wr selber, die 
DTU-pro ist "inaktiv", wird nur als ss zum wr gebraucht.

[Günter H. (gnter_h534)]

Lukas P. schrieb:
> Aktuell bekommt man Version 0.4.26, in Zukunft sollte man über den Link
> auch jede neuere Version bekommen (ohne Login):
> https://nightly.link/lumapu/ahoy/workflows/compile_esp8266/main/esp8266.zip

Eigentlich ein sehr schöner Service, leider erscheint inzwischen "Error 
404 – Not Found".

[Rene M. (Firma: Bitte wählen) (renmo)]

nimmt man einfach diesen link, da sind dann immer die aktuellen bins 
verfügbar
https://github.com/grindylow/ahoy/actions

[Günter H. (gnter_h534)]

Ist schon klar. Mit dem anderen Link braucht man halt keinen Login bei 
GitHub.

[Jörg R. (rejoe2)]

Ein Log sagt mehr wie viele Worte:

92388 Send... CH61 116010001378563412007A92389
.....send res 0
CH40 00 1234567801 0084 10 2  88 60100013 60100013 0003000000008B9785 1
CH61 00 1234567801 00C6 18 3  89 60100013 60100013 013F003609551382069500DC01787AFCCF 1
92536 CH:61 PV0 MI: 328W Grd:3230W Lm:   0W 168.5W 31.9V 5.4A  220Wh 238.9ACV 49.9Hz 37.6C S:3

Also bei guten Bedingungen ca. 150ms/Abfrage. Auf CH23 sind die 003-er 
auch zu finden, anzunehmen, dass der WR halt auch kurz braucht, um die 
angefragten Werte aufzubereiten.

Gehe davon aus, dass man für einen Mi-1500 bei halbwegs ordentlichen 
Bedingungen also keine Sekunde braucht, um ihn komplett auszulesen, und 
er wirklich DIREKT reagiert, wenn man eine Limitierung versendet.

Code dazu ist anbei.

Leider wird es mir nicht reichen, eine komplette statemachine für die 
Abfrage zu bauen, stelle mir sowas in der Art vor:

static bool received[4]  = {false};
static bool requestOpen  = true;

[...]
     if (MI600){         // 2 PVs
      MIDataCMD=!received[0] ? 0x09 : 0x11;

[...]
    if (MI1500){        // 4 PVs
      MIDataCMD = 0x0036
      for (int8_t i = 0; i < 4; i++) {
        if (!received[i]) {
             break;
        }
        ++MIDataCMD;
       }
     }
[...]
  if (received[0] && received[1] && received[2] && received[3]) {
    tickMillis = millis() + maxTimeForNextPing; //we got a message and will just wait....
    requestOpen  = false;
  }

[...]
  if (p->packet[2] == 0x89)  {PV= 0; TotalP[1]=P_DC; pvCnt[0]=1; received[0]=1; }//port 1
  if (p->packet[2] == 0x91)  {PV= 1; TotalP[2]=P_DC; pvCnt[1]=1; received[1]=1; }//port 2

Hoffe, es ist erkennbar, wie es gemeint ist.

[Christian E. (christian_e775)]

Hallo zusammen,

ich habe seit kurzem einen TSUN TSOL M800(de) und konnte heute relativ 
problemlos mit einem Raspberry + NRF24L01+ + ahoy Daten vom 
Wechselrichter empfangen :)
Mein Wechselrichter hat die Seriennummer 11418203xxxx

> Payload: 00 01 01 49 00 93 01 e2 01 4f 00 3c 00 c9 00 00 25 1e 00 00 18 0b 01 a9 
00 a8 09 02 13 86 02 8c 00 01 00 1c 03 e8 01 9f 00 0b 1e 64
> Decoded: temp=41.5, pf=1.0 phase0=voltage:230.6, current:2.8, power:65.2, 
frequency:49.98 string0=voltage:32.9, current:1.47, power:48.2, total:9.502, 
daily:425 sring1=voltage:33.5, current:0.6, power:20.1, total:6.155, daily:168

Wie man sieht ist der zweite Strang ungünstig positioniert aber das habe 
ich schon vermutet und wollte eigentlich nur eine Bestätigung.

Jetzt muss ich nur noch schauen wie ich das Richtung Volkszähler oder 
ähnlichen schön darstellbar hinbekomme.

Danke,
Christian

[peter (Gast)]

Hallo,

ich will demnächst zwei HM-1500 für einen Netzparallelen Akku mit 
Nulleinspeisung nutzen. Das Projekt scheint ja mittlerweile weit genug 
zu sein um das umzusetzen. Das ganze soll auf venusOS laufen und so habe 
ich als ersten Schritt erstmal ein PCB für den Raspberry PI erstellt 
(siehe Bild).
Bei Interesse kann ich gerne ein paar für euch mitbestellen :)

[Dirk M. (dirk_m695)]

Hi und Gruß in die Runde.

Ich verfolge den Thread seit ein paar Tagen, da ich mir ein 
Balkonkraftwerk installiert habe mit einem TSOL350 Wechselrichter.

Ich bin mit Arduino und AVR Mikrokontrollern vertraut und will Mal 
schauen, ob ich hier was finde, bei dem ich unterstützen kann.

Ich hab auch noch einen Webspace mit ein paar freien URLs übrig. Falls 
das von euch von Interesse wäre, könnte ich euch anbieten, dass man dort 
z.B. ein Forum einrichtet inkl. Admins von euch.

Außerdem kann ich Android Apps erstellen. Vielleicht wäre es ja 
interessant, dass man sich die Daten der Wechselrichter über einen 
NRF+ESP aufs Handy anzeigen lassen kann.

Einen 3D Drucker zum Drucken von Gehäusen hätte ich ebenfalls. Für den 
Fall, dass es Mal eine gute Idee für einen all-in-one System gibt.

Auf jeden Fall schon Mal danke dafür, dass ihr so ein Projekt aufgezogen 
habt aus einer so einfachen Frage, die im ersten Beitrag steht.

[Sigi S. (sermon)]

Dirk M. schrieb:
> Vielleicht wäre es ja
> interessant, dass man sich die Daten der Wechselrichter über einen
> NRF+ESP aufs Handy anzeigen lassen kann.

Vielleicht solltest Du dich etwas genauer mit der bestehenden Lösung 
auseinandersetzen? ;-)

[Frank L. (guilligan)]

Nach dem ich auf 0.5.12 aktualisiert habe, waren wieder alle 
Einstellungen weg. Sogar im ESP musste zunächst das Netzwerk 
eingerichtet werden.
Es ist als 3. Inverter einer fest eingetragen, der sich löschen lässt, 
aber nach reboot wieder da ist. Mqtt Intervall steht auf 0(read only.
Sonst läuft es bis jetzt besser als die 0.5.10.
Kann mir jemand sagen, was die minimalen Limitierungen für den hm-600 
und hm-1500 sind? Oder kann ich beide auf 0 setzen über Mqtt? Ich schon 
öfters von min 10% gelesen ???

[Carsten B. (carstenb)]

Frank L. schrieb:
> Kann mir jemand sagen, was die minimalen Limitierungen für den hm-600
> und hm-1500 sind?

Hallo,

in der Hoymiles-Doku finde ich dazu:

Percentage
2~100 for HM series
10~100 for MI series

Wenn ich über das Webinterface das Limit bei meinem HM600 setze, komme 
ich bei einem Wert von 10 auf etwa 60W Ausgangsleistung. Kann es sein, 
dass die Werte jetzt nicht merh absolut in W sind sondern relativ in %?

Siehe auch: https://github.com/grindylow/ahoy/issues/154

[Jörg R. (rejoe2)]

Ziyat T. schrieb:
> Jörg R. schrieb:
>> Hmm, weiß nicht...
>
>> Die WR ihrerseits haben ein gewisses Beharrungsvermögen auf einem
>> bestimmten Channel und wechseln dann "irgendwann", wenn keine Anfrage
>> kommt.
>
> das wissen wir nicht, weil wir nicht gleichzeitig mehrere ch's hören
> können. wir "beharren" beim hören auf einen kanal, dann sieht es so aus
> als der wr  diesen auch "gut" findet.
Hmmm, also:
Für den MI-600 (und vermutlich alle älteren) bin ich jetzt ziemlich 
sicher, dass der die STS-MSGs über Anfrage-Channel (- 1) bzw. (- 2) 
raushaut, seit der eine ESP den WR auf Kanal 61 festgenagelt hat, hat 
beides funktioniert. Scheinbar ist (- 1) etwas schneller, unklar ist 
noch,
- ob dann auch auf (- 2) (CH23) was zu sehen wäre;
- ob das wechselt (muss das nochmal kritisch beäugen und ggf. auch den 
Empfangskanal nochmal zwischendurch manipulieren?), und woran es liegt, 
dass manchmal (?) eine lange Message kommt und manchmal kein "Paar" zu 
sehen ist, sondern eine einzelne Message - im Moment gehe ich noch von 
Nebenwirkungen des weiteren ESP's aus...
Jedenfalls für den Empfang der "Hauptmessage" darf man den Kanal nicht 
auf was anderem haben als dem der Anfrage.

Damit dürfte zumindest klar sein, warum in den ersten Versionen des 
Sketches für den MI-600 nur so wenige "Treffer" dabei waren, dabei die 
003-er-Messages überwiegt haben und die Timing-Änderung vermeintlich 
eine Besserung gebracht hat - das ganze war schlicht nicht aufeinander 
abgestimmt...

> so wars am anfang, wir hörten nur auf CH3, funktionierte schon, aber
> langsam, damit hatte ich ein problem und zwar:
Das Problem kann ich nachvollziehen, wobei ich gerne verstehen würde, wo 
die Ursache für das Symptom liegt. Wenn es ein starres Verhältnis 
zwischen Sende- und Empfangskanal gibt (was ich zumindest für die alten 
WR vor MI-1500 vermute), könnte das schlicht daran gelegen haben, dass
- der Sendekanal gewechselt hatte, und/oder
- die DTU (schneller) was empfangen hat und dann der WR aufgehört hat zu 
senden (HW-ACK-Auswertung)

> da genügt es nicht (mit 4 PVs), irgendwann zu wissen wieviel der wr
> produziert, ich muss schnell (am besten alle 15 sek) wissen was die pv's
> bringen. darum bin ich aufs "ch hopsen beim rx" umgestiegen, so habe ich
> schneller 4 pv's erfassen können.
Wie gesagt: wenn der wirklich auf einem (vorhersagbaren) anderen Kanal 
zurücksendet als angefragt wird, müßten wir Zeiten deutlich noch unter 
15 Sekunden erzielen können! Wir sollten uns m.E. auch beim Rollieren 
jedenfalls merken, wo der letzte Treffer war und das irgendwie einbauen 
(zumindest in das DEBUG).

Das "Problem" der jetzigen ino ist m.E. noch, dass wir keinerlei Prüfung 
haben, ob die Daten noch aktuell sind. Einmal bei dem MI-600 alle Kanäle 
empfangen ergibt "alle PV's sind da", und zwar soweit erkennbar auch 
noch am nächsten Tag usw....

In diesem Zusammenhang bin ich dann noch über diesen Beitrag gestolpert:

Stefan T. schrieb:
> Hallo Zusammen,
>
> der RECV_CHANNEL 0x61 ist m.W. der mit dem er loslegt. Es wurde bei
> ersten Tests herausgefunden, dass bei TX auf Kanal 0x61 die nächste
> Antwort auf Kanal 0x03 relativ gut empfange wurde, d.h. zwei Kanäle
> Unterschied. Ob das am Timing zwischen Senden und Empfangsbereitschaft
> des Ahoy DTU Codes ist, oder etwas anderes weiß ich nicht.

Alles in allen wird mir nun auch klar, warum wir mit der "Hopserei" und 
deren Notwendigkeit so aneinander vorbei geredet haben und/oder es User 
gibt, die teils über sehr lange Synchronisierungszeiten klagen: Alles 
vor MI-1500 tickt an der Stelle wohl wirklich komplett anders - und ich 
sehe auch keinen großen Sinn darin, den Code-Ablauf groß anders zu 
gestalten wie "Merke dir den aktuellen Sende-Channel, hau reichtzeitig 
Anfragen drüber. Schalte nach dem Senden direkt den Empfangskanal 
'zurück' und direkt auch wieder hoch, sobald da was gekommen ist (oder 
zu lange nichts)".
Damit bekommt man ziemlich sicher punktgenau einen aktuellen und 
konsistenten Satz Infos vom WR.

Bleibt die Frage, wie man das ggf. auf den MI-1500 (und später?) 
übertragen kann, v.a. auch, um die Synchronisierungszeiten zu 
verbessern...
Auch bei den neueren Modellen würde es mAn. Sinn machen, sich den 
aktuellen "besten Empfangskanal" zu merken (und dann "erst mal" den 
anzufahren?). Die Frage wäre, ob das auch (-1) bzw. (-2) wäre, und ggf. 
nach welcher Logik was anderes auszuwählen wäre...

Wie arbeitest du denn grade sendeseitig? Ist das auch rollierend oder 
irgendwie festgezurrt?

[Ralla66 (Gast)]

Zufälliges Channel hopping eher weniger, wohl ein Algo aus bester 
Signalstärke pro Channel und gültiger CRC das die DTU auswertet.

[Jörg R. (rejoe2)]

Ralla66 schrieb:
> Zufälliges Channel hopping eher weniger, wohl ein Algo aus bester
> Signalstärke pro Channel und gültiger CRC das die DTU auswertet.
Muss darüber nochmal nachdenken, aber zum Thema "Signalstärke" eine 
kurze Rückfrage: Üblicherweise wird ja sowas als RSSI angegeben. Jetzt 
ist mir aus der MySensors-nRF-Ecke noch im Ohr, dass das die nRF-Chips 
nicht unterstützen und man bei MySensors daher auf die entsprechende 
Debug-Anfrage auch "nur" sowas bekommt wie einen Pseudo-RSSI (wie auch 
immer der gebildet wurde).

Als Indikator würde ich sehen:
- Zahl der Retry's, bis ein Hardware-Ack kommt (da muss afaik der CRC 
passen)
- ob überhaupt eines kommt
- (zuletzt)
-- Zeit, bis eine Antwort kommt (je kürzer, desto besser)
-- Verhältnis der Messages mit gültigem CRC / Gesamtzahl von einer 
Gegenstelle (kann sein, dass das die MySensors-Lösung ist).
-- das ganze ggf. unter Berücksichtigung der Frage, wie starkt ggf. der 
Anfragende (ESP) sowie die Gegenseite ausgelastet ist (Zusammenstellen 
von Daten).
Oder kennt ihr noch weitere Indikatoren?

Habe wg. des Frequenz-Wechsel-Themas nochmal das sniffer-log aus 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 
angesehen. Danach sieht das so aus, als würden zumindest manche der 
Anfragen auch noch innerhalb dieses Zykluses auf derselben Frequenz 
beantwortet - warum auch immer das grade dann da so ist (mir fehlen 
irgendwie da Zeitstempel-Infos, und was z.b. (27/0/0) bedeuten soll, 
müßte ich auch erst mal nachlesen). Das sieht jedenfalls nicht unbedingt 
danach aus, als müßte man bei dem MI-1500 die Sende- und 
Empfangsfrequenz entkoppeln, und auch die "fehlenden" Antworten aus 
diesem Zyklus kommen dann in den folgenden Nachrichten auf dem nächsten 
Kanal?
Folgt das der Logik: Wenn du eine erhaltene Anfrage nicht mehr zustellen 
kannst, speichere sie und sende das dann auf dem nächsten Kanal? (Weil 
die DTU weitergezogen ist?).

[Ralla66 (Gast)]

Signalstärke wäre ja wichtig, wo wenig Signal oder gar keins da liegt ja 
nahe das die Daten falsch sind oder nicht vorhanden.Gefiltert nach den 
20 Signalstärksten wäre gut. Danach diese 20 gefilterten auf gültige CRC 
prüfen.
Die besten 8 abspeichern. Danach wieder von vorne.
Ich lese mal das Datasheet vom NRF, das muß doch gehen mit der 
Signalstärke, Krücke würde ja reichen.

[Jörg R. (rejoe2)]

Anbei eine weitere Iteration des Sketches für MI-xxx - "nicht zum 
Verzehr geeignet" (da ist noch ein größerer Bug drin, aber die ersten 
paar Ausgaben bis zum unbeabsichtigten "Dauerfeuer" sind trotzdem sehr 
aufschlussreich)...

CH40 00 1234567801 0086 10 3  88 60100013 60100013 0003000000008BB641 1
24382 CH:40: MI300/MI600 status message
CH61 00 1234567801 00C0 18 0  89 60100013 60100013 0143000C091A1380018E057E00F645D490 1
24430 CH:61 PV0 MI:  39W Grd: 730W Lm:   0W 39.8W 32.3V 1.2A 1406Wh 233.0ACV 49.9Hz 24.6C S:3 
24433 Send... CH61 116010001378563412007A24438
.....send res 0
backchannel timed out...
24868 Send... CH61 116010001378563412007A24869
.....send res 0
25098 Send... CH61 116010001378563412007A25099
.....send res 0
backchannel timed out...
25528 Send... CH61 116010001378563412007A25529
.....send res 0
CH40 00 1234567801 0082 10 1  92 60100013 60100013 000300000000913454 1
25562 CH:40: MI300/MI600 status message
25758 Send... CH61 116010001378563412007A25759
.....send res 0
25988 Send... CH61 116010001378563412007A25989
.....send res 0
CH40 00 1234567801 0084 10 2  92 60100013 60100013 000300000000915618 1
26022 CH:40: MI300/MI600 status message
CH61 00 1234567801 00C6 18 3  91 60100013 60100013 0142000C09181380018D058100F6A21C02 1
26064 CH:61 PV1 MI:  79W Grd: 730W Lm:   0W 39.7W 32.2V 1.2A 1409Wh 232.8ACV 49.9Hz 24.6C S:3 
CH61 00 1234567801 00C4 18 2  91 60100013 60100013 0142000C091C1380018F058100F7A5F2C9 1
34519 CH:61 PV1 MI:  79W Grd: 730W Lm:   0W 39.9W 32.2V 1.2A 1409Wh 233.2ACV 49.9Hz 24.7C S:3 
CH61 00 1234567801 00C6 18 3  89 60100013 60100013 0143000C091E13810190057E00F75FA982 1
39526 CH:61 PV0 MI:  79W Grd: 730W Lm:   0W 40.0W 32.3V 1.2A 1406Wh 233.4ACV 49.9Hz 24.7C S:3 
CH61 00 1234567801 00C6 18 3  91 60100013 60100013 0142000C091C137B0192058100F7432BAC 1
49616 CH:61 PV1 MI:  80W Grd: 730W Lm:   0W 40.2W 32.2V 1.2A 1409Wh 233.2ACV 49.9Hz 24.7C S:3 
50001 Send... CH61 116010001378563412007A50002

[Ralla66 (Gast)]

Zitat:
There is an RSSI register in nRF24L01+, the address is 0x09, the 0th bit 
of this register represents the current channel signal strength. When 
the received signal strength is less than -60dBm, bit 0 is 0, when it is 
greater than -60dBm it is 1.
Ch die nicht / wenig senden können so gefunden werden, die am meisten 
senden CRC prüfen.So der Gedanke.

[Jörg R. (rejoe2)]

Vielleicht gefunden, warum dann keine Pause mehr war, nachdem der erste 
"Satz" komplett war...

[Jörg R. (rejoe2)]

Jörg R. schrieb:
> Vielleicht gefunden, warum dann keine Pause mehr war, nachdem der erste
> "Satz" komplett war...
Eher nicht, das war jedenfalls nicht alles gewesen.

Hatte gestern dann noch lange vor Sonnenuntergang beide ESP abgeklemmt.

Einer der Startvorgänge von heute morgen:

SerialIn: 4 Cmd:4
33823 Send... CH23 096010001378563412006233825
.....send res 0
34054 Send... CH40 096010001378563412006234055
.....send res 0
34284 Send... CH61 096010001378563412006234285
.....send res 0
34514 Send... CH75 096010001378563412006234515
.....send res 0
backchannel timed out...
34944 Send... CH03 096010001378563412006234945
.....send res 0
35174 Send... CH23 096010001378563412006235175
.....send res 0
backchannel timed out...
35604 Send... CH40 096010001378563412006235605
.....send res 0
backchannel timed out...
36034 Send... CH61 096010001378563412006236035
.....send res 0
backchannel timed out...
36464 Send... CH75 096010001378563412006236465
.....send res 0
backchannel timed out...
36894 Send... CH03 096010001378563412006236895
.....send res 0
backchannel timed out...
37324 Send... CH23 096010001378563412006237325
.....send res 0
37554 Send... CH40 096010001378563412006237555
.....send res 0
CH40 00 1234567801 0084 10 2  88 60100013 60100013 0003000000008B9785 1
37587 CH:40: MI300/MI600 status message
CH61 00 1234567801 00C6 18 3  89 60100013 60100013 00BA000208FD13860029000000BAC24075 1
37639 CH:61 PV0 MI:   4W Grd:  50W Lm:   0W  4.1W 18.6V 0.2A    0Wh 230.1ACV 50.0Hz 18.6C S:3 
37642 Send... CH61 116010001378563412007A37647
.....send res 0
backchannel timed out...
38076 Send... CH61 116010001378563412007A38077
.....send res 0
backchannel timed out...
38506 Send... CH61 116010001378563412007A38507
.....send res 0
38736 Send... CH61 116010001378563412007A38737
.....send res 0
38966 Send... CH61 116010001378563412007A38967
.....send res 0
CH40 00 1234567801 0080 10 0  92 60100013 60100013 000300000000911590 1
39000 CH:40: MI300/MI600 status message
CH61 00 1234567801 00C2 18 1  91 60100013 60100013 00E7000208FE13860030000000BA9D66BA 1
39040 CH:61 PV1 MI:   8W Grd:  50W Lm:   0W  4.8W 23.1V 0.2A    0Wh 230.2ACV 50.0Hz 18.6C S:3

[Frank L. (guilligan)]

0.5.12. #40 super Entwicklung.
Mir ist aufgefallen, dass beim HM-600 unterhalb von 90Watt die 
Produktion fast immer 10watt unter der Limitierung liegt.
Hat jemand gleiches beobachtet?

[Andreas (dicc)]

Moin,
super Projekt!
Was mir hier fehlt, oder ich finde es nicht, ist eine Zusammenstellung 
aller benötigter Komponeten und Software mit welcher z.B. der ESP 
gefasht wird! ich hab in der Vergangenheit mit der Arduino Software 
gearbeitet das denke ich geht hier nicht! Bin kein kompleter Leihe aber 
ich will halt das meinen WR ans laufen bringen (überwachen)!
Eine Schritt für Schritt Anleitung für "Halbdummies" fände ich super!

Ansonsten super Arbeit!

Grüsse
Andreas

[Simon S (Gast)]

Woran kann es liegen dass sich der ESP nicht mit dem WLAN verbinden will 
und jedes Mal nach einem Neustart die Konfiguration verwirft?

Habe immer das neuste Release 
(https://github.com/grindylow/ahoy/actions) auf einen Wemos D1 Mini 
geflasht.

Auch wenn ich die config.h anpasse um die SSID / Passwort festzulegen 
kappt es nicht wirklich und es kommt zu einem Bootloop.

[Ha F. (harry_f)]

Simon S schrieb:
> Woran kann es liegen dass sich der ESP nicht mit dem WLAN
> verbinden will
> und jedes Mal nach einem Neustart die Konfiguration verwirft?
>
> Habe immer das neuste Release
> (https://github.com/grindylow/ahoy/actions) auf einen Wemos D1 Mini
> geflasht.
>
> Auch wenn ich die config.h anpasse um die SSID / Passwort festzulegen
> kappt es nicht wirklich und es kommt zu einem Bootloop.

Wie sieht die Stromversorgung aus?
Vom PC aus über USB-Port?
Über ein Netzteil? Evlt zu schwach?

Auch mal nur den nackten D1 Mini getestet ohne Anbauteile?

[Ha F. (harry_f)]

Andreas schrieb:
> Moin,
> super Projekt!
> Was mir hier fehlt, oder ich finde es nicht, ist eine Zusammenstellung
> aller benötigter Komponeten und Software mit welcher z.B. der ESP
> gefasht wird! ich hab in der Vergangenheit mit der Arduino Software
> gearbeitet das denke ich geht hier nicht! Bin kein kompleter Leihe aber
> ich will halt das meinen WR ans laufen bringen (überwachen)!
> Eine Schritt für Schritt Anleitung für "Halbdummies" fände ich super!
>
> Ansonsten super Arbeit!
>
> Grüsse
> Andreas

- für das erste mal flashen zB mit: 
https://github.com/tasmota/tasmotizer/releases
später über OTA:  IP/update
- das bin-File von hier https://github.com/grindylow/ahoy/actions
- danach neu starten, mit dem WLAN des ESP verbinden und im WebIf 
einrichten.

[Jörg R. (rejoe2)]

Das "Gehopse" und manche Zufälligkeiten (warum scheint meiner den Kanal 
0x61 so zu mögen?!?) lassen mich nicht so richtig in Ruhe - und siehe 
da, in 
https://www.mikrocontroller.net/attachment/559626/Micro-inverse_system_related_product_ID_coding_rules-A3-20190712.docx 
steht ziemlich am Anfang was interessantes. Es gibt nicht nur Geräte, 
die explizit als Repeater eingesetzt werden können, sondern für DTU's, 
Repeater und WR gilt:
>The "8~12" bits are the pipeline coding (currently in decimal), the 
micro-inverter, repeater, and DTU share the same pipeline sequence, which is coded 
in sequence and must not be repeated, a total of 99999 bits.
Hmmm, ist etwas kryptisch, aber es klingt jedenfalls danach, als sei 
eine bestimmte Kombination der letzten 5 Ziffern der Seriennummern der 
beteiligten Geräten dafür ausschlaggebend, wann (im Sinne einer 
Zeitscheibe?) und auf welchem Kanal (?) ein Gerät Nachrichten versendet 
bzw. empfängt.

Eventuell hat hoymiles da auch irgendwann das Konzept dazu geändert?

Na ja, wie dem auch sei, in hmDefines.h gibt es z.B. hm1chAssignment[], 
und danach scheint die Zuordnung bestimmter Infos zu bestimmten Kanälen 
fest zu sein?

Das würde auf den MI-600 nur eingeschränkt passen, wie gesehen wäre es 
optimal, wenn
a) der (aktuell) richtige Sendekanal für den MI bekannt ist, und
b) der RX-Kanal noch für kurze Zeit (50-100ms?) auf dem davor liegenden 
Kanal (?) verbleibt und danach auch auf den aktuellen TX-Kanal 
umgeschaltet wird.
Wie das zeitlich in der app.cpp eingetacktet ist: noch k.A..

Zu den aktuellen Punkten auf der Roadmap:
>app.cpp aufräumen und in hmRadio / hmProtokollGen3 auslagern
In hmRadio gibt es derzeit die Funktion "sendPacket". Kommt mir aus der 
"kleinen ino" bekannt vor, stellt aber ihrerseits dann auch den Sende- 
und Empfangskanal um. Irgendwie müßten wir für den Fall der Koexistenz 
von verschiedenen Typen dafür sorgen, dass es zusammenpaßt, was da 
passiert....

Einen Wunsch hätte ich noch für die 0.6-er Roadmap: Die kompletten 
Ergebnisse dann in json zu verpacken (gerne optional).

Ich werde jetzt erst mal versuchen, eine etwas generalisierte Fassung 
der "kleinen ino" für MI zu bauen, die man dann ggf. auch als separates 
Tool anbieten kann? Vielleicht meldet sich ja doch noch jemand, der ein 
etwas abweichendes setup hat als Ziyat T und ich...
Oder bestehen da prinzipielle Einwände?

[Simon S (Gast)]

Ha F. schrieb:
> Simon S schrieb:
>
>> Woran kann es liegen dass sich der ESP nicht mit dem WLAN
>> verbinden will
>> und jedes Mal nach einem Neustart die Konfiguration verwirft?
>> Habe immer das neuste Release
>> (https://github.com/grindylow/ahoy/actions) auf einen Wemos D1 Mini
>> geflasht.
>> Auch wenn ich die config.h anpasse um die SSID / Passwort festzulegen
>> kappt es nicht wirklich und es kommt zu einem Bootloop.
>
> Wie sieht die Stromversorgung aus?
> Vom PC aus über USB-Port?
> Über ein Netzteil? Evlt zu schwach?
> Auch mal nur den nackten D1 Mini getestet ohne Anbauteile?

Sowohl USB am PC, als auch mit eigenem Netzteil.
Sowie mit und ohne Anbauteile.
Werde mal das letzte Debug Build flashen und schauen ob ich so mehr 
Informationen auslesen kann.

[Simon S (Gast)]

> für das erste mal flashen zB mit:
> https://github.com/tasmota/tasmotizer/releases
> später über OTA:  IP/update
> das bin-File von hier https://github.com/grindylow/ahoy/actions
> danach neu starten, mit dem WLAN des ESP verbinden und im WebIf
> einrichten.

Genau so hab ich es auch gemacht, doch leider verwirft er bei mir immer 
die WLAN Konfiguration

[Hfhausen (Gast)]

Jörg R. schrieb:
> Einen Wunsch hätte ich noch für die 0.6-er Roadmap: Die kompletten
> Ergebnisse dann in json zu verpacken (gerne optional).

IP/json sollte schon vieles liefern.

[Carsten B. (carstenb)]

Frank L. schrieb:
> 0.5.12. #40 super Entwicklung.
> Mir ist aufgefallen, dass beim HM-600 unterhalb von 90Watt die
> Produktion fast immer 10watt unter der Limitierung liegt.
> Hat jemand gleiches beobachtet?

Hallo,

ich habe mir grade die 5.13 installliert. Da hat sich beim Limit noch 
ganz vie lgetan (danke an alle für die tolle Weiterentwicklung!).

Ich werde morgen (das Wetter scheint ja ok zu werden) ausgiebig mit den 
Limits testen und berichten.

Carsten

[Ralla66 (Gast)]

Dann müsste ja
WRSer in dec 6 77 21
ESP Dtu      4 56 78
ergibt Ch    3 23 40 61 75
wobei ja DTU fest ist und die CH immer ähnlich sind bei HM600.

[Andreas S. (drschiffler)]

Carsten B. schrieb:
> Frank L. schrieb:
>> 0.5.12. #40 super Entwicklung.
>> Mir ist aufgefallen, dass beim HM-600 unterhalb von 90Watt die
>> Produktion fast immer 10watt unter der Limitierung liegt.
>> Hat jemand gleiches beobachtet?
>
> Hallo,
>
> ich habe mir grade die 5.13 installliert. Da hat sich beim Limit noch
> ganz vie lgetan (danke an alle für die tolle Weiterentwicklung!).
>
> Ich werde morgen (das Wetter scheint ja ok zu werden) ausgiebig mit den
> Limits testen und berichten.
>
> Carsten
Hallo Carsten,

danke für die Bereitschaft zu testen.
Nimm bitte die Version von hier:
https://github.com/aschiffler/ahoy/actions/runs/2869788679

Ist auch 0.5.13 nur hier habe ich noch eine kleine Verbesserung für MQTT 
einbauen müssen. Nach den Tests -- ca. 2-3 User wollen testen -- werden 
wir auf dem main dann ein neues Release bereitstellen inklusive pot. 
fixes.
Siehe auch als Anleitung:
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/User_Manual.md

[Simon S (Gast)]

Simon S schrieb:
> Woran kann es liegen dass sich der ESP nicht mit dem WLAN
> verbinden will und jedes Mal nach einem Neustart die Konfiguration
> verwirft?
> Habe immer das neuste Release
> (https://github.com/grindylow/ahoy/actions) auf einen Wemos D1 Mini
> geflasht.
> Auch wenn ich die config.h anpasse um die SSID / Passwort festzulegen
> kappt es nicht wirklich und es kommt zu einem Bootloop.

Lag wohl ab einem defekten Wemos D1 mini, hatte noch einen anderen auf 
dem es jetzt problemlos funktioniert.

[Dirk S. (fusebit)]

Moin,

ich habe gerade von 5.10 auf 5.13 ein OTA Update gemacht.
Danach hat sich der ESP wieder als AP gemeldet, aber keine 
Konfigurationsseite geöffnet.
Nachdem ich über USB wieder auf 5.10 gewechselt habe lief es sofort 
wieder im normalen Modus (hat also die WLAN Info im EEPROM gefunden).

5.13 funktioniert auch nicht, wenn ich es über USB einspiele.

[Jörg R. (rejoe2)]

Hfhausen schrieb:
> Jörg R. schrieb:
>> Einen Wunsch hätte ich noch für die 0.6-er Roadmap: Die kompletten
>> Ergebnisse dann in json zu verpacken (gerne optional).
>
> IP/json sollte schon vieles liefern.
Zum einen spiele ich grade noch mit "der kleinen ino" rum und sehe im 
Moment nur, was andere User an Topics (automatisch) abbonniert haben. Da 
war dieser Topic jedenfalls bislang gar nicht zu sehen.
Zum anderen war ich etwas unpräzise: Wünschen würde ich mit je getrennte 
Topics für
- den ESP an sich (obiger tree?)
- jeden WR (uU. noch getrennt nach AC+jedem DC-Eingang, aber in jedem 
Fall unter einem Sub-Topic, der dem WR zugeordnet ist)

Klasse wäre auch, wenn "signifikante Änderungen" (auf Bestellung?) vor 
Ablauf der normalen Periode gemeldet würden (Ausfall eines Eingangs oder 
von AC, Änderungen über z.B. 10% der Leistung oder 15/20W etc. tb. 
discussed).

Ralla66 schrieb:
> Dann müsste ja
> WRSer in dec 6 77 21
> ESP Dtu      4 56 78
> ergibt Ch    3 23 40 61 75
> wobei ja DTU fest ist und die CH immer ähnlich sind bei HM600.
Eine klare Logik kann ich hinter den Zahlen (auch mit meiner WR-Nummer) 
nicht erkennen. Beim Durchflözen der Rückmeldungen hier ist nur eben 
auffällig, dass viele sehr zufrieden sind, es bei manchen "ewig" 
braucht, bis eine Synchronisation da ist und wieder andere anscheinend 
gar keine Daten bekommen - warum auch immer.

Jedenfall habe ich heute nacht mal den WR auch von AC genommen. Damit 
sollte der "resettet" sein? Dann lief er eine Weile, bevor dann einer 
meiner Versuchs-Codes "randurfte". Im Ergebnis wollten sich beide dann 
wieder auf Kanal 0x61 einigen. ABER: zwischendurch kam auch über CH40 
eine 0x91-er Message rein. Interessant dabei ist, dass der Code zu 
diesem Zeitpunkt ausschließlich auf Kanal 0x61 sendete, der WR also 
vielleicht noch versucht hat, die Status-Messages 0x88 und 0x92 
zuzustellen? Und die Daten bereits aufbereitet hatte für den Fall, dass 
der ESP empfangsbereit ist?
(oder meine ausgegebenen Infos irgendwie unsauber sind...)

Na ja, wie dem auch sei, werde jetzt auch versuchsweise wieder zu 
starren Tick-Zeiten zurückgehen und den Empfangskanal "hart" an den 
Sendekanal binden (-1). Kommt dann die 89 Antwort im Zeithorizont von 
"senden+200" bis "senden+400" (oder ein HW-Ack), ist das der "richtige 
Channel" und künftige Sendungen sollten dann (erst mal nur) über diesen 
Kanal rausgehen - also muss bei "isTime2Send()" zusätzlich noch geprüft 
werden, ob wir auf der passenden "Zeitscheibe" sind und die bei "bisher 
Fehlanzeige" dann auch gewechselt werden.
Mal schauen.

[Ralla66 (Gast)]

Die Channels werden ja im Register Map Table Adresse 05 Bit 0 - 6 
geschrieben oder gelesen.
Könnte mir vorstellen das jede Pipe einen eigenen Channel bekommt für WR 
bezogene Daten.Eben errechnet aus den Serial IDs der DTU und WR.Dann 
wäre die Channel Number in den Daten der Pipe zu suchen und zum Senden 
vermutlich am Anfang gesetzt.

[Frank L. (guilligan)]

Kennt jemand den mqqt Befehl um das aktuell gesetzte limit auszulesen 
bzw. wird das gesendet und man kann es über ein subscribe verwenden?

[Jörg R. (rejoe2)]

Ralla66 schrieb:
> Die Channels werden ja im Register Map Table Adresse 05 Bit 0 - 6
> geschrieben oder gelesen.
> Könnte mir vorstellen das jede Pipe einen eigenen Channel bekommt für WR
> bezogene Daten.Eben errechnet aus den Serial IDs der DTU und WR.Dann
> wäre die Channel Number in den Daten der Pipe zu suchen und zum Senden
> vermutlich am Anfang gesetzt.

MAn. ist aus WR-Sicht eher die Frage des "optimalen Empfangs" relevant.

Ein nRF kann nach meinem laienhaften Verständnis (zu einem bestimmten 
Zeitpunkt) immer nur
- entweder Senden oder Empfangen, und das ganze
- immer nur auf genau einem Kanal

Da der Aufwand für eine eigene (exakte) Uhr auf jedem WR vermutlich viel 
zu groß ist, fangen die bei jedem DC-Zyklus (näherungsweise) bei "0" an. 
Was sie wissen, ist
- die eigene Nr.
- (vielleicht) den letzten Kanal, auf dem sie angefunkt wurden, und
- bestenfalls (!) die ID ihrer Gegenstelle, also (Repeater oder) DTU.

Ergo müßte es eigentlich das einfachste sein, die Dinger schlicht auf 
"ihrem Kanal" auf die Lauer zu legen und auf Signale zu warten. 
Vielleicht mal Wechseln, wenn zu lange nichts kommt. Das würde dann 
bedeuten: etwas mehr wie eine Sekunde (=1 DTU-Zyklus?) auf einen anderen 
Kanal wechseln, dort lauschen, dann wieder zurück, ebenfalls für mind. 
einen Zyklus, dann wieder den nächsten.
Eine eventuelle Antwort dann "rückwärts" auf dem vorherigen Kanal 
versenden, in der Erwartung, dass die DTU genau dort lauscht, bei 
"Unzustellbarkeit" dann die Kanäle wechseln (seltsamerweise scheint mein 
MI noch einen Kanal weiter zurück zu gehen, wenn er die Status-Message 
nicht an den Mann bringt? Der WR war dann aber nach etwas weniger als 
200ms wieder auf dem Hauptkanal, um die Hauptinfo zu versenden). Wenn 
die Zustellung klappt, wird ggf. die folgende Message (in etwa) "im Takt 
mit den Kanalwechseln" dann auch versendet?
Der "eigene Kanal" bleibt bei Versandproblemen nach dem 1. Zyklus frei, 
damit der WR hier auf weitere Anweisungen lauschen kann?

"Zuzuhören" scheint (!) mein MI jedenfalls mehr oder weniger 
ausschließlich auf Kanal 0x61... (wenn ich dran denke, wird dieser Kanal 
mal aus der Liste genommen, mal sehen, ob (und ggf. wie/wo/wann) dann 
eine Kommunikation zustande kommt; aber erst muss der Code ohne solche 
Spielereien erst mal so laufen wie gedacht...).

[Marcel S. (marcel_s750)]

Hallo,

erstmal vielen Dank für das coole Projekt!

An die iobroker-User unter uns, ich würde gerne das nicht-persistente 
Powerlimit per MQTT setzen, dazu habe ich den Datenpunkt angelegt (und 
siehe Bild), nach den Kriterien, wie sieh hier hinterlegt sind: 
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/User_Manual.md

"mqtt.0.Ahoy.devcontrol.114172608859.11.0"

Leider passiert in Ahoy gar nichts :-( wie habt ihr den Datenpunkt 
angelegt?

Danke schon mal!

Marcel

[Rene M. (Firma: Bitte wählen) (renmo)]

@Marcel
du musst auch
mqtt.0.Ahoy.devcontrol.0.11
nehmen.

[Marcel S. (Gast)]

Rene M. schrieb:
> @Marcel
> du musst auch
> mqtt.0.Ahoy.devcontrol.0.11
> nehmen.

Hmm, dann ist die Anleitung falsch. Hab es gerade ausprobiert, 
funktioniert aber leider auch nicht, sondern führt genau wie die andere 
Variante direkt zu einem reboot.
Welche Version hast du denn installiert? Hab die 0.5.14

[Ralla66 (Gast)]

An Jörg R.
Sehe ich ähnlich, aus der Spec vom NRF geht ja hervor das zwischen RX 
und TX gezielt geschaltet werden kann. Eine gute Verbindung wird ja bei 
RX in RDP 09 gesetzt. Ein Register für Ch habe ich in der Spec nicht 
gefunden. Dann wäre die einfachste Variante den CH mit zu senden im 
ersten Paket bei der Kontaktaufnahme zwischen den Teilnehmern.

[Sigi S. (sermon)]

Hallo,

ich habe 2 neue AZ-Delivery NodeMCU LolinV3 probiert.
Prozessor ESP8266MOD, Modell 12-F.

Compiliert ohne Fehler mit folgenden Settings:

platform = espressif8266
framework = arduino
board = esp12f
board_build.f_cpu = 80000000L
upload_port = COM5

Upload auch ohne Probleme.


Leider spannt er kein eigenes WLAN auf.

Version ist von letzter Woche.

Hat jemand einen Hinweis für mich?
Danke
Achso auf der Seriellen Schnittstelle empfange ich nur Schmierzeichen 
mit 115200 Baud

[Sigi S. (sermon)]

Sigi S. schrieb:
> Hallo,
>
> ich habe 2 neue AZ-Delivery NodeMCU LolinV3 probiert.
> Prozessor ESP8266MOD, Modell 12-F.
>
> Compiliert ohne Fehler mit folgenden Settings:
>
> platform = espressif8266
> framework = arduino
> board = esp12f
> board_build.f_cpu = 80000000L
> upload_port = COM5
>
> Upload auch ohne Probleme.
>
> Leider spannt er kein eigenes WLAN auf.
>
> Version ist von letzter Woche.
>
> Hat jemand einen Hinweis für mich?
> Danke
> Achso auf der Seriellen Schnittstelle empfange ich nur Schmierzeichen
> mit 115200 Baud

Hallo,

mit einem NodeMCU Flasher von:

This programmer can flash esp8266 by one click.
Our website is http://www.nodemcu.com
Our Tencent QQ Group:309957875

wird eine FW geflashed und es funktioniert so weit.
(Warum tut Platformio als hätte alles geklappt?!)

In der neuen GUI sehe ich kein Feld um meinen WR Typ HM1500 einzutragen.
Die Hinweise hier im Forum klären das auch nicht eindeutig.

Wo muß der Typ eingetragen werden???

[Rene M. (Firma: Bitte wählen) (renmo)]

@Marcel
sollte schon klappen.
Sieh dir einmal meinen Screenshot an.
Klappt schon seit 0.0.8 oder so.

[Carsten (Gast)]

Andreas S. schrieb:
> Hallo Carsten,
>
> danke für die Bereitschaft zu testen.
> Nimm bitte die Version von hier:
> https://github.com/aschiffler/ahoy/actions/runs/2869788679
Hallo,

leider hat moch die Arbeit heute etwas mehr in Anspruch genommen, als 
gedacht. Ich habe nicht mehr geschafft abzudaten, habe aber mit der 5.13 
getest, die ich schon dauf hatte.

Hat sich alles plausibel verhalten. Habe jeweils über das Webinterface 
"absolute watt in non-persitant" gesetzt:

gesetzt 10W, WR:13W, shelly:9W 
gesetzt 20W, WR:24W, shelly:19W
gesetzt 50W, WR:48W, shelly:43W
gesetzt 100W, WR:103-108W, shelly:98-103W
gesetzt 150W, WR:152-157W, shelly:152-157W  
gesetzt 200W, WR:201-206W, shelly:201W 
gesetzt 300W, WR:310W max, shelly:max 305W 
gesetzt relativ in procent persistent: 100% WR: max 561W, shelly: max 553W

Angehängt noch die Graphen aus fhem dazu. Für mich ist das ein sehr 
ordentliches Ergebnis :-)

Gruß

Carsten

PS: ich hatte mehrere Reboots den Tag über. Mit 5.1 lief es mehrere Tag 
durch...

PPS: ich habe leider keine serielle Console dran, da aus Empfangsgründen 
die DTU draussen am Gartenhaus hängt. Ich versuche spätestens am 
Wochende dafür eine Lösung zu finden (2. ESP mit seriell nach ssh o.ä.)

[Christian E. (christian_e775)]

Falls jemand die Daten direkt mit einem RaspberryPi auslesen und an den 
Volkszähler schicken will: https://github.com/stefan123t/ahoy/pull/3
Ggf. an einigen Stellen noch nicht schön aber funktioniert erstmal so.

[Sigi S. (sermon)]

number of supported inverters (set to 3 by default) defines.h

Ist in defines.h nicht zu finden.

Wo dann?

[Carsten (Gast)]

config.h, Zeile 46:

// number of configurable inverters
#define MAX_NUM_INVERTERS       3

[Sigi S. (sermon)]

Sigi S. schrieb:
> number of supported inverters (set to 3 by default) defines.h
>
> Ist in defines.h nicht zu finden.
>
> Wo dann?

JA, Danke!!!

[Marcel S. (Gast)]

Ich muss noch mal nachfragen, wie genau du es machst, weil es bei mir 
einfach nicht klappen will.
Ich nutze den mqtt Adapter (nicht den mqtt-Client, könnte das ein Fehler 
sein).
Ich habe mir analog zu dir diesen Datenpunkt manuell erstellt:
mqtt.0.Ahoy.devcontrol.0.11
Die Ordner habe ich als folder deklariert.
Gesendet habe ich dann die Werte als string und number, beides ohne 
Erfolg.
Wo kann ich ansetzen?

[Dirk S. (fusebit)]

Bei mir läuft die 5.10 schön stabil, aber ich bekomme weiterhin keine 
höhere Version zum laufen.

Habe mir nun extra noch ein zweites Testsystem gebaut und verschiedene 
Varianten ausprobiert. Direktes flashen mit ESP8266flasher oder OTA von 
5.10 aus, auch mit komplett gelöschten ESP getestet.
Aber alle Versionen >5.10 melden sich zwar als AP, aber es öffnet sich 
keine Anmeldeseite für das Setup. Die WiFi Konfiguration wird auch nicht 
übernommen, wenn vorher 5.10 lief. Sobald ich auf 5.10 zurückgehe 
funktioniert es wieder.

[Sorbit (Gast)]

Dirk S. schrieb:
> Bei mir läuft die 5.10 schön stabil, aber ich bekomme weiterhin
> keine
> höhere Version zum laufen.
>
> Habe mir nun extra noch ein zweites Testsystem gebaut und verschiedene
> Varianten ausprobiert. Direktes flashen mit ESP8266flasher oder OTA von
> 5.10 aus, auch mit komplett gelöschten ESP getestet.
> Aber alle Versionen >5.10 melden sich zwar als AP, aber es öffnet sich
> keine Anmeldeseite für das Setup. Die WiFi Konfiguration wird auch nicht
> übernommen, wenn vorher 5.10 lief. Sobald ich auf 5.10 zurückgehe
> funktioniert es wieder.

Ich kann bestätigen, das auch die aktuellen Versionen bei mir 
einwandfrei laufen. Mit WEMOS, und auch Nodemcu v3 clones…

[Ha F. (harry_f)]

Marcel S. schrieb:
> Ich muss noch mal nachfragen, wie genau du es machst, weil es bei
> mir
> einfach nicht klappen will.
> Ich nutze den mqtt Adapter (nicht den mqtt-Client, könnte das ein Fehler
> sein).
> Ich habe mir analog zu dir diesen Datenpunkt manuell erstellt:
> mqtt.0.Ahoy.devcontrol.0.11
> Die Ordner habe ich als folder deklariert.
> Gesendet habe ich dann die Werte als string und number, beides ohne
> Erfolg.
> Wo kann ich ansetzen?

Im Einsatz: 0.5.14
Iobroker mit MQTT-Adapter als Server, allerdings auf Port 1881, da noch 
ein Sonoff-Adapter läuft.

ich schreibe Werte nach (als String):
mqtt.0.inverter.devcontrol.0.11

inverter  ist das MQTT-Topic aus der Configseite

[Dirk S. (fusebit)]

Sorbit schrieb:
> Ich kann bestätigen, das auch die aktuellen Versionen bei mir
> einwandfrei laufen. Mit WEMOS, und auch Nodemcu v3 clones…

Moin,

hast Du die bin von GitHub genommen, oder selbst kompiliert?
Wie hast Du sie aufgespielt:
- direkt auf leeren ESP geflasht?
- OTA von vorheriger Version?
- neue Version über vorherige geflasht?

Irgendetwas mache ich wohl falsch, aber was kann es bloß sein?