Homematic Wired - Homebrew Devices

[loetmeister]

Hi,

danke euch für die Erklärung und Lösung.
Im nachhinein eigentlich schon klar das ich für 16 bit variablen auch entsprechend Platz brauche, das ich einfach nur die Adresse des ersten bytes übergeben kann hatte ich nicht auf dem Schirm. Komisch das es hier zum ersten mal Probleme gegeben hat.

Habe alle einsprechenden Vorkommnisse angepasst, in HBWBlind, HBWOneWireTempSensors, HBWSenEP

Code: [Auswählen]

    static uint16_t level;
    get((uint8_t*) &level);
    device->sendInfoMessage(channel, 2, (uint8_t*) &level):(weiter "static", da es 2 byte RAM statt 60..130 bytes im code belegt hatte)


EDIT, klappt auch so: (kommt fast aufs Selbe raus, list sich aber schöner - wie ich finde)

Code: [Auswählen]

    static uint8_t level[2];
    get(level);
    device->sendInfoMessage(channel, 2, level):
Gruß,
Thomas

[loetmeister]

Hallo Thorsten,

habe mal einen pull request erstellt.
https://github.com/ThorstenPferdekaemper/HBWired/pull/13

Neue Geräte:

• HBW-1W-T10
• HBW-CC-VD-8
• HBW-Sen-EP

Dazu die Erweiterung in HBWired um peerings mit Datenaustausch zu ermöglichen. Z.B. Temperatursensor & PID/Ventil-regler.
Support_HBWLink_InfoEvent
Standardmäßig deaktiviert in HBWired.h.

Gruß,
Thomas

[Thorsten Pferdekaemper]

...ist gemerged.

[aperoap]

Hallo zusammen,
Mittlerweile nutze ich bei mir zu Hause überall wo was geschaltet werden soll die HBW-Sen-Key-12 und HBW-LC-Sw8 mit einfachem paarig. Das funktioniert sehr zuverlässig und stabil (Respekt). Ich habe gestern versucht zwei ...Sw8 mit einem ...Key-12 Kanal zu paaren. Das paarig hat an sich problemlos funktioniert, dir Lampe (..Sw8) dir als zweites gepaart wurde, lässt sich nicht Schalten.
Ist als mehr paarig nicht möglich oder gibt es spezielle Sachen die ich einhalten soll?
LG

[loetmeister]

Hi,

ich bin mir relativ sicher das es leider aktuell nicht funktioniert einen Sensor Kanal (Key) mehr als einem Aktor Kanal (Sw) zu peeren.
Nachdem die erste peering Nachricht auf den Bus geschickt wurde, wird eine weile gewartet. In der Zwischenzeit werden weitere peerings ignoriert.
// onlyIfIdle: If this is set, then the bus must have been idle since 210+rand(0..100) ms

Ich hatte das Problem bei meinem Temperatursensor, bei dem die Info Nachricht an die Zentrale weitere Nachrichten blockiert hat. Dort hatte ich mir mit einer extra Wartezeit geholfen. Damit klapp dann das erste peering, weitere würde aber auch verloren gehen, da es das grundsätzliche Problem nicht löst. Besser wäre es einen Sendespeicher einzuführen, der kann dann "langsam" abgearbeitet werden. Wie genau das geht... müsste man sich mal ein paar Abende Zeit nehmen  (Nachricht aus dem Speicher löschen wenn ACK Empfangen oder 3 Fehlversuche - bzw. nur 1 oder 2 Versuche bei "Key" peerings?)


Gruß,
Thomas

[aperoap]

Hört sich kompliziert an. Vielleicht macht sich jemand irgendwann die Mühe bis dahin werde ich wohl mit notify klar kommen müssen:)

Andere Frege:

Kann man ...Sen12 irgendwie auch als fensterkontakt nutzen. Sprich auf und zu. Wird die Aktualisierung jeder Sekunde bzw. Max 5 Sekunden wegen longtime press bei >10 Fenstern zu Probleme führen?

Gruß

[loetmeister]

Hi,

Kann man ...Sen12 irgendwie auch als fensterkontakt nutzen. Sprich auf und zu. Wird die Aktualisierung jeder Sekunde bzw. Max 5 Sekunden wegen longtime press bei >10 Fenstern zu Probleme führen?

Denke das geht nicht... und macht auch keinen Sinn 
Nach 5 Sekunden (oder was auch immer die "long press time" ist) wird der der Bus von jedem sensor mit Nachrichten geflutet, bis der Schalter wieder öffnet...

Du müsstest ein Device nehmen, was <HBWKey.h> nutzt. Z.B. HBW-SC-10-Dim-6 oder ein eigenes erstellen.
Bei HBWKey kannst dann wählen:
IN_DOORSENSOR   0    // sends a short KeyEvent on HIGH and long KeyEvent on LOW input level changes
IN_MOTIONSENSOR 1    // sends a short KeyEvent for raising or falling edge - not both
IN_SWITCH       2    // sends a short KeyEvent, each time the input (e.g. wall switch) changes the polarity
IN_PUSHBUTTON   3    // sends a short KeyEvent on short press and (repeated) long KeyEvent on long press

