Homematic Wired - Homebrew Devices

Begonnen von Thorsten Pferdekaemper, 27 April 2014, 00:13:17

Vorheriges Thema - Nächstes Thema

loetmeister

Hi Thorsten,

bzgl. den möglichen Störungen bei dem Senden der peering Nachrichten. (Deine Anmerkung, das es eventuell problematisch ist die KeyEvent Nachrichten nicht zu wiederholen.)

Hab noch ein wenig getestet. Mit Sen-Key-12 und Sw-8. Drei peerings von einem Taster zu switch ch1 bis ch3.
Es dauert 68 ms vom senden des Broadcast, bis zum Empfang des dritten ACK. Ein paar Ausreißer gab es mit 102 ms.
Ich habe versucht die Übertragung zu stören. Long press brodcasts blockieren den Bus, keine Nachricht wird von Sen-Key-12 gesendet - erwartetes Verhalten. Man muss entsprechend den Taster erneut betätigen. Die weiteren Nachrichten habe ich nicht geschafft zu stören (68 ms sind nicht viel Zeit :)) Extra ein "Störgerät" zu bauen, was z.b. bei einem peering mit 'Spam' Nachrichten antwortet habe ich nicht so viel lust...  ::)

Die Möglichkeit der Störung besteht natürlich... zweit Punkte sind mir dazu aufgefallen.

Generell wäre es gut bei Tastern (Sen-Key-12, etc.) "keyPressNum" Zähler nur hochzuzählen wenn device->sendKeyEvent() SUCCESS (oder != BUS_BUSY) zurück gibt. Das vermeidet bei z.B. toggle_to_counter das grade oder ungrade Werte übersprungen werden.
Aktuell würde von device->sendKeyEvent() nur der Status des Brodcast zurück kommen, das hilft dann nicht für Störungen die danach auftreten.

Um im loop, welcher die peering Nachrichten versendet, zu reagieren, müsste sendFrame() eine Kollisionserkennung haben. (Oder noch zwei Ebenen tiefer in sendFrameByte()?)
In sendFrame() könnte man abfangen, wenn ein Frame empfangen wurde, welcher nicht an das eigene Gerät ging. D.h. irgendwer anderes hat dazwischen "gefunkt'". Abgebrochene Übertragungen würde ich aber weiter nicht erkennen. Es würde anhand des fehlenden ACKs auffallen, das ignoriere ich aber, da ein toter Peer nicht alle anderen Blockieren sollte.


