Documentation: Ahoy-DTU parallel operation communication

[MiniOh]

Hardware

• ESP8266
• ESP32
• Raspberry Pi

nRF24L01+ Module

• nRF24L01+ you verified this is a Plus model capable of the required 256kBit/s mode
• square dot indicates original Nordic Semicon chip
• round dot indicates copy-cat / counterfeit SI labs chip

Antenna:

• circuit board
• external antenna

Software

• AhoyDTU
• OpenDTU

Version / Git SHA:

Version: 0.5.59

Hello,

I have a question regarding the susceptibility to failure when another DTU is in operation.
I was previously using an HM-DTU, but would like to switch to Ahoy or Open-DTU.
In the past few months, the HM-DTU and an Open-DTU have been running in parallel. Both supplied data and the Open-DTU was always connected to the 3 inverters. The only disadvantage is that the Open-DTU occasionally transmits "zero" values via MQTT due to the parallel operation. This behavior is well known. I've been testing Ahoi-DTU for a few weeks now, because there is a function here that no "zero" data is transmitted. So far it works great.
However, Ahoy-DTU and HM-DTU don't work well in parallel at all. As soon as the HM-DTU is also in operation, the inverters are often displayed as unavailable in the Ahoy-DTU and it is only rarely the case that all 3 are reliably online.
I am aware that this is due to the parallel operation, but I would like to continue operating the HM-DTU until I have integrated everything into my home automation. Parallel operation was possible with Open-DTU. What is the difference in the communication behavior between Open-DTU and Ahoy-DTU?

Thank you in advance.

================================================================

Hallo,

ich habe eine Frage bezüglich der Störanfälligkeit, wenn eine weitere DTU im Betrieb ist.
Ich nutzte bisher eine HM-DTU, möchte aber auf Ahoi oder Open-DTU umsteigen.
In den Vergangenen Monaten liefen die HM-DTU und eine Open-DTU parallel. Beide lieferten Daten und auch die Open-DTU war immer mit den 3 Wechselrichter verbunden. Einziger Nachteil, durch den Parallel Betrieb werden von der Open-DTU hin und wieder "Zero" Werte über MQTT übermittelt. Dieses Verhalten ist ja bekannt. Nun bin ich seit einigen Wochen Ahoy-DTU am testen, da es hier nun eine Funktion gibt, dass keine "Zero" Daten übertragen werden. Soweit funktioniert das auch klasse.
Allerdings funktionieren Ahoi-DTU und HM-DTU überhaupt nicht gut parallel. Sobald die HM-DTU zusätzlich in Betriebt ist, werden in der Ahoi-DTU die Wechselrichter ganz oft als nicht verfügbar angezeit und es kommt auch nur selten vor, dass alle 3 zuverlässig online sind.
Mir ist bewusst, dass dies am Parallel Betrieb liegt, allerdings würde ich gerne die HM-DTU noch weiter betreiben bis ich alles in mein Homeautomation intregriert habe. Mit Open-DTU war der Parallel Betrieb möglich. Was unterscheidetet in dem Kommunikationsverhalten Open-DTU und Ahoy-DTU?

Danke euch schon mal vorab.

[stefan123t]

Hallo das Problem rührt vom Protokoll her. Die beiden/drei DTUs schicken Kommandos an den Wechselrichter und bekommen Antworten vom WR. Wir kennen aber nur das MainCmd auf das der WR antwortet und nicht das SubCmd zu dem diese Antwort gehört.
Wenn mehrere DTUs mit dem WR sprechen und Aufgaben / Kommandos zum Beantworten schicken dann tun sie dies ohne sich aufeinander abzustimmen. Der WR antwortet zwar brav an die entsprechende DTU Adresse aber vermutlich kommt seine State Machine in diesem Fall durcheinander und er antwortet evtl auf ein anderes MainCmd/SubCmd.
Viele der Retransmit Kommandos sind nämlich nur gib mir Paket Nummer x der letzten MainCmd Anfrage. Wenn jetzt die Hoymiles oder OpenDTU gerade SubCmd A angefragt hat, wir mit AhoyDTU aber SubCmd B dann ist das N-te Paket von A etwas anderes als das von uns erwartete N-te Paket von B.
Näheres bitte im Wiki unter Protocol nachlesen. Danke!
Z.B. hier: https://github.com/lumapu/ahoy/wiki/Protocol#welche-device-info-req_arw_dat_all-0x15-sub-kommandos-gibt-es

[MiniOh]

Hallo,

vielen Dank für die Antwort.
Ja, im Groben ist mir bekannt, warum das passiert und dass es durch mehrere DTUs verursacht wird.