DOORSENSOR wäre für Fenster passend... das schickt dann eine Nachricht wenn sich der Status ändert (Fenster auf/zu).

PS: https://github.com/loetmeister/HBWired/tree/master/HBW-SC-10-Dim-6 hab ich gestern noch ein paar Änderungen eingecheckt.

Gruß,
Thomas

[loetmeister]

Hi,

hab mal einen Puffer eingebaut... etwas quick und dirty, aber in einem kurzen test hat das Funktioniert. Es werden max 4 Nachrichten gespeichert, wenn der Bus belegt ist und gesendet sobald der Bus frei ist. Aktuell bleiben die Nachrichten im Puffer, wenn der Bus nicht frei ist... denke es wäre gut sie zu löschen, auch wenn sie gar nicht gesendet wurden... was bringen einem Tastendrücke die einige Sekunden alt sind... da hat man ungeduldig eh schon wieder auf den Taster gedrückt.

Kompiliere mal einen HBW-Sen-Key-12 neu, mit dem code aus der Lib, von https://github.com/loetmeister/HBWired + der ZIP im Anhang.

Code: [Auswählen]

// key-Event senden an bestimmtes Target
uint8_t HBWDevice::sendKeyEvent(uint8_t srcChan, uint8_t keyPressNum, boolean longPress, uint32_t targetAddr, uint8_t targetChan, boolean enqueue) {
   if (pendingActions.zeroCommunicationActive) return 1; // don't send in zeroCommunication mode, return with "bus busy" instead
   txTargetAddress = targetAddr;  // target address
   txFrameControlByte = 0xF8;     // control byte
   txFrameDataLength = 0x04;      // Length
   txFrameData[0] = 0x4B;         // 'K'
   txFrameData[1] = srcChan;      // Sensornummer
   txFrameData[2] = targetChan;   // Zielaktor
   txFrameData[3] = (longPress ? 3 : 2) + (keyPressNum << 2);
//--> old part   //return sendFrame(true);  // only if bus is free

//>>>> new:
   uint8_t result = sendFrame(enqueue, enqueue ? 1 : 3);  // only 1 try if queuing is allowed, 3 otherwise
   if ( result == BUS_BUSY && enqueue)  // bus busy and queuing allowed
   {
   return sendBufferAddMessage(srcChan, keyPressNum, longPress, targetAddr, targetChan, 2);  // add to queue, try to send 2 times
   }
   else
   return result;
};
//^^^^^^^^^^^TODO: send queue (buffer)
uint8_t HBWDevice::sendBufferAddMessage(uint8_t srcChan, uint8_t keyPressNum, boolean longPress, uint32_t targetAddr, uint8_t targetChan, uint8_t reSendCounter)
{
uint8_t index = getNextSendBufferSlot(true);
if (index == 0xFF)  return BUS_BUSY;  // no empty slot (buffer full)

sendBuffer[index].reSendCounter = reSendCounter;
sendBuffer[index].srcChan = srcChan;
sendBuffer[index].targetAddr = targetAddr;
sendBuffer[index].targetChan = targetChan;
sendBuffer[index].keyPressNum = keyPressNum;
sendBuffer[index].longPress = longPress;

if(hbwdebugstream) {
    hbwdebug(F("sendQ in: ")); hbwdebug(index); hbwdebug(F(" retry: ")); hbwdebug(reSendCounter);
hbwdebug("\n");
}
return SUCCESS;
}
void HBWDevice::sendBufferInit()
{
for(byte i = 0; i < SEND_BUFFER_SIZE; i++) {
sendBuffer[i].reSendCounter = 0;
}
}
uint8_t HBWDevice::getNextSendBufferSlot(boolean free)
{
for(byte i = 0; i < SEND_BUFFER_SIZE; i++) {
if (free) {
if (sendBuffer[i].reSendCounter == 0)  return i;  // return free index number
}
else {
if (sendBuffer[i].reSendCounter != 0)  return i;  // return used index number
}
}
return 0xFF;
}
void HBWDevice::sendBufferTransmitMessage()
{
if (!busIsIdle(250))  return; // add own timestam to retry faster? ignore minIdleTime for send frame? (onlyIfIdle = false)
uint8_t index = getNextSendBufferSlot(false);
if (index == 0xFF)  return;  // nothing to send

if(hbwdebugstream) {
    hbwdebug(F("sendQ out: ")); hbwdebug(index); hbwdebug(F(" retry: ")); hbwdebug(sendBuffer[index].reSendCounter);
hbwdebug("\n");
}

uint8_t result = sendKeyEvent(sendBuffer[index].srcChan, sendBuffer[index].keyPressNum, sendBuffer[index].longPress,
sendBuffer[index].targetAddr, sendBuffer[index].targetChan, false);  // send, but not queue same message again

if (result == SUCCESS) // successful send
sendBuffer[index].reSendCounter = 0;
else
sendBuffer[index].reSendCounter--;
}
//^^^^^^^^^^^TODO: make it nice....