byte HBWDevice::sendFrame(...
...
      if(frameComplete) {
        if(targetAddress == ownAddress){
          frameComplete = false;
          parseFrame();
          if(!(frameStatus & FRAME_SENTACKWAIT))  // ACK empfangen
            return SUCCESS;  // we have an ACK, i.e. ok
        };
// ? add "else", in case a frame was received, but not for us (broadcast or other) - stop sending and return BUS_BUSY ?



PS: Weitere Tests: mit Drei peerings weiterhin, aber mehreren Zielgräten: Sen-Key-12, Sw-8 und SD6_Multikey (Dimmer Zielkanal): Meist 68 ms, ein paar mit 102 ms.
Test mit 4 peerings an Drei Zielgeräte Sen-Key-12, Sw-8, SD6_Multikey und Dim-6: 102 ms


1. Nutzen und Risiko bei Wiederholung der Peering Nachrichten (Wahrscheinlichkeit von Störungen beim senden der Peering Nachrichten (Sendevorgang relativ kurz) vs. das Risiko andere Teilnehmer unnötig lange zu stören?)
2. Weitere Fehlerbehandlung im Sensorkanal (z.B. Taster/Schalter: keine Wiederholung. Bewegungsmelder: x Wiederholungen?), keyPressNum Inkrement anpassen?
2a. Aktor: bei gleichem Zählerstand (keyPressNum) den Schaltbefehl nicht erneut ausführen (bei HBW-SC-10-Dim-6 mit "State Machine" bereit implementiert)

Punkt 2, "keyPressNum" würde ich sofort ändern wollen. Punkt 1 würde ich ändern, nach Tests in größeren Umgebungen...

Gruß,
Thomas

Thorsten Pferdekaemper

Hi,
zum "Reagieren beim Senden" gab es mal die Idee, dass man beim Senden (hardwaremäßig) auch gleichzeitig empfängt (ich glaube mir ist das aus Versehen mal passiert) und dabei prüft, ob man auch tatsächlich das empfängt, was man sendet. Dann muss man im Prinzip nicht auf einen Timeout warten. Allerdings kann das auch ganz blöd laufen, wenn das andere Gerät doch alles empfangen hat und dann ein ACK sendet...
Naja, aber man kann wahrscheinlich nicht wirklich alle Eventualitäten abfangen.

Ich denke, Du hast Dir das inzwischen recht genau überlegt und es klingt alles soweit sinnvoll.

Gruß,
   Thorsten
FUIP

loetmeister

#617
Hi,

beim Testen & Optimieren bin ich die Tage über eine neue Version der ShiftRegister74HC595 Library gestolpert, bei der "templates" benutzt werden. In dem speziellen Fall war es nicht so praktisch, aber im Fall von HBWLinkSender / HBWLinkReceiver passt es und spart Speicher (dynamischen Speicher, als auch Flash)
EDIT: Einsparung bei meinem größeren Sketch (21832 Bytes (71%) Mega328p): 140 Bytes Flash und 6 Bytes RAM, bei Verwendung von LinkSender und LinkReceiver.

z.B. sieht HBWLinkKey nun so aus:
template<uint8_t numLinks, uint16_t eepromStart>
class HBWLinkKey : public HBWLinkSender {
  public:
      HBWLinkKey();
  void sendKeyEvent(HBWDevice* device, uint8_t srcChan, uint8_t keyPressNum, boolean longPress);
  private:
      static const uint8_t EEPROM_SIZE = 6;   // "address_step" in XML
};


Ich kann mir die beiden Variablen sparen:
uint8_t numLinks;         // number of links of this type
uint16_t eepromStart;     //size sollte konstant sein -> als define in .cpp


Leider muss die Erzeugung der Objekte angepasst werden.
statt:
new HBWDevice(..., new HBWLinkKey(NUM_LINKS_INPUT, LINKADDRESSSTART_INPUT), ...

nun:
new HBWDevice(..., new HBWLinkKey<NUM_LINKS_INPUT, LINKADDRESSSTART_INPUT>(), ...

Commit/diff, in "bunt":
https://github.com/loetmeister/HBWired/commit/13a874ca8fa7aa30546f86e3b4ad4829a7838466#diff-b6a7deb8ee01e5f455d42a0c336d36e9R17


Ich sehe keine Nachteile von diesem Ansatz und würde alle HBWLinkSender / HBWLinkReceiver + Sketches anpassen...
Eventuell wird es dann zeit für einen Hinweis in der Readme...  ::)
Edit: Und Anpassung im HBW Tutorial..

PS: Danke für den letzten "merge" @Thorsten :)

Gruß,
Thomas

Thorsten Pferdekaemper

Hi,
klar, das kannst Du gerne auch mit Templates machen. Ich glaube, dass ich das anfangs auch schon einmal probiert hatte, aber es hat nicht funktioniert. Womöglich sind inzwischen ein paar Bugs in der Arduino-Umgebung behoben...
Gruß,
   Thorsten
FUIP

Langerrenner

Hallo loetmeister,
zur Zeit werkeln 7 Module in einem FHEM Testsystem.
2 mal Temperaturmodule, 2 mal Relaismodule, 2 mal Schaltermodule und ein Rollomodul. Ich habe die Key- Module durch Direktverknüpfungen mit den Relais und dem Rollomodul verknüpft.
So schaltetet zB. ein Schalterkanal mehrere Relaiskanäle gleichzeitig. Ein Keymodul wird durch ein Drucksimulator ständig stimuliert.
Software Stand von letzter Woche.
Ich musste feststellen, das die gleich angesteuerten Kanäle nach kurzer Zeit nicht mehr synchron sind. Es gehen also Telegramme im System verloren.
In meinem echten Homematic System habe ich auch jede Menge dieser Verbindungen, ohne Probleme.
Frage: Macht es Sinn den Hardware UART zu benutzen. Das würde doch sicher die Interruptbelastung deutlich senken.
Frage: Jede Direktverknüpfung erzeugt ein Telegramm von der Quelle zum Ziel. Bei mehreren Direktverknüpfungen eines Quell- Kanals erzeugt das natürlich eine deutliche Mehrbelastung des Systems.
Einfacher wäre es doch, wenn der Quellkanal eine Nachricht an alle absetzt und nur die Empfangskanäle entscheiden was zu tun ist.
Viele Grüße
Langerrenner

loetmeister

#620
Hi Thorsten,

ok, danke fürs feedback. Die Sachte ist neu für mich, daher die Frage... Habe die anderen Link Klassen auch umgestellt.
Denke ich schick dir dann noch mal in nicht all zu ferner Zukunft einen pull request :)


Zitat von: Langerrenner am 16 Januar 2020, 22:51:35
zur Zeit werkeln 7 Module in einem FHEM Testsystem.
2 mal Temperaturmodule, 2 mal Relaismodule, 2 mal Schaltermodule und ein Rollomodul. Ich habe die Key- Module durch Direktverknüpfungen mit den Relais und dem Rollomodul verknüpft.
Hi Langerrenner, das ist doch schon mal ein schönes Setup... sind das die Module aus GitHub oder angepasste? (HBW-1W-T10, HBW-LC-Sw-8?, HBW-Sen-Key-12?, HBW-LC-BL-4?)

Zitat
So schaltetet zB. ein Schalterkanal mehrere Relaiskanäle gleichzeitig. Ein Keymodul wird durch ein Drucksimulator ständig stimuliert.
Software Stand von letzter Woche.
Ich musste feststellen, das die gleich angesteuerten Kanäle nach kurzer Zeit nicht mehr synchron sind. Es gehen also Telegramme im System verloren.
In meinem echten Homematic System habe ich auch jede Menge dieser Verbindungen, ohne Probleme.
Software aus https://github.com/loetmeister/HBWired oder Thorstens Repo? Am besten könnest du sagen bis zu welchem Commit dein Stand ist (https://github.com/loetmeister/HBWired/commits/master)
Damit ich das besser nachvollziehen kann... "mehrere Relaiskanäle gleichzeitig" - wie viele? Edit: und sind die Verknüpfungen verschiedene Kanäle auf dem selben Gerät? :) Wie oft schickt denn der "Drucksimulator" Tastendrücke auf den Bus?
Den Punkt mit den peerings und wie oft da Nachrichten wiederholt werden sollten hatten wir ja hier vor kurzem diskutiert. Da kann dein test setup bestimmt helfen das zu optimieren.