Die Frage die ich mir aber stelle ist, warum es mit HM-DTU und OpenDTU funktioniert und mit HM-DTU und Ahoy-DTU nicht bzw. nur sehr schlecht?

[stefan123t]

Es gibt hier zwei mögliche Gründe:

• das Channel Hopping ist bei AhoyDTU etwas anders (evtl. sogar unsinnig / falsch ?) implementiert.
• die Selektion der Parser Routinen für die Responses der AhoyDTU könnten evtl. noch besser werden und die Antworten auf Plausibilität prüfen ?
• vor allem die Retransmit Funktion in AhoyDTU ist m.E. nach anders programmiert. Wir senden eine Anfrage und warten welche Pakete zurückkommen. Wenn keine Antwort kommt, dann fragen wir nach dem vermutlich letzten Paket 0x83/4/5 und suchen uns erst dann die anderen fehlenden Pakete 0x81, 0x82 und 0x83 / 0x84 dazu. OpenDTU und Hoymiles fragen in einem solchen Fall (dass kein Ende Paket kam) entweder die komplette Nachricht nochmal nach oder aber das erste fehlende Paket nochmals ab.

[MiniOh]

Hallo,

vielen Dank. Das klingt auf jeden Fall nach einer plausiblen Erklärung für das unterschiedliche Verhalten.
Lässt sich das in AhoyDTU anpassen, bzw. ist dies gewünscht?

[lumapu]

Ja klar, wir sind auf jeden Fall interessiert die Kommunikation so gut und stabil wie möglich zu machen.

[MiniOh]

Das freut mich.

[MiniOh]

@lumapu
Gibts deinerseits da schon zeitliche Pläne, wann sowas angepasst werden könnte?
Ich teste wirklich seit einiger Zeit Ahoy und OpenDTU, und hier sind schon deutliche Unterschiede, wie häufig "vollständige" Daten verarbeitet werden.

[lumapu]

das passiert Stück für Stück, zB. ist die retransmit Thematik in der aktuellen Dev Version schon umgebaut. (0.5.68)

Ich habe selbst nicht mehr den gesamten Überblick wo was besser / schlechter ist und kann nur über issues wie diesen darauf reagieren.

[MiniOh]

Ok, werde ich morgen mal testen.
Besser / schlechter ist keinesfalls negativ gemeint.
OpenDTU liefert sehr kontinuierlich Daten im eingestellten Zeitraum, z.B. alle 10 sek.
Übermittelt aber auch Zeros per MQTT.
Ahoy hat eine schöne Funktion, dass keine Zeros übermittelt werden, allerdings ist hier zumindest bis zur 0.5.65 die kontinuierliche Kommunikation noch nicht so gegeben.

[MiniOh]

@lumapu
Hallo nochmal, ok, ich habe nun die 0.5.68 im Einsatz und kann, wie bereits von Dir beschrieben ein deutlich besseres Transmit Verhalten bestätigen.
Was jetzt evtl. noch schön wäre, wenn die Werte nicht in "zufälligen" Abständen per MQTT übermittelt würden.
In OpenDTU lässt sich der Wert in Sekunden angeben, so dass dann z.B. genau minütlich Daten geliefert werden.
Kannst du das anpassen, oder soll das lieber ein neuer Feature Request sein?

[lumapu]

Ich weiß nicht was du dir daraus versprichst, AhoyDTU übermittelt Daten, sobald es neue empfangen hat. Wenn keine neue Daten können gibt's auch keine neuen Informationen.

[MiniOh]

Hallo,
persönlich finde es ich "ordenlicher", wenn ich z.B. jede Minute oder so etwa alle 30 Sekungen einen Wert in die Datenbank schreibe, anstatt, dass dies "willkürliche" Zeitabstände sind.

Du sagt, immer wenn es neue Daten gibt, wird auch etwas versendet.
Lässt es sich nicht umsetzen, dass beispielsweise alle 15 Sek die WR angefragt wird, somit hätte ich doch auch alle 15 Sek frische Daten, die ich dann z.B. minütlich per MQTT verschicken könnte, oder?

In OpenDTU kann man sowohl das Pollintervall zum WR als auch das MQTT Intervall einstellen.
Ist sicherlich kein Muss, aber wäre schön.

[lumapu]

das hängt immer von der Beleuchtungssituation ab.

Ich kann ein festes Intervall vorsehen, nur denke ich bringt das hinsichtlich der Aktualität keinen Vorteil.
Wenn das Intervall verkürzt wird und die Daten weiterhin zuverlässig von Ahoy empfangen werden, dann wird dies natürlich auch öfter per MQTT übertragen

[MiniOh]

Vielen Dank für die Rückmeldung.
Ja, ich verstehen was du meinst. Es bingt evtl. wenig alle x Sekunden etwas per MQTT zu versenden, wenn es keine neuen Werte gibt.

