Homematic Wired - Homebrew Devices

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

Vorheriges Thema - Nächstes Thema

loetmeister

Hi Willi,

Würde sagen das tutorial von Thorsten ist ein guter Einstieg...
https://forum.fhem.de/index.php/topic,61780.0.html

Gruß,
Thomas

holzwurm83

Hallo zusammen,

ich möchte mir einen weiteren HBW-LC-Sw-8 zusammen bauen. Das wäre dann mein zweiter. Könnt ihr mir sagen wie und wo ich dafür die Seriennummen anpassen muss?

Ich tippe mal hier, nur was genau und wie.
#define HMW_DEVICETYPE 0x83
#define HARDWARE_VERSION 0x01
#define FIRMWARE_VERSION 0x0066

- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

Thorsten Pferdekaemper

Zitat von: holzwurm83 am 04 Dezember 2018, 16:22:19ich möchte mir einen weiteren HBW-LC-Sw-8 zusammen bauen. Das wäre dann mein zweiter. Könnt ihr mir sagen wie und wo ich dafür die Seriennummen anpassen muss?

Ich tippe mal hier, nur was genau und wie.
#define HMW_DEVICETYPE 0x83
#define HARDWARE_VERSION 0x01
#define FIRMWARE_VERSION 0x0066

Da tippst Du leider falsch...
Das hier könnte helfen:
https://forum.fhem.de/index.php/topic,61780.msg536038.html#msg536038
Gruß,
   Thorsten
FUIP

holzwurm83

Hallo Thorsten,

danke für dein Feedback! Das habe ich wohl überlesen, als ich da vorher nachgeschaut habe...
Ist ja somit noch besser gelöst und ich kann das später ändern!

- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

loetmeister

#529
Hallo,

ich bin beim Testen über https://github.com/ThorstenPferdekaemper/HBWired/issues/2 (EDIT: issue #2 nicht #1) gestolpert. (Tastendrücke z.B. bei HBW-Sen-Key-12 werden nur dann als Broadcast geschickt, solange es kein Peering für den entsprechenden Kanal gibt.)
Ich dachte bisher, es wäre in device->sendKeyEvent(), mit dem sendKeyEvent an die Broadcast Adresse erledigt... Da aber nur "onlyIfIdle" gesetzt ist, wird nichts gesendet wenn vorher bereits ein Frame über das Peering (linkSender) verschickt wurde.


// key-Event senden, inklusive peers etc.
uint8_t HBWDevice::sendKeyEvent(uint8_t srcChan, uint8_t keyPressNum, boolean longPress) {
if (pendingActions.zeroCommunicationActive) return 1; // don't send in zeroCommunication mode, return with "bus busy" instead
    if(linkSender)
        linkSender->sendKeyEvent(this, srcChan, keyPressNum, longPress);
    return sendKeyEvent(srcChan, keyPressNum, longPress, 0xFFFFFFFF, 0);  // only if bus is free
};


Ich hatte zum testen mal "onlyIfIdle" = false für den sendKeyEvent an die Broadcast Adresse gesetzt. Damit werden dann in Folge beide Frames (Peering + Broadcast) gesendet.
Bin mir nicht sicher ob das die richtige Richtung ist... würde sendFrame() das Device und den Bus zu lange Blockieren? (@sendFrame(), "TODO: non-blocking") :)
Müsste man sendFrame() komplett umbauen? Oder eine sende Warteschlange bauen?  :o

Gruß,
Thomas

Thorsten Pferdekaemper