Zitat
Frage: Macht es Sinn den Hardware UART zu benutzen. Das würde doch sicher die Interruptbelastung deutlich senken.
In den meisten Module kannst du mit #define USE_HARDWARE_SERIAL die UART Konfiguration aktivieren, entsprechende Beschaltung vorausgesetzt. Ich glaube bis auf HBW-Sen-Key-12 ist das der Fall. Das Modul hatte ich (fast) so gelassen wie Thorsten erstellt hatte...
Edit: ich hatte mir gestern auch ein test setup mit 7 Geräten aufgebaut, alle Geräte nutzen UART. Wäre interessant zu sehen ob bei dir Nachrichten auf dem Bus wegen Kollisionen oder Empfangsproblemen der Geräte selbst nicht ankommen..

Zitat
Frage: Jede Direktverknüpfung erzeugt ein Telegramm von der Quelle zum Ziel. Bei mehreren Direktverknüpfungen eines Quell- Kanals erzeugt das natürlich eine deutliche Mehrbelastung des Systems.
Einfacher wäre es doch, wenn der Quellkanal eine Nachricht an alle absetzt und nur die Empfangskanäle entscheiden was zu tun ist.
Ja, laut Thorsten gibt es in dem Fall eine Nachricht an das Zielgerät, nur mit Quell- aber ohne Zielkanal. Dann Schalten alle Kanäle mit nur einer Nachricht...
Die Funktion gibt es in HBW noch nicht.