Aber wenn man es so sieht, dass ist wahrscheinlich immer noch die Aktualität der Daten die vom WR kommen, das "Problem"
Teilweise habe ich Abstände von 4-5 Minuten, bis neue Daten übermittelt werden, auch wenn das Verhalten schon besser ist mit der 0.5.68.

Ich kann es leider technisch nicht beurteilen, da mir das Wissen in dem Bereich fehlt.
Ich kanns eben leider immer nur vergleichen. Es ist nach wie vor so, dass ich mit OpenDTU alle ca. 5 Sekungen aktuelle Daten von den Wechselrichtern bekomme, mit Ahoy allerdings teilweise nur alle 4-5 Minuten.

[stefan123t]

Hallo @MiniOh
ich versuche nach wie vor zu verstehen welchen Zweck Du verfolgst bzw wo das Problem ist.

Allerdings funktionieren Ahoi-DTU und HM-DTU überhaupt nicht gut parallel. Sobald die HM-DTU zusätzlich in Betriebt ist, werden in der Ahoi-DTU die Wechselrichter ganz oft als nicht verfügbar angezeit und es kommt auch nur selten vor, dass alle 3 zuverlässig online sind.

Prinzipiell ist es nicht vorgesehen mehrere DTUs parallel zu betreiben bzw. den WR gleichzeitig mit mehreren DTUs abzufragen.
Du willst das aus den genannten Gründen dennoch tun und stellst jetzt fest dass die AhoyDTU gegenüber HM-&OpenDTU noch seltener vom WR beachtet / beantwortet wird.
Vielleicht ist auch die Sendeanlage Deiner anderen DTUs näher an dem WR oder die haben besser Sender/Empfänger. Alleine die Ausrichtung der Antenne kann darauf bereits einen Einfluss haben. Kannst Du Dein Setup mal genauer beschreiben ?

Mir ist bewusst, dass dies am Parallel Betrieb liegt, allerdings würde ich gerne die HM-DTU noch weiter betreiben bis ich alles in mein Homeautomation intregriert habe. Mit Open-DTU war der Parallel Betrieb möglich. Was unterscheidetet in dem Kommunikationsverhalten Open-DTU und Ahoy-DTU?

@lumapu ich hatte mit @cbscpe neulich auch die Senderoutine angesehen und er meinte wir hätten DynamicPayloadLength aktiv aber würde das AutoACK nicht nutzen.

D.h. wir lösen auch bei fehlerhaften Paketen einen IRQ aus und prüfen das selbst.

https://discord.com/channels/984173303147155506/1056138445958938655/1060488095784501278

Vielleicht erklärt ja das die stark unterschiedliche Empfangsqualität in einer kompetitiven Umgebung mit mehreren DTUs wie bei @MiniOh ?

[MiniOh]

@stefan123t

Vielen dank für die ausführliche Ausführung.

Dauerhaft möchte ich natürlich keine DTUs parallel betreiben.
Aber aktuell ist eben noch die original HM DTU im Einsatz.

Mittlerweile sind aber die alternativen Projekte, dank Euch, so gut, dass man die HM DTU ablösen kann.
Bis alles soweit integriert ist, wollte ich die HM DTU aber noch mitlaufen lassen.

Zu deine Frage.
Ich denke Empfangsprobleme kann ich recht gut ausschließen, die 3 WR sind nur einige Meter von den DTUs entfernt.
Alle 3 DTU sind von der positionierung sehr ähnlich, die 3 Antennen sind gleich ausgerichtet.
Ahoy und Open sind jeweils ESP-32 Boards.

Wenn ich HM-DTU und Open-DTU laufen lasse, bekomme ich über den Tag verteilt zuverlässg alle 15-30 Sek Daten von den WR.
HM-DTU und Ahoy-DTU (0.5.69, Abfrageintervall 30 Sek) verhält sich hier immer noch "anders" ... die Daten sind meist weniger aktuell.
Teilweise sind die Daten über 4-5min unverändert.

Ich kann die Situation bzw. die Aktualität der Daten verbessern, indem ich in Ahoy das Abfrageintervall auf 5 Sek stelle,
Aber ich weiß nicht ob es so sinnvoll ist, die WRs so mit Abfragen zuzuballern.
Zudem müsste es ja eigentlich ausreichen, wenn die Daten alle 30 Sek abgefragt werden.
Offenbar scheint es aber so zu sein, dass die empfangenen Daten zu oft nicht vollständig sind?

Vielen Dank schon mal voab.

[DanielR92]

Kurze Frage: Ist dieses Thema noch aktuell hier? Oder kann man es closen?