Hi,
tja, so genau weiß ich das jetzt auch nicht mehr. Ich glaube, dass die Besonderheit beim Broadcast vor Allem war, dass kein ACK zurück kommt. Man weiß also im Prinzip sowieso nicht, ob der Broadcast angekommen ist. Eigentlich müsste man nicht einen Broadcast, sondern eine gezielte Message an die Zentrale machen. Ich dachte auch, dass das so wäre (siehe https://github.com/ThorstenPferdekaemper/HBWired/issues/2). Allerdings halt nur bei HBW und nicht bei HMW.
Von wegen Bus blockieren: Ja, vielleicht. Aber was soll man auch anderes machen?
Gruß,
   Thorsten
FUIP

loetmeister

Hi Thorsten,

Ich meinte eigentlich "issue #2".. scheint das ich den falschen Link kopiert hatte.  ???

FHEM wertet den Broadcast ja aus, das wäre eigentlich ausreichend um dort den aktuellen Status zu haben.
return 0;  // we do not wait for an ACK, i.e. always ok

Was mich stört ist das bei "HBWDevice::sendKeyEvent" der Rückgabewert der Funktion, die des "sendKeyEvent" an die Broadcast Adresse ist, wichtiger wäre aber das Erfolgreiche versenden der peering KeyEvents (HBWLinkKey::sendKeyEvent)...

Gruß,
Thomas

Thorsten Pferdekaemper

Zitat von: loetmeister am 18 Dezember 2018, 00:34:50
Ich meinte eigentlich "issue #2".. scheint das ich den falschen Link kopiert hatte.  ???
Ja, das dachte ich mir schon.

Zitat
FHEM wertet den Broadcast ja aus, das wäre eigentlich ausreichend um dort den aktuellen Status zu haben.
Von dieser Seite aus betrachtet ist es tatsächlich egal. Es macht aber einen Unterschied, da die Zentrale ein ACK sendet, wenn sie direkt angesprochen wird. Bei einem Broadcast passiert das jedoch nicht. Wäre ja auch nicht gerade sinnvoll.

Zitat
Was mich stört ist das bei "HBWDevice::sendKeyEvent" der Rückgabewert der Funktion, die des "sendKeyEvent" an die Broadcast Adresse ist, wichtiger wäre aber das Erfolgreiche versenden der peering KeyEvents (HBWLinkKey::sendKeyEvent)...
Da hast Du Recht. Ich habe mir auch mal angesehen, wie das in HBWKey.cpp verwendet wird. Wenn man das Ergebnis von sendKeyEvent so hinbekommt, dass es nur dann "erfolgreich" ist, wenn es alle mitbekommen haben, dann wird HBWKey::loop das automatisch wiederholen, bis es komplett erfolgreich ist. Allerdings müsste man auch unterscheiden zwischen 1 (Bus belegt) und 2 (kein ACK). Bei "2" dürfte man nicht wiederholen, da das sonst ggf. ewig dauert.

Gruß,
   Thorsten
FUIP

loetmeister

Hallo,

kurze Info zum Beitrag https://forum.fhem.de/index.php/topic,22952.msg835410.html#msg835410
Mit der aktuellen Arduino IDE 1.8.8 habe ich noch immer Probleme... code zu klein oder Segmentation fault.
https://github.com/arduino/Arduino/issues/7949
Falls jemand das selbe Problem hat. Man kann bei IDE 1.8.8 bleiben, wenn man den board manager v1.6.21 nutzt. (tools > board:... > boards manager...)

Gruß,
Thomas

loetmeister

Hi Thorsten,

in einem alten Fork von HBWired ist mir die Ergänzung "SIFS" Time ins Auge gesprungen:
https://github.com/katze2k/HBWired/commit/465be7d6e38867f0f6c17f4e39b96a98210416dd
//Short Interframe Space
#define SIFS_TIME 3 // laut protokoll 7 ms


In der "HMW RS485 Protokollbeschreibung" ist SIFS als unbekannt aufgeführt. Ich kenne den Ursprung der 3 oder 7 ms nicht, aber wäre es dennoch etwas, was in den aktuellen Code kommen sollte? Ich hab es bei mir mal test weise aufgenommen, habe aber noch zu wenig Module am Bus um Kollisionen zu erzeugen und wirkliche Änderungen festzustellen...  ::)

Gruß,
Thomas

Thorsten Pferdekaemper

Hi,
ich habe keine Ahnung, wo die 3 bzw. 7ms herkommen. Ich habe mal was von 50ms gelesen und dass das auch nur die Zeit ist, bis ein ACK gesendet wird. ...wobei mir die 50ms ziemlich viel vorkommen.
Ich weiß allerdings nicht so recht, was das bringen soll. Ich denke mal, dass es zumindest so wie katze2k das eingebaut hat, es zu ziemlichem Chaos führen kann. Es kann natürlich auch sein, dass ich das nicht ganz durchdacht habe. Ich würde es nicht einbauen.
Gruß,
   Thorsten
FUIP

loetmeister

Hi,

ok, danke für die Einschätzung Thorsten :)
Ich habs wieder raus genommen.