Gruß,
Thomas

Thorsten Pferdekaemper

Zitat von: Langerrenner am 16 Januar 2020, 22:51:35
Einfacher wäre es doch, wenn der Quellkanal eine Nachricht an alle absetzt und nur die Empfangskanäle entscheiden was zu tun ist.
Die empfangenen Geräte sollen ja eine Bestätigung zurück senden ("ACK"). Wenn die innerhalb einer gewissen Zeit nicht kommt, dann wiederholt der Sender die jeweilige Nachricht. Das macht die ganze Kommunikation stabiler.
Das geht aber nur, wenn der Sender weiß, von wem er eine Antwort zu erwarten hat. Theoretisch könnte das ganze auch noch funktionieren, wenn man eine einzige Nachricht abschickt und dann wartet, bis alle Empfänger ein ACK geschickt haben. Dummerweise werden dann ziemlich sicher die ganzen ACKs kollidieren. Daher muss das ganze einer nach dem anderen gehen.
Vielleicht könnte man sich da noch was intelligenteres ausdenken, aber es soll ja auch noch mit dem Original-HMW kompatibel sein.
Wie schon loetmeister gesagt hat: Was man noch machen könnte, das wäre nur eine Nachricht pro gepeertem Gerät senden statt pro Kanal.
Gruß,
   Thorsten
FUIP

Langerrenner

Hallo Loetmeister, Hallo Thorsten,
die Software die verwende ist die "https://github.com/loetmeister/HBWired".
Ich werde als nächstes die Module umbauen, damit ich den Hardware UART verwenden kann. Gleichzeitig werde ich mein Telegrammmonitor mit laufen lassen, um zu schauen ob alle Telegramme auf dem Bus erscheinen.
Das Handlingdes  des "ACK" Signales und die Kompatibilität zu der HMW - Umgebung halte ich für sehr wichtig und man sollte das nicht so schnell aufgeben. Suchen wir erstmal das Problem.
Ich melde mich wenn ich mehr weiß. Schon mal vielen Dank.
Gruß Langerrenner

Langerrenner

Hallo Loetmeister, Hallo Thorsten,
das Umrüsten auf die Hardware hat leider nicht funktioniert. Das Modul reagiert nicht.
Hab nun die Kommunikation untersucht. Habe dazu ein Taster mit vier Direktverknüpfungen zu unterschiedlichen Modulen programmiert.
Nach kürzester Zeit waren die Kanäle nicht mehr synchron.
Am ehesten waren die letzteren Verknüpfungen fehlerhaft. Im Telegrammmonitor fehlten dann auch die Telegramme von dem Tasten-Modul.
Zwischen die vier Telegrammen von dem Modul fallen aber auch einige andere Telegramme von anderen Modulen hinein. Das bringt wohl das Tasten-Modul dazu seine noch anstehenden Telegramme zu vergessen.

Gruß Langerrenner

loetmeister

Hi,

welches Modul hast du denn auf Hardware Serial umgebaut? HBW-Sen-Key-12?

Bei den anderen Modulen ändert sich RS485_TXEN von Pin 3 nach Pin 2. (Wenn du USE_HARDWARE_SERIAL definiert hast)