Also TTL für die Sende Puffer fehlt... auch würde ich den Puffer gern für andere Nachrichten nutzen, nicht nur sendKeyEvent.

Gruß,
Thomas

[aperoap]

Ich werde das mal ausprobieren, vielen Dank.
wie groß wäre der Aufwand um z.B. 12 Kanal Fenster/Tür Kontakt Sensor mit Homebrew wired zu realisieren?

[loetmeister]

wie groß wäre der Aufwand um z.B. 12 Kanal Fenster/Tür Kontakt Sensor mit Homebrew wired zu realisieren?

Hi,

hast du dir HBW-SC-10-Dim-6 mal angesehen? Wenn du das als Basis nimmst, dann brauchst du nur die 6 Dimmer Kanäle raus zu nehmen und kannst die Anzahl der Sensor Kontakte erhöhen... ist eigentlich schon alles da was du brauchst. 

Gruß,
Thomas

[aperoap]

Ich habe auf die Schnelle HBW-SC-10-Dim-6 angelegt und die Pins zum testen gegen Gnd geschaltet. Leider hat das nicht funktioniert. Da meine Tochter heute Geburtstag hatte, werde ich die Woche nach der Arbeit bearbeiten und mich melden. Danke und Gruß

[Thorsten Pferdekaemper]

Hi,
es besteht eigentlich kaum Notwendigkeit, das Ding selbst zu entwickeln:
https://www.elv.de/homematic-12fach-kontaktsensor-fuer-schaltzustandserkennung-komplettbausatz.html
...zumindest wäre es viel teurer, das selbst zu machen, denke ich.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
zu den Peerings: Meine erste Reaktion darauf war "nein, das sollte eigentlich gehen". Allerdings sieht es im Coding tatsächlich anders aus. Wahrscheinlich gab es bei mir im Test nie ein Problem, weil die Original-HM-Aktoren sowieso schon schalten, wenn die Peering-Nachricht für irgend einen Kanal kommt. D.h. ein Peering für mehrere Kanäle eines HM-Original-Device funktionieren.
Der Nachteil bei den Original-Devices ist allerdings, dass die Logging-Nachricht dann auch nur für den ersten Kanal kommt, so dass es in FHEM aussieht, als ob es nicht funktioniert hätte.
Anyway: Ich glaube, dass ich das damals nicht weiter verfolgt hatte, da es dazu wahrscheinlich keine perfekte Lösung gibt. Gut wäre wahrscheinlich, wenn die ganze Kommunikation mehr asynchron gehen würde und die Geräte sich merken würden, bei welchem Empfänger sie gerade sind. Außerdem sollte man vielleicht ähnlich vorgehen wie bei HM-Original und die Peering-Nachricht tatsächlich an jedes Gerät nur einmal schicken (und nicht einmal pro Kanal). Natürlich müssten sich dann auch die Empfänger ändern.
...aber wie schon angedeutet: Die richtig perfekte Lösung habe ich da auch nicht.
Gruß,
   Thorsten

[loetmeister]

Außerdem sollte man vielleicht ähnlich vorgehen wie bei HM-Original und die Peering-Nachricht tatsächlich an jedes Gerät nur einmal schicken (und nicht einmal pro Kanal)

Das klingt spannend... nur eine Nachricht ist gut, weniger traffic auf dem Bus. 
Der Fall, denn du beschrieben hast, wäre z.B. 1 sensor Kanal auf Device A - verknüpft mit 2 oder mehreren aktor Kanälen auf Device B?
Würde die CCU die peerings so in die Homebrew geräte schreiben? Also im sensor einen peering Eintrag, im aktor zwei oder mehr, mit dem Zielkanal? Müsste das nicht sogar schon jetzt funktionieren? (wenn FHEM das EEPROM so beschreiben würde?)


In vorangegangenen Fall war die Situation aber ein Sensor (Key) soll mehrere Aktoren (angenommen 1 Kanal pro Aktor) schalten. D.h. es sind unterschiedliche Adressen/Devices an den die Key Nachricht gesendet werden muss.

Gruß,
Thomas

[aperoap]

Hi,
es besteht eigentlich kaum Notwendigkeit, das Ding selbst zu entwickeln:
https://www.elv.de/homematic-12fach-kontaktsensor-fuer-schaltzustandserkennung-komplettbausatz.html
...zumindest wäre es viel teurer, das selbst zu machen, denke ich.
Gruß,
   Thorsten

Hast vollkommen recht, habe jedoch nur 5 V Versorgungsspannung in Verteiler und Serienplattine fertigen lassen wo Arduino Mini Pro drauf gesteckt werden und unten mit Reihenklemmen alles verteilt wird. Somit wäre die arduino Lösung mit homebrew viel besser auch wenn es mir viel Zeit kosten würde. In schlimmsten Fall muss ich den schon kaufen :-)

Irgendwie will HBW-SC-10-Dim-6 bei mir nicht laufen. Wird zwar von FHEM erkannt aber passiert nichts wenn die Pins gegen gnd geschaltet werdn. Eine Idee?