MYSENSORS Frage zum Thema Rückkanal und 1% Regel

[uwetaz]

Hallo zusammen,

ich habe erste sinnvolle Basteleien mit Mysensors und FHEM (mit NRF24L01+ und RFM69HW) fertig am Laufen und hätte folgende Fragen die ich mit Recherche im Netz nicht beantworten konnte:

- Rückkanal: Wie könnte man relativ einfach in FHEM realisieren dass bei fehlendem Ack ein Befehl zu einem Aktor nochmal wiederholt wird? Ich habe Ack aktiviert und sehe auch bei einem Befehl zu einem deaktiven Aktor dass outstandingAck hochzählt. Bei Homematic gibt es meines Wissens ein Attribut msgRepeat was für sowas verwendet werden kann. Aber weder im GW noch in den Nodes von mysensors habe ich ähnliche Attribute gefunden. Ich würde halt sowas gern neben der hilfreichen in Betrieb genommenen heartbeat Funktion und Ack noch einbauen. Bei FS20, was ja keinen Rückkanal hat, habe ich bei Rolloaktoren gelegentlich einfach kein Schalten der Aktoren. Das ist sicher nichts Besonderes. Aber das würde ich bei meinem mysensors-Aufbau gern ändern.
Oder hat jemand Erfahrung mit einer anderen Controller SW die sowas für mysensos unterstüzt?
Nachtrag: Hier ist in Antwort 15 was erklärt (es scheint immer wieder versucht zugestellt zu werden wobei die Abstände größer werden):
https://forum.fhem.de/index.php/topic,114657.0.html

- 1% Regel. Die CUL FW hat ja das Feature oder eher diese Beschränkung schon eingebaut. Wird Sendezeit überschritten kommt eine Fehlermeldung und man muss warten. Ich würde gern mal abschätzen wo ich mit meiner mysensors Konfiguration rauskomme (ist alles im Rahmen des Erlaubten, grenzwertig oder muss ich was tun). Also wie groß meine Sendezeit mit dem Senden durch mysensors GW und Nodes pro Stunde ist. Aber ich habe keine Infos gefunden wie lang z.B. so ein mysensors Protokoll im Schnitt ist. Vielleicht habe ich nur nicht die richtigen Suchbegriffe verwendet.


Danke für eine Antwort im Voraus
Uwe

[Beta-User]

Vorab mal: Willkommen im FHEM-Forum!

Wie du schon herausgefunden hast: Ein mit ACK versendeter Befehl wird immer weiter versendet, bis entweder FHEM neu gestartet wird oder eben dann irgendwann "Treffer" gemeldet wird. Es gibt auch ein NACK-Event, auf das man reagieren könnte.
Stellt sich nur die Frage, ob ein "namuell-automatisiertes" neuerliches Senden mehr Erfolg hat wie die (verlängerte) Wiederholung. (CUL_HM bricht irgendwann ab).

Für Funkstreckenanalysen würde ich eher DEBUG-Optionen im Sketch aktivieren und dann auch mal die RSSI-Werte ansehen. Die sollten für RFM verfügbar sein.

MySensors wurde ursprünglich für nRF24 entwickelt, und auf 2.4GHz gibt es keine 1%-Regel. Wie das ggf. für RFM69/9. umgesetzt ist, entzieht sich meiner Kenntnis. In der Regel sind die MySensors-Telegramme mAn. aber eher kurz, und es geht bei 1% auch um "ungefragt".
Aber auch da kannst du ggf. ja z.B. über get heartbeat rausfinden, wie schnell die Übertragung so prinzipiell ist.

[uwetaz]

Hallo Beta-User,

danke für das "Willkommen"

RSSI hab ich nach einem Problemchen zum Laufen bekommen. In der aktuellen 2.3.2 fehlt nämlich in dem Beispiel noch ein define; siehe hier:
https://forum.mysensors.org/topic/11651/problems-with-rfm69_rfm95_atc_signalreport-example

Noch eine Verständnisfrage zu Deinem Vorschlag zum Rausfinden der Schnelligkeit mit "get heartbeat". Das "get heartbeat" kann ich via Button im FHEM Device drücken und sehe in einem parallel offenen Browserfenster mit FHEM unter Event monitor, dass gefühlt sofort eine Antwort kommt. Das meinst Du sicher nicht, oder?

[Beta-User]

Wenn du über FHEMWEB das get auslöst, sollte eigentlich auch ein Dialogfeld erscheinen mit der Info, wie lange es gedauert hat, bis die Antwort da war. Das wäre dann - sehr grob gesprochen - also in etwa die Zeit, die zwei Messages brauchen - allerdings ohne Payload.
Ab hier wird es unscharf, bin kein Experte für sowas... Hier mal ein paar Anhaltspunkte:
Unterstellt, es ist kein signing etc. im Spiel, müßte die Payload ca. 1/2 bis 1/4 des Datenvolumens ausmachen (8/32 Byte, die der nRF max. kann). Demnach würde eine Message eben dann ca. höchstens so lange brauchen wie dieser heartbeat-roundtrip. Die Zahl der Messages über der Zeit, die eine Node sendet, kennst du ja in etwa, so dass sich daraus zumindest ungefähr ergibt, welches Funkbudget eine Node maximal ausschöpft.