ZitatHab nun die Kommunikation untersucht. Habe dazu ein Taster mit vier Direktverknüpfungen zu unterschiedlichen Modulen programmiert.
Nach kürzester Zeit waren die Kanäle nicht mehr synchron.
Das waren weitere Tests mit deinem Bestehenden System, welches Software Serial nutzt?
In dem Fall könntest du in "HBWLinkKey.hpp" die "1" auf eine 2 oder 3 ändern. Das erhöht die Anzahl der Sendeversuche.
device->sendKeyEvent(srcChan, keyPressNum, longPress, addrEEPROM, channelEEPROM, !NEED_IDLE_BUS, 1);
https://github.com/loetmeister/HBWired/blob/28090441d867391217867cf15653ef5b27351a26/libraries/src/HBWLinkKey.hpp#L45


Gruß,
Thomas

Langerrenner

Hallo loetmeister,
es war das Relaismodul. Aber ich hab den RS485_TXEN Steueranschluss nicht geändert. Das wird wohl das Problem sein.
Aber der Empfang in diesen Modulen dürfte nicht das Problem sein.
Ich hab ja fehlende Telegramme festgestellt.
Aber ich muss auch mal den Scop anschließen, ob es zu Kollisionen kommt. Das könnte ja auch noch passieren.

Gruß Langerrenner

loetmeister

Hallo,

habe mal die "inhibit" Funktion eingebaut. Damit lassen sich pro Kanal die Direktverknüpfungen deaktivieren. Gilt nur für Aktoren (Relais, Dimmer, etc.) - alles was über receiveKeyEvent angesprochen wird. Über FHEM lässt sich der Kanal bei aktivem "inhibit" weiterhin setzen.

https://github.com/loetmeister/HBWired/commit/9741aef948067dcc5580f6f1cc2d88a0d595b606

Hoffe das passt... Ich hatte zunächst setLock() und getLock() als virtuelle Funktion (analog zu set() / get() in den Kanälen, das kostet aber meiner Ansicht nach zu viel unnötigen Speicher. Den "inhibit" bool Wert kann ich auch direkt der Channel Klasse hinzufügen, da ich keine kanalspezifische Implementierung brauche.

Gruß,
Thomas

Thorsten Pferdekaemper

Hi,
ich denke auch, dass das so ok ist. Man hätte meiner Meinung nach sogar direkt von HBWDevice auf das inhibitActive-Attribut in HBWChannel zugreifen können. ...aber so ist es vielleicht sauberer.
Gruß,
   Thorsten
FUIP

loetmeister

Danke!  8)

Ich habe mal einen Pull Request gestellt. https://github.com/ThorstenPferdekaemper/HBWired/pull/15
In der Hauptsache wäre drin:

  • HBWLinkSender & HBWLinkReceiver class nutzen templates für 'start_address' und 'number of links'.
  • channel inhibit Funktion hinzugefügt
Gruß,
Thomas

Zeitisen

Hallo,
ich wäre auch interessiert an wired homebrew.
Allerdings benutze ich Homematic IP Wired. Ich denke, Homematic Wired ist inzwischen ein Auslaufmodell.

Ist das Protokoll IP Wired dokumentiert?

Als Gerät würde ich mir dringend einen Raumluftsensor mit dem Bosch BME680 wünschen. Von eQ3 gibt es nur Temperatur und Feuchte.
Dazu gibt es auch einen Thread: https://forum.fhem.de/index.php/topic,78619.msg1021209.html

Beide Threads sind für mich sehr schwierig zu verfolgen, da sie sich in Details verlieren und der aktuelle Stand nicht einfach ersichtlich ist.
Gibt es so etwas wie eine Übersichtsseite des aktuellen Standes?


Zum selber Forschen fehlt mir aktuell die Zeit. Bei mir reicht es vielleicht noch zum Nachbau.