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
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.
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
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!
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:
1
17 MI600
2
Send... CH61 11601000132143658700F2.....send res 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
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!!!
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?
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...
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?
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).
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
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 ?
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.
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:
1
DEBUG_RCV_DATA 1
2
DEBUG_TX_DATA 1
3
PA_LEVEL 2
4
WITHWIFI 0
5
ZEROEXP 0
6
INTERRUPT 0
7
SNIFFER 0
8
ONLY_RX 0
9
CHECK_CRC 0
10
11
SerialIn: 2 Cmd:2
12
9 MI600
13
Send... CH23 0960100013785634120062.....send res 0
14
17 MI600
15
Send... CH40 116010001378563412007A.....send res 0
16
9 MI600
17
Send... CH61 0960100013785634120062.....send res 1
18
17 MI600
19
Send... CH75 116010001378563412007A.....send res 0
20
9 MI600
21
Send... CH03 0960100013785634120062.....send res 0
22
17 MI600
23
Send... CH23 116010001378563412007A.....send res 0
24
9 MI600
25
Send... CH40 0960100013785634120062.....send res 0
26
17 MI600
27
Send... CH61 116010001378563412007A.....send res 1
28
9 MI600
29
Send... CH75 0960100013785634120062.....send res 0
30
17 MI600
31
Send... CH03 116010001378563412007A.....send res 0
32
9 MI600
33
Send... CH23 0960100013785634120062.....send res 0
34
17 MI600
35
Send... CH40 116010001378563412007A.....send res 0
36
9 MI600
37
Send... CH61 0960100013785634120062.....send res 1
38
17 MI600
39
Send... CH75 116010001378563412007A.....send res 0
40
9 MI600
41
Send... CH03 0960100013785634120062.....send res 0
42
17 MI600
43
Send... CH23 116010001378563412007A.....send res 0
44
9 MI600
45
Send... CH40 0960100013785634120062.....send res 0
46
17 MI600
47
Send... CH61 116010001378563412007A.....send res 0
48
9 MI600
49
Send... CH75 0960100013785634120062.....send res 0
50
17 MI600
51
Send... CH03 116010001378563412007A.....send res 0
52
9 MI600
53
Send... CH23 0960100013785634120062.....send res 0
54
17 MI600
55
Send... CH40 116010001378563412007A.....send res 0
56
9 MI600
57
Send... CH61 0960100013785634120062.....send res 1
58
17 MI600
59
Send... CH75 116010001378563412007A.....send res 0
60
9 MI600
61
Send... CH03 0960100013785634120062.....send res 0
62
17 MI600
63
Send... CH23 116010001378563412007A.....send res 0
64
9 MI600
65
Send... CH40 0960100013785634120062.....send res 0
66
17 MI600
67
Send... CH61 116010001378563412007A.....send res 1
68
9 MI600
69
Send... CH75 0960100013785634120062.....send res 0
70
17 MI600
71
Send... CH03 116010001378563412007A.....send res 0
72
9 MI600
73
Send... CH23 0960100013785634120062.....send res 0
74
17 MI600
75
Send... CH40 116010001378563412007A.....send res 0
76
9 MI600
77
Send... CH61 0960100013785634120062.....send res 1
78
17 MI600
79
Send... CH75 116010001378563412007A.....send res 0
80
9 MI600
81
Send... CH03 0960100013785634120062.....send res 0
82
17 MI600
83
Send... CH23 116010001378563412007A.....send res 0
84
9 MI600
85
Send... CH40 0960100013785634120062.....send res 0
86
17 MI600
87
Send... CH61 116010001378563412007A.....send res 1
88
9 MI600
89
Send... CH75 0960100013785634120062.....send res 0
90
17 MI600
91
Send... CH03 116010001378563412007A.....send res 0
92
9 MI600
93
Send... CH23 0960100013785634120062.....send res 0
94
17 MI600
95
Send... CH40 116010001378563412007A.....send res 0
96
9 MI600
97
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...
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!
:-)
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.
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
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:
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
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).
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
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...?
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?
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...
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, 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!!
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.
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:
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 ?
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.
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 ;-)
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.
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
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
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.
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
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:>>
>> 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.
@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.
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.
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.
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...)
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
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.
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.
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.
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 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.
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. 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?
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
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.
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?
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.
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.
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.
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).
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
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.
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.
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?
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.
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
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 ?
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!!
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...
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
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.
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
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
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.
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.
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?
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
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..
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...
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.
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
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
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!
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
@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"):
1
Send... CH61 0960100013785634120062.....send res 0
2
Send... CH75 116010001378563412007A.....send res 0
3
Send... CH03 0960100013785634120062.....send res 0
4
Send... CH23 116010001378563412007A.....send res 0
5
Send... CH40 0960100013785634120062.....send res 0
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.
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)...
1
360453 Send... CH61 360454116010001378563412007A.....send res 0
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.
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:
1
2901299 Send... CH61 29012990960100013785634120062.....send res 0
2
2906299 Send... CH75 2906299116010001378563412007A.....send res 0
3
2911299 Send... CH03 29112990960100013785634120062.....send res 0
4
2916299 Send... CH23 2916299116010001378563412007A.....send res 0
5
2921299 Send... CH40 29212990960100013785634120062.....send res 0
6
2926299 Send... CH61 2926299116010001378563412007A.....send res 0
7
2931299 Send... CH75 29312990960100013785634120062.....send res 0
8
2936299 Send... CH03 2936299116010001378563412007A.....send res 0
Bin mal gespannt, ob und wo die sich morgen finden.
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
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.
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?
Ziyat T. schrieb:> 2936299Ziyat 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...
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.
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 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. 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+! ".
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
@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?
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:-)grinsZiyat 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...
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
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
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=0xB6Ziyat 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.
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
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?
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
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.
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?
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.
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?
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.
@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.
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
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?
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
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 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.
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
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!
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.
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ö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?
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.
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
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 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
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?
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.
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?
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. 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.
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
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...
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.
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".
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:
1
static bool received[4] = {false};
2
static bool requestOpen = true;
3
4
[...]
5
if (MI600){ // 2 PVs
6
MIDataCMD=!received[0] ? 0x09 : 0x11;
7
8
[...]
9
if (MI1500){ // 4 PVs
10
MIDataCMD = 0x0036
11
for (int8_t i = 0; i < 4; i++) {
12
if (!received[i]) {
13
break;
14
}
15
++MIDataCMD;
16
}
17
}
18
[...]
19
if (received[0] && received[1] && received[2] && received[3]) {
20
tickMillis = millis() + maxTimeForNextPing; //we got a message and will just wait....
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
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 :)
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.
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? ;-)
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 ???
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
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 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?).
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.
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)...
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. 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:
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?
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
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.
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?
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.
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?
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.
> 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
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.
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
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 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.
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.
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.
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.
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...).
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. 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
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.
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. 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???
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:
1
gesetzt 10W, WR:13W, shelly:9W
2
gesetzt 20W, WR:24W, shelly:19W
3
gesetzt 50W, WR:48W, shelly:43W
4
gesetzt 100W, WR:103-108W, shelly:98-103W
5
gesetzt 150W, WR:152-157W, shelly:152-157W
6
gesetzt 200W, WR:201-206W, shelly:201W
7
gesetzt 300W, WR:310W max, shelly:max 305W
8
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.ä.)
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.
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?
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.
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…
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
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?
Thread beobachten
Seitenaufteilung abschalten