Habe auch noch ein paar Änderungen in meinem Git Repository, würde die nächsten Tage einen Pull request stellen.
Habe eine Umbenennung HBW-IO-10-Dim-6 -> HBW-SC-10-Dim-6, welche den Pfad im Wiki (https://wiki.fhem.de/wiki/HomeMatic_Wired#Aktoren_/_Sensoren) kaputt gemacht hat...  ::)

Gruß,
Thomas

Thorsten Pferdekaemper

Zitat von: loetmeister am 12 Februar 2019, 22:59:24
Habe eine Umbenennung HBW-IO-10-Dim-6 -> HBW-SC-10-Dim-6, welche den Pfad im Wiki (https://wiki.fhem.de/wiki/HomeMatic_Wired#Aktoren_/_Sensoren) kaputt gemacht hat...  ::)
Ich hab's repariert.
Gruß,
   Thorsten
FUIP

loetmeister

Hallo,

bastel noch immer an HBW-SC-10-Dim-6...  ein paar Details gefallen mir an der Software noch nicht. Die 0-10V und PWM Dimmer Endstufen laufen aber.  ;)
Die Elektronik ist vom 'breadboard' zum PCB gewandert. Drei Platinen: Controller ganz oben, dann 6x Analog/PWM Kanal, unten die Basisplatine mit 10 Eingängen und Spannungsversorgung - 12 und 5 Volt (daher ist der DC-Wandler auf der Controllerplatine nicht bestückt).
In Summe 48 Schraubklemmen...  :o

https://github.com/loetmeister/HBWired/tree/master/HBW-SC-10-Dim-6

Gruß,
Thomas

loetmeister

Hallo,

habe mal angefangen den Stellantrieb-Regler für thermoelektrische Ventile von HGlaser (HBW_CC_VD2_FM, https://forum.fhem.de/index.php/topic,22952.msg798766.html#msg798766) auf die Aktuelle lib zu portieren...
Zum testen sind es zwei Kanäle, Ziel ist 8 Kanäle zu haben. Also jeweils 8 PID Regler, Ventilsteuerausgänge, eventuell auch Temperatursensoren...

Aktueller Stand - ohne den Änderungen an "HBWired.h/cpp"
HBW-CC-VD-8 (z.Z. eher HBW-CC-VD-2): https://github.com/loetmeister/HBWired/tree/master/HBW-CC-VD-8

Die ganze Sache ist leider alles andere als Banal, zumindest für meine einschränkten C++ Kenntnisse....  :-\

Kanäle für PID Regler und Ventilsteuerung laufen schon mal...
Um die PID Regler mit einem Temperatur Sensor zu peeren hat Harald in die Trickkiste gegriffen und die Info Message (i-Message) benutzt (denke das war im Standard nicht vorgesehen?) HM Wired hat den Nachrichten type="0x41" nicht, welcher einen Event mit Messwerten überträgt...

Um es auch erst mal mit der Info Message zu lösen, habe ich entsprechende Klassen von HBWLinkSender und HBWLinkReceiver erstellt, mit den Funktionen receiveIMEvent & sendIMEvent, analog zu receive- & sendKeyEvent.
Leider ist dies nun Teil der Basisklasse und die bisherigen HBWLinkSender und HBWLinkReceiver Klassen wie HBWLinkKey, HBWLinkSwitchSimple, etc. passen nicht mehr.
Also bisher nicht so schön gelöst...  ::)


HBWired.hclass HBWLinkReceiver {
  public:
  virtual void receiveKeyEvent(HBWDevice* device, uint32_t senderAddress, uint8_t senderChannel, uint8_t targetChannel, uint8_t keyPressNum, boolean longPress) = 0;
  virtual void receiveIMEvent(HBWDevice* device, uint32_t senderAddress, uint8_t senderChannel, uint8_t targetChannel, uint8_t length, uint8_t const * const data) = 0;
};


HBWired.cppvoid HBWDevice::receiveIMEvent(uint32_t senderAddress, uint8_t srcChan, uint8_t dstChan, uint8_t length, uint8_t const * const data) {
    if(linkReceiver)
        linkReceiver->receiveIMEvent(this, senderAddress, srcChan, dstChan, length, data);
};



Was noch fehlt/nicht geht:
- Ziel Temperatur für PID setzten
- Peering mit externen Aktoren für Ventilsteuerung
- 1-Wire Temperatursensoren


Gruß,
Thomas