FHEM Forum

FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: Thorsten Pferdekaemper am 27 April 2014, 00:13:17

Titel: Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 27 April 2014, 00:13:17
Hallo,
ich habe mal angefangen, mir über "Homematic Wired Homebrew" Gedanken zu machen. Die Idee ist, ähnlich wie es das schon für Funk-Homematic gibt, auch eigene Geräte für's Kabel zu machen. Das Schöne ist, dass das viel einfacher zu sein scheint. (Zumindest zu den ersten Erfolgserlebnissen.)
Ich weiß, dass Dirk da auch dran ist. Ich habe die meisten Informationen auch von ihm. Speziell das hier ist sehr nützlich:
http://forum.fhem.de/index.php?action=dlattach;topic=10027.0;attach=2441 (http://forum.fhem.de/index.php?action=dlattach;topic=10027.0;attach=2441)

Mein momentanes Experimentier-Setup besteht im Wesentlichen aus einem Arduino Uno, einem MAX487, einem HMW-LC-Sw2-DR mit passendem Netzteil und ein paar Kabeln. (Siehe Bild.) Zumindest kann ich damit schon die Messages sehen (und dank Dirks Doku auch verstehen), die vom Sensor/Aktor geschickt werden.

Damit ich die normale serielle Schnittstelle für Debug-Ausgaben benutzen kann, verwende ich für die RS485 die Pins 2 bis 5 und die SoftwareSerial Library. (Theoretisch ginge es sogar mit nur drei Pins.) Mit folgendem Sketch kann sieht man die Nachrichten im seriellen Monitor.
// Testprogramm RS485

#define PinDI 2
#define PinDE 3
#define PinRE 4
#define PinRO 5
#define PinLED 13

// RS485 uses SoftSerial
#include <SoftwareSerial.h>

SoftwareSerial rs485(PinRO, PinDI); // RX, TX

void setup() {
   
  // Pin 2: Driver Input
  pinMode(PinDI, OUTPUT);
  digitalWrite(PinDI, LOW);
  // Pin 3: DE
  pinMode(PinDE, OUTPUT);
  digitalWrite(PinDE, LOW);
  // Pin 4: !RE
  pinMode(PinRE, OUTPUT);
  digitalWrite(PinRE, LOW);
  // Pin 5: Receiver Output
  pinMode(PinRE, INPUT); 
  // Vorerst nur empfangen und ueber normale serielle
  // Schnittstelle weitergeben
  pinMode(PinLED, OUTPUT);
 
  // SoftSerial konfig
  rs485.begin(19200);
 
  Serial.begin(57600);
  Serial.println("Ready...");
}


void loop() {
 
  signalLED();
  if (rs485.available()) {
    byte c = rs485.read();
    if( c == 0xFD ) Serial.println();
    char buf[10];
    sprintf(buf, "%02X-", c);
    Serial.write(buf);
  };
  if( rs485.overflow()) Serial.println("Overflow"); 
}


void signalLED(){
  static unsigned long lasttime = 0;
  static byte state = 0;
  unsigned long time = millis();

  if(time-lasttime >= 1000){
    digitalWrite(PinLED, state);
    state = 1 - state;
    lasttime = time; 
  }   

};


Es gab nur ein kleines Problemchen mit der SoftwareSerial Library. Standardmäßig verwendet die keine Parity-Bits. Zumindest zum Empfangen bekommt man das mit folgenden kleinen Änderungen an SoftwareSerial.cpp hin:
/* static */
inline void SoftwareSerial::tunedDelay(uint16_t delay) {
  uint8_t tmp=0;

  asm volatile("sbiw    %0, 0x01 \n\t"
    "ldi %1, 0xFF \n\t"
    "cpi %A0, 0xFF \n\t"
    "cpc %B0, %1 \n\t"
    "brne .-10 \n\t"
    : "+w" (delay), "+a" (tmp)       // <<<<< hier heissts im Original : "+r" (delay...
    : "0" (delay)
    );
}

und
void SoftwareSerial::recv()
{

#if GCC_VERSION < 40302

[...]

      else // else clause added to ensure function timing is ~balanced
        d &= noti;
    }

    // PFE skip parity bit
    tunedDelay(_rx_delay_stopbit);     // <<<<< das ist neu

    // skip the stop bit
    tunedDelay(_rx_delay_stopbit);
    DebugPulse(_DEBUG_PIN2, 1);

[...]


Natürlich wird das Parity-Bit nicht ausgewertet und beim Senden kommt es noch nicht mit, aber für's Empfangen reicht's.

Ich weiß, dass das noch nichts wirklich großartiges ist, aber ein Anfang ist gemacht.

Gruß,
    Thorsten



Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 27 April 2014, 10:52:11
Hallo Thorsten,

Cool. Da hat es dir wohl in den Fingern geribbelt? :)
Hast den Code neu entwickelt oder konntest du den Code von mir nach C++/Arduino portieren?
Kannst mir das ja mal zukommen lassen. Dann können wir da gemeinsam weiter machen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 27 April 2014, 13:06:35
Zitat von: Dirk am 27 April 2014, 10:52:11Cool. Da hat es dir wohl in den Fingern geribbelt? :)
Heftigst...
ZitatHast den Code neu entwickelt oder konntest du den Code von mir nach C++/Arduino portieren?
Naja, so viel gab's da nicht zu entwickeln. Im Prinzip gebe ich ja nur nach Serial weiter, was von SoftwareSerial reinkommt. Den Rest (Baudrate, Parity, "0xFD") habe ich von Deiner Protokolldoku übernommen.
Die notwendigen Änderungen an SoftwareSerial habe ich mir dann zusammengesucht, nachdem es zuerst nicht funktionieren wollte.
Ich denke aber, dass ich Deinen Code noch auf Arduinisch übersetzen kann. Das dürfte nur ein bisschen dauern.
Zitat
Kannst mir das ja mal zukommen lassen. Dann können wir da gemeinsam weiter machen.
Coding siehe meinen ersten Post im Thread. Von wegen gemeinsam weiter: Ja, das war so gedacht.

Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 04 Mai 2014, 21:17:10
Hallo Thorsten,hallo Dirk,

ich bin auch mit der Entwicklung eines Homebrew-Modul für HMW beschäftigt. Ich habe mir als Basis allerdings das openHC-Projekt ausgesucht, da dort schon ein Atmega88 verwendet wird. Aktuell bin ich aber noch dabei die HW und SW-Plattform anzupassen. Aus Zeitgründen geht das allerdings etwas langsamer voran.

Mein Testaufbau sieht ähnlich aus: Netzteil, 2x HMW-SW-LC2-DR, Digitus DA-70157.

Könnten wir uns hier nicht zusammen tun?

Gruß Rene
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 05 Mai 2014, 12:13:57
Zitat von: reneFHEM am 04 Mai 2014, 21:17:10Ich habe mir als Basis allerdings das openHC-Projekt ausgesucht,
Das kannte ich bisher noch nicht. Sieht interessant aus, zumindest gibt es da schonmal die Designs, die UP-Dosen etc. passen. Von der Hardware her vertraue ich allerdings lieber Dirk als mir selbst.
Zitatda dort schon ein Atmega88 verwendet wird.
Ich bin mir nicht sicher, ob 8kB Flash Speicher ausreichen. Das HMW-Protokoll kann ja schon einiges und 8kB (incl. Bootloader...) ist nicht gerade viel.
ZitatAktuell bin ich aber noch dabei die HW und SW-Plattform anzupassen. Aus Zeitgründen geht das allerdings etwas langsamer voran.
Geht mir nicht anders. Wahrscheilich geht's bei mir erst fruehestens am 12.Mai weiter. ...aber ein bisschen "Projektmanagement" geht vorher.
ZitatKönnten wir uns hier nicht zusammen tun?
Klar, das faende ich gut. Dirk wollte ein git-Repository dafuer anlegen.
@Dirk: Hast Du das schon gemacht?
Ansonsten waere es vielleicht gut, wenn wir ausmachen, wer sich um was kuemmert. Wie schon gesagt wollte ich damit anfangen, das HMW-Protokoll nach "Arduinisch" zu uebersetzen. Ich wollte das mit einem normalen Arduino Uno machen, es duerfte aber einfach sein, das auf andere Atmega-Plattformen zu uebertragen. Was die Hardware angeht, kann ich einfache Sachen zusammenstecken und -loeten, aber was ich mache wird normalereise zu gross, um es tatsaechlich einsetzen zu koennen. Das ueberlasse ich dann lieber anderen.

Gruss,
    Thorsten

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 05 Mai 2014, 20:58:48
Hallo Thorsten,

welche HW gebraucht wird, dafür habe ich auch noch kein Gefühl.

Zitatich einfache Sachen zusammenstecken und -loeten, aber was ich mache wird normalereise zu gross, um es tatsaechlich einsetzen zu koennen
Zusammenstecken und Löten kann ich auch, aber richtige Platinen (womöglich noch mit SMD) habe ich schon länger nicht mehr gebaut. Das wird sicher nicht auf Anhieb funktionieren :-)

Deshalb werde ich mir mal ein Arduino Uno besorgen. Wenn es damit läuft, kann man immer noch sehen, welcher Atmega tatsächlich gebraucht wird.

ZitatAnsonsten waere es vielleicht gut, wenn wir ausmachen, wer sich um was kuemmert.
Sehe ich auch so. Hier müssten wir uns separat abstimmen, wenn es das Repository gibt.

Gruß Rene
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 05 Mai 2014, 21:41:46
Zitat von: reneFHEM am 05 Mai 2014, 20:58:48Zusammenstecken und Löten kann ich auch, aber richtige Platinen (womöglich noch mit SMD) habe ich schon länger nicht mehr gebaut. Das wird sicher nicht auf Anhieb funktionieren :-)
Da wuerde ich auf Dirk vertrauen. Das sieht bei ihm professionell aus.
ZitatDeshalb werde ich mir mal ein Arduino Uno besorgen. Wenn es damit läuft, kann man immer noch sehen, welcher Atmega tatsächlich gebraucht wird.
Vergiss den RS485-Bustreiber nicht.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 05 Mai 2014, 22:08:55
ZitatVergiss den RS485-Bustreiber nicht.
Den habe ich schon da :-)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 05 Mai 2014, 23:58:35
Zitat von: Thorsten Pferdekaemper am 05 Mai 2014, 12:13:57
Das HMW-Protokoll kann ja schon einiges und 8kB (incl. Bootloader...) ist nicht gerade viel.Geht mir nicht anders.
Zumindest die fertigen Module haben alle einen Atmega32 on Board. Wenn man die Module auch selber miteinander interagieren lassen möchte, Sprichwort Peering, dann braucht es auch noch Flash-Speicher. 1K wie beim Atmega32x sind schon ok. Weniger würde ich da nicht einplanen.

Zitat
@Dirk: Hast Du das schon gemacht?
Nein, noch nicht. Zeitlich sieht es bei mir im Moment auch nicht soo gut aus.
Ich werde das Repo aber diese Woche wenigstens mal anlegen.

Zitat
Wie schon gesagt wollte ich damit anfangen, das HMW-Protokoll nach "Arduinisch" zu uebersetzen.
In dem "alten" Code von mir ist das Protokoll ja schon fertig. Das muss du "nur" noch von Bascom in C++ portieren. :)

Zitat von: reneFHEM am 05 Mai 2014, 20:58:48
welche HW gebraucht wird, dafür habe ich auch noch kein Gefühl.
Ein kleiner Arduino, z.B ein Pro Micro sollte als Hardware vollkommen ausreichen.
Dann noch z.B. ein Max485 an den UART und schon kann es losgehen.
Für Debug-Ausgaben dann reicht dann ein Soft-UART.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 06 Mai 2014, 11:10:41
Zitat von: Dirk am 05 Mai 2014, 23:58:35Wenn man die Module auch selber miteinander interagieren lassen möchte, Sprichwort Peering, dann braucht es auch noch Flash-Speicher. 1K wie beim Atmega32x sind schon ok.
Du meinst EEPROM, oder?
ZitatIn dem "alten" Code von mir ist das Protokoll ja schon fertig. Das muss du "nur" noch von Bascom in C++ portieren. :)
Schon klar, aber auch das braucht seine Zeit. Vor Allem wuerde ich das gerne ordentlich machen, also nicht einfach uebersetzen.
ZitatDann noch z.B. ein Max485 an den UART und schon kann es losgehen.
Für Debug-Ausgaben dann reicht dann ein Soft-UART.
Vorerst wuerde ich es erstmal dabei belassen, dass ich den RS485 per Soft-UART ansteuere. Dann kann ich den Arduino weiterhin ganz normal ueber USB am PC lassen. Spaeter wuerde ich dann das Coding flexibel gestalten. Zumindest soweit der Plan.

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 06 Mai 2014, 12:55:31
Zitat von: Thorsten Pferdekaemper am 06 Mai 2014, 11:10:41
Du meinst EEPROM, oder?
Selbstverständlich, keiner Verschreiber :)

Vorerst wuerde ich es erstmal dabei belassen, dass ich den RS485 per Soft-UART ansteuere. Dann kann ich den Arduino weiterhin ganz normal ueber USB am PC lassen.
Zum Debugen ist das ok.
Am Ende sollte die Firmware auch über den Bus einspielbar sein.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 06 Mai 2014, 13:00:20
Zitat von: Dirk am 06 Mai 2014, 12:55:31Am Ende sollte die Firmware auch über den Bus einspielbar sein.
Klar, aber eins nach dem Anderen.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 10 Mai 2014, 21:26:39
Der Arduino Uno ist bei mir Einsatzbereit. Ich kann also auch mit machen. Ich würde ja erstmal deb HMW-LC-SW2-DR nachbauen, da wir ja alle so ein Modul als Referenz besitzen.

Da könnte ich mich ja erstmal um das Userinterface kümmern. Also die Modis die über die beiden Tasten einstellbar sind. Oder brauchst Du Hilfe bei der Portierung des Stacks?

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 11 Mai 2014, 12:57:32
Zitat von: reneFHEM am 10 Mai 2014, 21:26:39
Der Arduino Uno ist bei mir Einsatzbereit. Ich kann also auch mit machen. Ich würde ja erstmal deb HMW-LC-SW2-DR nachbauen, da wir ja alle so ein Modul als Referenz besitzen.
Ich bin momentan (soweit es die Zeit zwischendurch erlaubt) dabei, eine Art IO-Modul zu bauen. Sozusagen ein HMW-IO-8-FM. Das liegt einfach daran, dass Dirks bisherige Sourcen schon etwas ähnliches machen.

ZitatDa könnte ich mich ja erstmal um das Userinterface kümmern. Also die Modis die über die beiden Tasten einstellbar sind.
Daran hatte ich bisher gar nicht gedacht. Mir würde es eigentlich ausreichen, wenn man das Teil über den Bus "programmieren" kann. ...aber mach' mal.

ZitatOder brauchst Du Hilfe bei der Portierung des Stacks?
Ich denke, dass ich das hinbekomme. Ich werde halt noch ein paar Tage brauchen. Je nach Wetter kann es sein, dass ich nächstes Wochenende was lauffähiges habe.

Bisher habe ich die folgenden Fragen/ offene Punkte:  (Es sind noch ein paar mehr...)

Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 11 Mai 2014, 13:55:29
Hallo zusammen,
ich beschäftige mich auch seit einigen Tagen mit dem Thema "Homebrew HMW-device mit Arduino" und war deshalb total begeistert, als ich diesen Thread gefunden habe.

Ich verwende einen Arduino Uno, den ich direkt per USB mit FHEM verbinde (erstmal zum Testen, RS485 kommt später). Das Device im FHEM ist dementsprechend /dev/ttyACM0.
Was bisher funktioniert: mit "define client HM485 000000AB" und "get client info" wird der Client angelegt und Infos zu HW-Typ, Version und Seriennummer abgefragt. Der Arduino-Client liefert diese Infos zurück (gibt sich als HMW_IO_12_Sw7_DR aus), so dass im FHEM 12 keys und 7 switches angelegt werden. Soweit so gut. Jetzt zu den Problemen.

Schalten der Ausgänge:
Beim Schalten der Ausgänge (z.B. client_14 auf ON) schickt FHEM zunächst 3x eine Botschaft raus, deren Bedeutung mir nicht ganz klar ist. Bei der anschließenden Botschaft wird der Befehl "x" verwendet, laut Protokoll-Doku hätte ich hier "s" erwartet. Ist das eine "normale" Kommunikation oder läuft hier irgend etwas schief, weil der Client noch nicht vollständig gepairt ist?

2014.05.11 13:06:09 3: HM485_LAN: TX: (93) I[0](0,F,B)(18) 00000001 -> 000000AB [2] FF(?)
2014.05.11 13:06:09 3: HM485_LAN: ACK: (93)
2014.05.11 13:06:09 3: HM485_LAN: Response: (93)
2014.05.11 13:06:09 3: HM485_LAN: TX: (94) I[1](0,F,B)(1A) 00000001 -> 000000AB [2] FF(?)
2014.05.11 13:06:09 3: HM485_LAN: ACK: (94)
2014.05.11 13:06:09 3: HM485_LAN: Response: (94)
2014.05.11 13:06:09 3: HM485_LAN: TX: (95) I[2](0,F,B)(1C) 00000001 -> 000000AB [2] FF(?)
2014.05.11 13:06:09 3: HM485_LAN: ACK: (95)
2014.05.11 13:06:09 3: HM485_LAN: Response: (95)
2014.05.11 13:06:09 3: HM485_LAN: TX: (96) I[3](0,F,B)(1E) 00000001 -> 000000AB [5] 78(x) 0DC8
2014.05.11 13:06:09 3: HM485_LAN: ACK: (96)
2014.05.11 13:06:09 3: HM485_LAN: Response: (96) 780DC8


Lesen der Eingänge:
Wird am Arduino eine angeschlossene Taste gedrückt, verschickt der Client die folgende Botschaft:
2014.05.11 13:16:34-681 3: HM485d: Rx:  I[2](0,Y,F,B)(9C) 000000AB -> FFFFFFFF [6] 4B(K) 01000A {8DFA}


In der FHEM-Zentrale passiert allerdings nichts (die Zeile steht auch nicht im allgemeinen Logfile, sondern nur in dem Logfile für das HM485-Gateway). Auch hier wieder die Frage, ob sich der Client "normal" verhält und es an den Einstellungen im FHEM liegt, oder ob die Botschaften von Original-HMW-Clients anders aussehen.


Zusammengefasst habe ich folgende Fragen:
1. Hat jemand Interesse an dem Arduino-Code? Dann würde ich das ganze nochmal etwas aufräumen, den Code mehr kommentieren und posten. Ist allerdings nichts was wirklich ausgereift ist, sondern nur schnell zusammen geschrieben, um die Kommunikation testen zu können.
2. Hat vielleicht jemand die Rohdaten von einer Kommunikation zwischen FHEM und Aktor bzw. FHEM und Sensor?
3. Sind die Quellen für das HMW-Gateway, die im Wiki angegeben sind (https://github.com/kc-GitHub/FHEM-HM485), noch aktuell, oder gibt es mittlerweile irgendwo Arbeitsstände mit weiteren Funktionen?
4. Irgendwo im Netz habe ich die Protokolldoku von Dirk gefunden. Besten Dank dafür - großartige Hilfe! Ist die Version 14 vom 04.04.2012 die aktuellste die es gibt? Besonders interessieren mich etwas mehr Details zum Discovery-Mode, aber dazu stelle ich später vielleicht noch ein paar Fragen. Eins nach dem Anderen.


Besten Dank & schöne Grüße
Markus

PS: Sorry, dass meine Fragen so protokolllastig sind - hab gesehen, dass es dazu auch einen eigenen Thread gibt. Aber wegen dem Arduino/Homebrew-Thema passt es hier vielleicht auch rein.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: T.ihmann am 11 Mai 2014, 14:20:34
Ja ich hätte Interesse an dem Arduino Code. Sollten wir evtl. die Aktivitäten zusammenfassen und den Arduino Code auch ins Github einpflegen?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 11 Mai 2014, 21:32:16
ZitatSozusagen ein HMW-IO-8-FM
Das und das HMW-LC-SW2-DR sind die beiden die ich aktuell benötigen würde. Die Möglichkeit das Modul ohne FHEM zu betreiben ist für mich wichtig. Deshalb auch das HMW-LC-SW2-DR. FHEM soll nur die "Komfortsteuerungen" zur Verfügung stellen.

ZitatDas ganze sollte auch einen eigenen Bootloader bekommen.
Diese Frage habe ich mir auch schon gestellt. Insbesondere kann der Bootloader wahrscheinlich nur auf der realen HW entwickelt/getestet werden, da Arduino IMHO einen speziellen Bootloader verwendet. 

ZitatInsbesondere ist mir nicht klar, woher FHEM später wissen soll, wo im EEPROM welche Konfig-Option liegt.
Muss FHEM das wissen oder nur die Firmware auf dem Modul ?

ZitatSollten wir evtl. die Aktivitäten zusammenfassen und den Arduino Code auch ins Github einpflegen?
Das sollten wir auf jeden Fall :-). Dirk wollte sich um ein Repository kümmern.

Gruß Rene
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 11 Mai 2014, 22:22:16
Hallo,
für alle die es interessiert hänge ich mal meinen Arduino-Code an (Projekt + Library). Vielleicht kann ja jemand was davon gebrauchen. Die Frage nach einer aktuellen Protokoll-Doku hat sich durch den Link im ersten Post auch erledigt. Hatte ich vorher noch nicht gesehen...
Mit dieser für mich neuen Doku werde ich mal versuchen, den Discovery-Mode zu implementieren. Vielleicht werden damit auch die Tastendrücke richtig gemeldet?
ZitatSollten wir evtl. die Aktivitäten zusammenfassen und den Arduino Code auch ins Github einpflegen?
Wär großartig! Ich hab auf jeden Fall Interesse, dass Ganze weiter zu entwickeln.

Beste Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 12 Mai 2014, 08:03:07
Zitat von: reneFHEM am 11 Mai 2014, 21:32:16Die Möglichkeit das Modul ohne FHEM zu betreiben ist für mich wichtig. Deshalb auch das HMW-LC-SW2-DR. FHEM soll nur die "Komfortsteuerungen" zur Verfügung stellen.
Klar, sonst bräuchte man ja nicht sowas wie das Homematic-Protokoll. Ich meinte damit nur, dass man das Programmieren (z.B. was ist Ein- oder Ausgang, irgendwelche Schaltzeiten, Peering) der Module über eine Zentrale (wie FHEM) vornehmen kann. Danach können dann die Module alleine arbeiten, auch wenn FHEM oder was auch immer die Zentrale ist mal ausfällt.
ZitatDiese Frage habe ich mir auch schon gestellt. Insbesondere kann der Bootloader wahrscheinlich nur auf der realen HW entwickelt/getestet werden, da Arduino IMHO einen speziellen Bootloader verwendet.
Ein Arduino kommt mit einem vorgefertigten Bootloader, aber soweit ich weiß kann man den mit einem Programmer auch umschießen.
ZitatMuss FHEM das wissen oder nur die Firmware auf dem Modul ?
Soweit ich verstanden habe, verwendet Homematic kaum Funktionen im Protokoll, die das EEPROM indirekt verändern. Statt dessen wird das EEPROM über spezielle Kommandos ausgelesen, in der Zentrale geändert und dann über RS485 wieder geschrieben. D.h. die Zentrale muss ziemlich genau wissen, wo was im EEPROM liegt, es hat aber den Vorteil, dass man sich einiges an Programmzeilen im Modul selbst spart.

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 12 Mai 2014, 08:31:14
Zitat von: MarkusO am 11 Mai 2014, 22:22:16für alle die es interessiert hänge ich mal meinen Arduino-Code an (Projekt + Library).
Ich bin auch gerade dabei, etwas ähnliches zu bauen. Wenn ich was Lauffähiges habe, dann stelle ich's auch hier rein. Mal sehen, wie man das dann verheiraten kann. 
ZitatMit dieser für mich neuen Doku werde ich mal versuchen, den Discovery-Mode zu implementieren.
Das trifft sich gut, davon wollte ich nämlich erstmal die Finger lassen. 
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 12 Mai 2014, 11:07:20
Zitat von: Thorsten Pferdekaemper am 11 Mai 2014, 12:57:32
Es gibt immer noch kein git-Repository. (@Dirk: ?)
Ich denke das ich das heute schaffen werde.

ZitatDas ganze sollte auch einen eigenen Bootloader bekommen. Es gibt dazu auch schon (Bascom)-Sourcen, aber mir ist noch nicht klar, wie ich das tatsächlich auf "Arduinisch" bekomme.
Für den Arduino-Bootloader gibt es auch Beispielcode. Den könnte man erweitern. Der Bascom-Bootloader kann übrigens auch noch keine Kommunikation über den Bus.

ZitatIch habe etwas den Überblick verloren, wie weit die Anbindung von Homematic Wired an FHEM gediehen ist.
Da habe ich die letzte Zeit leider nicht viel geschaft.
Aber, ich war am Samstag auf dem Homematic-Userteffen. Da wurden einige interessante Dinge vorgestellt. Unter anderem auch die mögliche Freigabe des  hs485d und des rfd von der CCU. Das betrifft die Nutzung der Binärfiles auf externer Hardware wie dem Raspberry Pi usw. Im Gespräch waren ARM und x86 Plattformen. Ich vermute aber das die Fritzbox und MacOS hier außen vorleiben würden. Daher bin ich grade am überlegen ob und wie ich das ganze weiterentwickle.

ZitatInsbesondere ist mir nicht klar, woher FHEM später wissen soll, wo im EEPROM welche Konfig-Option liegt.
In den Device-Files ist die Adresszuordnung abgelegt. FHEM weis also welche EEprom-Adresse mit welchem Wert beschriebe werden muss. Im Prinzip das Gleiche wie das Registerhandling bei HM-Funk (BidCos).

Zitat von: MarkusO am 11 Mai 2014, 13:55:29
Schalten der Ausgänge:
Beim Schalten der Ausgänge (z.B. client_14 auf ON) schickt FHEM zunächst 3x eine Botschaft raus, deren Bedeutung mir nicht ganz klar ist.
Das sieht für mich auch etwas merkwürdig aus.
Kannst du mal den Abschnitt posten der während des Anlernen und bei get info ober den Bus gehen?

ZitatBei der anschließenden Botschaft wird der Befehl "x" verwendet, laut Protokoll-Doku hätte ich hier "s" erwartet. Ist das eine "normale" Kommunikation oder läuft hier irgend etwas schief, weil der Client noch nicht vollständig gepairt ist?
"x" sollt in diesem Fall korrekt sein. "s" sendet die Zentrale soweit ich es noch in Erinnerung habe nur an einen gepeerten aktor.

ZitatWird am Arduino eine angeschlossene Taste gedrückt, verschickt der Client die folgende Botschaft:
2014.05.11 13:16:34-681 3: HM485d: Rx:  I[2](0,Y,F,B)(9C) 000000AB -> FFFFFFFF [6] 4B(K) 01000A {8DFA}


In der FHEM-Zentrale passiert allerdings nichts (die Zeile steht auch nicht im allgemeinen Logfile, sondern nur in dem Logfile für das HM485-Gateway).
Dein Device hat 000000AB als Adresse? So wie ich das herausgefunden habe ist der Adressraum 00000001 - 000000FF für das Interface der Zenralen vorgesehen. Auch wenn aktuell vor allem an der CCU1/2 nur eine Wired-Interface unterstützt werden.
Und ich meine dass Messages von anderen Zentralen ignoriert werden.

Zitat1. Hat jemand Interesse an dem Arduino-Code? Dann würde ich das ganze nochmal etwas aufräumen, den Code mehr kommentieren und posten. Ist allerdings nichts was wirklich ausgereift ist, sondern nur schnell zusammen geschrieben, um die Kommunikation testen zu können.
Ich guck mir das auf alle Fälle auch mal an.

Zitat3. Sind die Quellen für das HMW-Gateway, die im Wiki angegeben sind (https://github.com/kc-GitHub/FHEM-HM485), noch aktuell, oder gibt es mittlerweile irgendwo Arbeitsstände mit weiteren Funktionen?
Soweit ja. Es gibt dort noch eine DEV-Branch die ein kleines Stück weiter ist. Aber auch noch Bugs enthält.

Zitat4. Irgendwo im Netz habe ich die Protokolldoku von Dirk gefunden. Besten Dank dafür - großartige Hilfe! Ist die Version 14 vom 04.04.2012 die aktuellste die es gibt? Besonders interessieren mich etwas mehr Details zum Discovery-Mode, aber dazu stelle ich später vielleicht noch ein paar Fragen.
Das ist nicht mehr die neuste. Die letzte die ich veröffentlicht hatte ist hier:
http://forum.fhem.de/index.php/topic,10027.msg56562.html#msg56562

Da sollten auch deine Fragen zum Discovery-Mode beantwortet werden.
Aus Informationen vom Samstag kommen hier noch ein paar Ergänzungen rein.

Zitat von: reneFHEM am 11 Mai 2014, 21:32:16
Insbesondere kann der Bootloader wahrscheinlich nur auf der realen HW entwickelt/getestet werden, da Arduino IMHO einen speziellen Bootloader verwendet.
Auch der Bootloader den Arduino verwendet ist nix besonderes. Es müssen halt die vorher spezifizierten Übergangsparameter eingehalten werden.

Zitat von: Thorsten Pferdekaemper am 12 Mai 2014, 08:03:07
Ein Arduino kommt mit einem vorgefertigten Bootloader, aber soweit ich weiß kann man den mit einem Programmer auch umschießen.
Das ist korrekt. Und wenn die Module dann auch über den Bus updatebar sein sollen, muss man in den Arduino dann einen eigenen Bootloader "brennen". Man das dann übrigens auch mit einem zweiten Arduino welcher dann den Job des ISP-Programmers übernimmt, erledigen. Daher sollte das dann kein großes Problem werden.

ZitatSoweit ich verstanden habe, verwendet Homematic kaum Funktionen im Protokoll, die das EEPROM indirekt verändern. Statt dessen wird das EEPROM über spezielle Kommandos ausgelesen, in der Zentrale geändert und dann über RS485 wieder geschrieben. D.h. die Zentrale muss ziemlich genau wissen, wo was im EEPROM liegt, es hat aber den Vorteil, dass man sich einiges an Programmzeilen im Modul selbst spart.
Das Protokoll kennt Befehle für das Lesen (R) und schreiben (W) des EEprom. Daher hat man von der Zentrale (FHEM) aus den kompletten EEprom unter Kontrolle.
In der Gerätedefinition ist beschrieben an welche Speicheradresse welche Informationen stehen müssen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 12 Mai 2014, 21:20:06
Hi,

so, jetzt habe ich auch die erste einigermaßen lauffähige Version von "meiner" Lösung. (Genau genommen ist ein großer Teil davon Dirks Lösung.) Die Sourcen hängen hier als .zip mit dran. Ich habe das mit Eclipse gemacht, aber es müsste auch in der Arduino-IDE gehen, wenn man HMWHomebrew.cpp nach .ino umbenennt.

Ich benutze für RS485 die SoftwareSerial Lib. Dummerweise kann die keine Parity, also musste ich da auch rumbasteln. Mit der SoftwareSerial.cpp hier im Anhang sollte es gehen.
Das Gerät sondert über die normale serielle Schnittstelle (Pin 0/1 bzw. USB) Debug-Ausgaben mit 57600 ab. RS485 geht über Pins 2 (RXD), 3 (TXD) und 4 (TX-Enable). Siehe auch den Anfang von HMWHomebrew.cpp.

Das Teil wird von FHEM (mit Dirks HM485-Erweiterungen) als HMW-IO-12-FM erkannt. Das funktioniert dadurch, dass es alle 20 Sekunden eine "A"-Nachricht sendet. (Also besser nicht in Eure Produktiv-Umgebung reinhängen.)
Die I/O-Ports funktionieren allerdings noch nicht...

Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 12 Mai 2014, 23:11:28
Hallo,
erstmal vielen Dank für die vielen Infos und besonders für diesen Tipp:
ZitatDein Device hat 000000AB als Adresse? So wie ich das herausgefunden habe ist der Adressraum 00000001 - 000000FF für das Interface der Zenralen vorgesehen. Auch wenn aktuell vor allem an der CCU1/2 nur eine Wired-Interface unterstützt werden.
Und ich meine dass Messages von anderen Zentralen ignoriert werden.
Mit einer Adresse, die nicht zwischen 0x00 und 0xFF liegt, werden die Tastendrücke auf einmal erkannt. Viel mehr habe ich heute leider nicht geschafft. Falls ich morgen Zeit finde, schaue ich mir mal Thorstens Code an.
@Thorsten: Auf den ersten Blick sieht dein Arduino-Projekt deutlich strukturierter aus als meins. Ich werd mal versuchen, auf Basis von Deinem Code den Discovery-Mode zu implementieren.

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 13 Mai 2014, 00:17:16
Hallo,

Ich habe hier schon mal ein Repo erstellt welches aber noch leer ist:
https://github.com/kc-GitHub/HM485-Lib

Ich wollte eigentlich schon mal ein Gerüst einbauen.
Das habe ich heute aber nicht mehr.

Ihr könnt mir ja schon mal eure Github Accouns schicken.
Dann kann ich euch mit einrichten.

@Thorsten,
Ich schaue mir morgen mal deinen aktuellen Code an.
Allerdings würde ich den Hartdware-UART und den Soft-UART tauschen.
Soft-UART als Debug-Ausgang.
Ich habe im Platinenlayout für die RS485-Version des Wettersensors übrigens PD2 als TX-Enable "verkabelt".
Die Platinen sollten hoffentlich Ende der Woche bzw. Anfang nächster Woche bei mir ankommen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 13 Mai 2014, 00:49:12
Zitat von: MarkusO am 12 Mai 2014, 23:11:28@Thorsten: Auf den ersten Blick sieht dein Arduino-Projekt deutlich strukturierter aus als meins. Ich werd mal versuchen, auf Basis von Deinem Code den Discovery-Mode zu implementieren.
Danke für die Blumen. Allerdings konnte ich noch nicht so richtig Tastendrücke etc. verschicken. Da scheinst Du weiter zu sein. Vielleicht liegt's aber auch daran, dass der HMW-IO-12-FM irgendwie anders reagiert.
Hat jemand einen echten HMW-IO-12-FM, so dass man das mal ausprobieren kann?

Zitat von: Dirk am 13 Mai 2014, 00:17:16Allerdings würde ich den Hartdware-UART und den Soft-UART tauschen.
Soft-UART als Debug-Ausgang.
Ich habe das absichtlich so gemacht, damit ich den Arduino Uno so wie er ist benutzen kann. Der USB-Stecker ist nun mal der Hardware-UART.
Man kann das aber im Hauptprogramm ganz einfach umstellen. Die HMWRS485-Klasse nimmt im Konstruktor jeweils einen Stream für den rs485 und für den Debug-Ausgang. Das kann man einfach umdrehen, wenn die Hardware etwas anders aussieht.

Gruß,
     Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 13 Mai 2014, 09:42:21
Zitat von: Dirk am 13 Mai 2014, 00:17:16Ihr könnt mir ja schon mal eure Github Accouns schicken.
Dann kann ich euch mit einrichten.
Du hast eine PM.

Ansonsten habe ich gestern (oder eher heute morgen) doch noch geschafft, etwas "sinnvolles" von meinem Prototypen zu FHEM zu senden. 4B-Nachrichten bekommt FHEM mit, aber 69-Nachrichten scheinen ignoriert zu werden. Ich habe es daher mal kurz mit der Emulation eines HMW-LC-SW2-DR probiert, da funktionieren (auch?) 69-Nachrichten für die Schaltausgänge.
Ich werde daher wahrscheinlich erst einmal mit einem HMW-LC-SW2-DR weitermachen, da ich da wenigstens was sehen kann. Ich habe auch vor, das Coding noch etwas zu vereinfachen (z.B. brauchen wir wohl keine zwei Klassen für das Protokoll und die generische Modulfunktionalität). Außerdem ist noch nicht wirklich sauber getrennt, was "Library" ist und was modulspezifisch. Das will ich aber noch machen.

Wo ich nicht so recht durchblicke ist die Konfiguration übers EEPROM. Das Layout des EEPROM-Speichers geht irgendwie aus dem Modul-Dateien (mit JSON-Beschreibungen oder so) hervor. Ich kapiere aber nicht, wie das genau zu verstehen ist. Gibt's dazu eine Doku?
Vielleicht kann sich jemand anders dieses Teils annehmen.

Außerdem wäre es gut, wenn jemand, der wirklich einen HMW-IO-12-FM hat, das ganze mal ausprobiert. Vor Allem wäre interessant, welche Messages das Teil bei einem Tastendruck schickt bzw. wenn ein Ausgang geschaltet wird.

...aber jetzt muss ich erstmal Geld verdienen

Gruss,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 Mai 2014, 00:01:39
Hi,

ich habe das jetzt umgebaut, so dass es in FHEM aussieht wie ein HMW-LC-Sw2-DR.
Die Sourcen liegen in https://github.com/kc-GitHub/HM485-Lib/tree/thorsten (https://github.com/kc-GitHub/HM485-Lib/tree/thorsten).
(Das "alte" Hauptprogramm habe ich nach HMW-IO-12-FM.cpp bzw. .h kopiert.)

Es sendet jetzt alle 20 Sekunden jeweils eine 4B-Nachricht (Key Event) für die ersten beiden Channels und je eine 69-Nachricht (Information) für die Channels 3 und 4. Das ist in etwa so, wie mein echter HMW-LC-Sw2-DR es auch macht.
Die Nachrichten kommen in FHEM als Events an und werden auch in den Readings der Channels angezeigt.

Device-Type, Seriennummer und Adresse werden jetzt im Konstruktor von HMWModule mitgegeben. Außerdem gibt es die Methoden broadcastKeyEvent und broadcastInfoMessage, mit denen man relativ einfach was vom Modul an die Zentrale (FHEM) schicken kann.

Die Konfiguration funktioniert noch nicht, da ich wie schon gesagt das Speicherlayout im EEPROM nicht kapiere. Falls sich da jemand verweilen will...
(...das ist aber nicht alles, was noch fehlt.)

Gruß,
    Thorsten


Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 14 Mai 2014, 16:22:34
Zitat von: Thorsten Pferdekaemper am 14 Mai 2014, 00:01:39
Die Konfiguration funktioniert noch nicht, da ich wie schon gesagt das Speicherlayout im EEPROM nicht kapiere. Falls sich da jemand verweilen will...
Das kann ich  mit machen bzw. kann ich dich hier einweisen. Das ich nicht so schwehr.
Ich würde das gerne so ähnlich machen wie in der AskSin-Lib, wo man die Register aus der Device-Config generieren lassen kann.
Allerdings würde ich hier auf die XML-Dateien zurück greifen.

Zum Thema Device-Type, Seriennummer und Adresse, würde ich das ganze auch so machen wie ich es bei Wettersensor gemacht habe.
Dann könnte man diese Daten während des Flashens vergeben.
Alternativ, so wie es auch bei den kommerziellen Geräten gemacht wird, könnte man diese Daten in den Bootloader packen. Den muss man sowieso selber flashen, wenn man Updates über den Bus fahren möchte.

Man kann den Raspery Pi übrigens auch als ISP-Programmer "misbrauchen". Das ganze passiert dann über 4 GPIO-Pins + GND.
Alternativ kann man einen Ardiuno mit einem passenden Sketch versorgen und diesen als ISP benutzen.

Die neuen Platinen vom Wettersensor sind ürbigens auf dem Weg zu mir.
Da diese auch für eine Bestückung mit RS485 Tranceiver und Spannungsversorgung vorgesehen sind, kann man diese auch gut zum experimentieren benutzen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 Mai 2014, 17:21:06
Zitat von: Dirk am 14 Mai 2014, 16:22:34
Das kann ich  mit machen bzw. kann ich dich hier einweisen. Das ich nicht so schwehr.
Ok, dann erklär mir das mal, am besten Anhand des HMW-LC-Sw2-DR.
ZitatIch würde das gerne so ähnlich machen wie in der AskSin-Lib, wo man die Register aus der Device-Config generieren lassen kann.
Allerdings würde ich hier auf die XML-Dateien zurück greifen.
Das können wir gerne so machen. Wo ist das Coding und woher bekomme ich die XML-Dateien?

ZitatZum Thema Device-Type, Seriennummer und Adresse,
[...]
diese Daten in den Bootloader packen.
Das sind für mich alles Themen, die ich momentan noch nicht angehen will. Zuerst sollte das Gerät mit richtig funktionieren, danach können wir es für die Massentauglichkeit fit machen.

ZitatDie neuen Platinen vom Wettersensor sind ürbigens auf dem Weg zu mir.
Da diese auch für eine Bestückung mit RS485 Tranceiver und Spannungsversorgung vorgesehen sind, kann man diese auch gut zum experimentieren benutzen.
Ok, aber dafür braucht man dann definitiv einen eigenen Bootloader oder muss per Programmer flashen, denke ich. (...aber den habe ich ja.)

Gruss,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 14 Mai 2014, 17:46:55
Zitat von: Thorsten Pferdekaemper am 14 Mai 2014, 17:21:06
woher bekomme ich die XML-Dateien?
Lade dir mal von der eq-3 Website das aktuellste firmwareupdate von der CCU1
Das Img benennst du um in tar.gz und packst das aus. Das innere Archiv auch noch mal
Die XML-Dateien liegen dann unter /firmware/hs485types
Hier kann man auch gut die Adressen der Register im EEprom rauslesen.

Es gibt da aber noch ein paar Kleinigkeiten zu beachten.
Das jetzt hier komplett zu erklären währ aber ziemlich umfangreich. Ggf. können wir dazu ja mal Skypen oder so.
Ggf. könnte man das in die Protokoll-Doku mit aufnehmen.
Die Doku habe ich übrigens noch etwas erweitert. Werde die die Tage mal noch hochladen.

ZitatOk, aber dafür braucht man dann definitiv einen eigenen Bootloader oder muss per Programmer flashen, denke ich.
Den brauchen wir in jedem Fall, wenn man über den Bus updaten können soll.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 Mai 2014, 21:24:32
Hi Dirk,
ok, mit den XMLs ist's ein bisschen klarer. Ich werde aber erstmal ein paar andere Sachen verbessern und dem Teil ein par richtige Ein- und Ausgänge geben. Zwei Taster und ein paar LEDs habe ich noch...
Wenn Du Skypen willst: Man findet mich mit meinem Realname und da müsste ich auch eindeutig sein. ...was man von Deinem Namen nicht behaupten kann.
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 14 Mai 2014, 22:11:07
Zitat von: Thorsten Pferdekaemper am 14 Mai 2014, 21:24:32
...was man von Deinem Namen nicht behaupten kann.
Auch mit meinem vollen Namen wird das nicht eindeutig :)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 Mai 2014, 23:10:14
@Dirk: Das habe ich mir schon gedacht, aber Du hast mich ja gefunden.

Ich wollte eigentlich heute nicht, aber es hat doch in den Fingern gejuckt. Man kann jetzt von FHEM aus Ausgänge schalten. Sozusagen als Beweis habe ich mal einen Screenshot angehängt. Der HMW_LC_Sw2_DR_KEQ1056682 ist einer von HomeMatic, der HMW_LC_Sw2_DR_HHB2703111 ist der selbst gebastelte.

Das Teil sendet jetzt nur noch die Tastendrücke alle 20 Sekunden. Die Ausgänge sind jetzt echt (im Sketch Pin 7 und 8) und können per FHEM geschaltet werden.
Sonstige Änderungen:
- Es gibt jetzt eine Klasse HMWDeviceBase. Die enthält die Definitionen für Callbacks vom Protokoll zur Hardware. Momentan ist das setLevel und getLevel zum Setzen und Lesen eines Zustands. HMWModule ruft die Methoden momentan dann auf, wenn von der Zentrale (oder auch von sonstwo) eine "x" oder "s" Nachricht kommt.
- Das Teil hat versucht, Nachrichten ohne Inhalt (also frameLength 0) zu verarbeiten. Das gab merkwürdige Effekte. (ACKs verarbeite ich momentan noch gar nicht, es werden auch noch keine reinen ACKs gesendet.)

Besonders @Dirk: A propos leere Nachrichten: FHEM sendet des Öfteren so etwas:
   FD-42-38-01-23-1C-00-00-00-01-02-A6-DC
Das kommt z.B. dann, wenn ich einen Ausgang schalten will. Ich mache also ein "set ... on" auf den Kanal und dann kommt erstmal so eine Nachricht. Offenbar ist es eine leere I-Nachricht. Ist das so gedacht? Wenn ja, wie muss ich darauf reagieren?

...und wenn wir gerade bei Problemchen sind: Am Anfang (also wenn ich meinen Testaufbau hochfahre) brauche ich immer einmal shutdown restart, muss ggf. den rs485-Dämon neu starten und muss einmal (oder so) "get info" aufs Gerät machen. Woran kann das liegen?

Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 14 Mai 2014, 23:13:25
Du bist schnell :)
Ich kann leider erst am Wochenende mitmachen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 15 Mai 2014, 23:11:42
Hallo,
ich habe mir den Discovery-Mode jetzt mal etwas näher angesehen und eine erste Version hochgeladen. Prinzipiell scheint der Mode zu funktionieren:
2014.05.15 22:30:25 3: HM485_LAN: Discovery - found device: 42380123
Allerdings frage ich mich jetzt, wofür der Discovery-Mode eigentlich gut ist? Ursprünglich bin ich davon ausgegangen, dass der Mode benötigt wird, um neue Devices zu finden. Die Devices werden scheinbar aber auch erkannt, wenn z.B. einfach eine Taste gedrückt wird und Botschaften von dem Gerät verschickt werden.
Wie sieht das bei Devices aus, die keine Eingänge haben? Werden hier zyklisch Acknolege-Botschaften verschickt und diese Devices damit auch automatisch erkannt, oder benötigen solche Geräte evtl. den Discory-Mode?

Falls der Mode tatsächlich benötigt wird: hat jemand Informationen zum Timing? Also wie lang die Pause zwischen Empfang der Botschaft und dem Versenden der Bestätigung sein muss? Ich könnte mir vorstellen, dass alle Geräte exakt die gleiche Wartezeit haben und gleichzeitig Antworten. Dadurch, dass keine unterschiedlichen Adressen geschickt werden, sondern von allen die gleiche Botschaft "0xF8" kommt es zu keinen Kollisionen (wie die Arbitrierung beim CAN-Bus). Ist aber nur eine Vermutung. Hat schon mal jemand beobachtet, ob verschiedene Geräte unterschiedliche "Wartezeiten" haben?

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 15 Mai 2014, 23:27:23
Zitat von: MarkusO am 15 Mai 2014, 23:11:42
Allerdings frage ich mich jetzt, wofür der Discovery-Mode eigentlich gut ist? Ursprünglich bin ich davon ausgegangen, dass der Mode benötigt wird, um neue Devices zu finden. Die Devices werden scheinbar aber auch erkannt, wenn z.B. einfach eine Taste gedrückt wird und Botschaften von dem Gerät verschickt werden.
Hm-Wired-Geräte werden automatisch erkannt und gepaired, sofern die Zentrale diese noch nicht kennt.
Zumindest mach das die CCU so. Daher habe ich das im FHEM-Modul genau so gemacht.
Bei einem Wired-Bus kann man eigentlich davon ausgehen, dass es hier keine fremden Geräte gibt.

Der Discovery-Mode dient lediglich dazu, das Anlernen einfacher zu gestalten. Auch wenn man an einem IO-Modul mal noch keine Taster angeschlossen hat, oder wenn man alle Module mal neu anlernen möchte, dafür aber nicht durch das Ganze Haus rennen zu müssen.

ZitatWie sieht das bei Devices aus, die keine Eingänge haben? Werden hier zyklisch Acknolege-Botschaften verschickt und diese Devices damit auch automatisch erkannt, oder benötigen solche Geräte evtl. den Discory-Mode?
Aktuell fällt mir zwar kein fertig-Modul ein, was keine Eingänge. Aber ja, dafür währ der dann erforderlich.

ZitatFalls der Mode tatsächlich benötigt wird: hat jemand Informationen zum Timing? Also wie lang die Pause zwischen Empfang der Botschaft und dem Versenden der Bestätigung sein muss?
Die CCU schickt Discovery-Messages, das Device muss innerhalb von 7ms. Antworten.
Ich überarbeite grade die Protokoll Dokumentation da hab ich noch ein paar neue Infos drinn.

ZitatDadurch, dass keine unterschiedlichen Adressen geschickt werden, sondern von allen die gleiche Botschaft "0xF8" kommt es zu keinen Kollisionen (wie die Arbitrierung beim CAN-Bus).
Hier bin ich mir noch nicht ganz sicher. Wenn die Devices das F8 nämlich nicht exact gleichzeitig verschicken, könnte es trotzdem Kollisionen geben. Das wollte ich hier aber noch mal testen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 16 Mai 2014, 00:06:31
ZitatWenn die Devices das F8 nämlich nicht exact gleichzeitig verschicken, könnte es trotzdem Kollisionen geben.
Ja, das könnte eine Herausforderung werden. Allein das Verschicken von ein paar Debug-Nachrichten hat bei mir soviel Zeit in Anspruch genommen, dass die Antwort nicht mehr innerhalb der 7ms gekommen ist und der Discovery-Mode nicht mehr lief. Das ganze so zu timen, dass alle Devices so zeitgleich senden und es zu keinen Kollisionen kommt, klingt fast unmöglich...
Ich werd einfach mal die neue Doku abwarten.

Grüße,
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 16 Mai 2014, 09:59:36
Zitat von: MarkusO am 15 Mai 2014, 23:11:42Falls der Mode tatsächlich benötigt wird: hat jemand Informationen zum Timing?
Die ganzen Timing-Geschichten und Kollisionsvermeidung sind sowieso noch nicht implementiert. Vielleicht ergibt sich das später fast von selbst.

ZitatIch könnte mir vorstellen, dass alle Geräte exakt die gleiche Wartezeit haben und gleichzeitig Antworten. Dadurch, dass keine unterschiedlichen Adressen geschickt werden, sondern von allen die gleiche Botschaft "0xF8" kommt es zu keinen Kollisionen
Das kann ich mir irgendwie nicht wirklich vorstellen. Wenn ich mir das Coding vom SoftSerial anschaue, dann ist das ganze so schon recht zeitkritisch. Ich gehe mal nicht davon aus, dass die Geräte so genau zur gleichen Zeit senden können.

ZitatIst aber nur eine Vermutung. Hat schon mal jemand beobachtet, ob verschiedene Geräte unterschiedliche "Wartezeiten" haben?
Ich hab leider nur ein "echtes".

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 16 Mai 2014, 10:11:36
Zitat von: Thorsten Pferdekaemper am 16 Mai 2014, 09:59:36
Das kann ich mir irgendwie nicht wirklich vorstellen.
Ich auch nicht so ganz. Obwohl das möglich sein sollte. Daher liegt der Punkt noch etwas im Dunkeln.
Ich werde mir das mal auf meinem Bus ansehen.
Ggf. mal mit dem Logicanalyzer.

ZitatWenn ich mir das Coding vom SoftSerial anschaue, dann ist das ganze so schon recht zeitkritisch. Ich gehe mal nicht davon aus, dass die Geräte so genau zur gleichen Zeit senden können.
Ich nehme an das man SoftSerial hier nicht als Referenz heranziehen kann.
Ansonsten sollte es schon möglich sein beim Eintreffen von Discovery Paketen einen ziemlich gleichzeitigen Interrupt in den Devices auszulösen.
Die HMW-Geräte haben auch alle einen Quarz. Somit ist das Timing hier genauer als ohne.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 17 Mai 2014, 23:47:49
Hi,
ich habe mal wieder ein bisschen weitergebastelt und an meinen Arduino zwei LEDs und zwei Taster angeschlossen (siehe Bild). Ich weiß jetzt, dass das Teil tatsächlich seine Ausgänge schaltet, wenn auch etwas langsam (siehe unten).
Außerdem habe ich im Coding die Taster-Eingänge dazugebaut. (Eingecheckt in meinem Branch.) D.h. das Teil sendet jetzt nicht mehr alle 20 Sekunden einen Key-Event, sondern wenn man die Tasten drückt. Im Einzelnen...

Ein paar Sachen fehlen da natürlich noch, z.B. müssen die 2 Sekunden einstellbar werden und ich glaube auch die "Repeat"-Funktion alle 300ms. Außerdem denke ich, dass Broadcast nicht ganz das Richtige ist. (Oder?)
Das Coding gefällt mir auch noch nicht wirklich. Vielleicht sollte man dem Teil eine eigene Klasse spendieren, vielleicht sogar eine eigene Mini-Lib.

Jetzt nochmal zum langsamen Schalten der Ausgänge: Das ganze liegt (denke ich) daran, dass die Zentrale (FHEM) vor dem eigentlichen Schalt-Befehl (sowas wie
     FD-42-38-01-23-1E-00-00-00-01-05-78-02-C8-AC-3A
) erst einmal drei leere Nachrichten schickt, also sowas wie
FD-42-38-01-23-18-00-00-00-01-02-DC-44.
Da ich noch keine ACKs sende, macht die Zentrale das dann jeweils dreimal. D.h. es werden 9 Nachrichten versendet, bevor der eigentliche Befehl kommt. Natürlich liegt das Hauptproblem bei mir (fehlende ACKs), aber müssen die leeren Nachrichten sein? Wofür sind die gut?

Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Mr. P am 18 Mai 2014, 00:20:31
Zitat von: Thorsten Pferdekaemper am 17 Mai 2014, 23:47:49

  • Die Tasten sind entprellt. Eine Taste muss mindestens 50ms gedrückt sein, damit überhaupt was passiert.
  • Beim Loslassen einer Taste wird ein KEY_EVENT_SHORT geschickt, außer die Taste wurde länger als 300ms gedrückt.
  • Bei einem Tastendruck von mindestens 300ms wird alle 300ms ein KEY_EVENT_SHORT geschickt.
  • Wenn man eine Taste 2 Sekunden lang drückt, wird ein KEY_EVENT_LONG ausgelöst. Es gibt immer nur ein KEY_EVENT_LONG, egal wie lange man eine Taste drückt.
Hej Thorsten,

nachdem mich das Projekt auch interessiert, versuche ich hier im Thread regelmäßig zu informieren und die Fortschritte gefallen mir. :-)
Aber für ein SHORT würde ich nicht min. 50ms veranschlagen, damit was passiert. Ich würde eher bei einem Tastendruck von unter 300ms  min. 50 oder 100ms warten, bis ich den nächsten akzeptiere und das ganze damit entprellen.
Und wie muss man das mit den 300ms verstehen? Entweder, dass wenn ich die Taste zwischen 300ms und 2Sek. loslasse ein kontinuierliches SHORT geschickt wird (bis die Taste vermutlich nochmal gedrückt wird) oder aber, dass ab 300ms solange ein SHORT geschickt wird, bis du bei 2 Sekunden angelangt bist (also bei 300ms, 600ms, 900ms, 1200ms, 1500ms & 1800ms) und dann folgt ein LONG.

Wär' super, wenn du das ein wenig näher erläutern könntest. :-)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 18 Mai 2014, 08:52:37
Zitat von: Mr. P am 18 Mai 2014, 00:20:31nachdem mich das Projekt auch interessiert, versuche ich hier im Thread regelmäßig zu informieren und die Fortschritte gefallen mir. :-)
Danke!
ZitatAber für ein SHORT würde ich nicht min. 50ms veranschlagen, damit was passiert. Ich würde eher bei einem Tastendruck von unter 300ms  min. 50 oder 100ms warten, bis ich den nächsten akzeptiere und das ganze damit entprellen.
Es gibt ein paar Gründe, warum ich es so gemacht habe:
...um die 50ms kann man natürlich streiten. Für die trainierte Gamer-Hand wären vielleicht 25ms besser, für zaghafte oder betagte Benutzer vielleicht 100ms.
ZitatUnd wie muss man das mit den 300ms verstehen? Entweder, dass wenn ich die Taste zwischen 300ms und 2Sek. loslasse...
Also hier mal ein paar Beispiele für Tastendrücke verschiedener Länge:
Durch meine Implementierung können die Zeiten ein bisschen abweichen. Das dürften nie mehr als ein paar Millisekunden sein, aber eine genaue Uhr kann man damit nicht bauen.
Ich habe oben den momentanen Stand beschrieben. Das muss nicht so bleiben, speziell müssen ein paar Sachen konfigurierbar werden.
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 18 Mai 2014, 11:33:05
Zitat von: MarkusO am 16 Mai 2014, 00:06:31
Ja, das könnte eine Herausforderung werden. Allein das Verschicken von ein paar Debug-Nachrichten hat bei mir soviel Zeit in Anspruch genommen, dass die Antwort nicht mehr innerhalb der 7ms gekommen ist und der Discovery-Mode nicht mehr lief. Das ganze so zu timen, dass alle Devices so zeitgleich senden und es zu keinen Kollisionen kommt, klingt fast unmöglich...
Nicht unbedingt. Ich habe mir das nochmal überlegt. Das Timing der AVR's haben wir komplett in der Hand. ggf. muss man auf Arduino-Libs hier verzichten aber das sollte gehen. Allerdings nicht mit SoftSerial.
Die ARV's brauchen für Wired sowieso einen Quarz. D.H. Wenn der AVR ein Discovery-Frame für seine Seriennummer empfängt, muss dieser "nur" ein Byte senden. Und das sollte mit einem vorhersagbarem Timing möglich sein. ggf. müssen während des Discovery nicht benötigte Interrupts abgeschaltet werden. Debugmessages während dessen sind da natürlich nicht drinn.

Ich werde aber mal fertige Module belauschen wie die sich hier verhalten. Mal sehen ob die tatsächlich gleichzeitig F8 senden. Da bin ich nämlich noch nicht so sicher.



Zitat von: Thorsten Pferdekaemper am 17 Mai 2014, 23:47:49
  • Bei einem Tastendruck von mindestens 300ms wird alle 300ms ein KEY_EVENT_SHORT geschickt.
Hier sollte alle 300ms KEY_EVENT_LONG gesendet werden.

ZitatAußerdem denke ich, dass Broadcast nicht ganz das Richtige ist. (Oder?)
Wenn das Device noch nicht gepeert ist, nur dann werden events an die Broadcastadresse gesendet. Ansonsten nur an das gepeerte Device.

ZitatDas Coding gefällt mir auch noch nicht wirklich. Vielleicht sollte man dem Teil eine eigene Klasse spendieren, vielleicht sogar eine eigene Mini-Lib.
Ich hätte das Ganze evtl. sogar so ähnlich aufgebaut wie Trillus AskSin-Lib?

ZitatDa ich noch keine ACKs sende, macht die Zentrale das dann jeweils dreimal. D.h. es werden 9 Nachrichten versendet, bevor der eigentliche Befehl kommt. Natürlich liegt das Hauptproblem bei mir (fehlende ACKs), aber müssen die leeren Nachrichten sein? Wofür sind die gut?
Ich vermute das ist ein Bug. Pasiert das auch, wenn du RAW-Messages schickst?



Zitat von: Thorsten Pferdekaemper am 18 Mai 2014, 08:52:37
  • Das scheint zum Entprellen die gängige Praxis zu sein.
Ja, so mache ich das auch immer.

Zitatfür zaghafte oder betagte Benutzer vielleicht 100ms. Also hier mal ein paar Beispiele für Tastendrücke verschiedener Länge:
Auch hier reichen 50ms. Für die "Betagten" wird nur die Einstellung für die Erkennung des langen Tastendrucks interessant.

Sofern braucht es auch keine weitere Prüfung

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Mr. P am 18 Mai 2014, 11:49:29
Zitat von: Dirk am 18 Mai 2014, 11:33:05

  • 0-49 ms: nix passiert
  • 50-longPressSchwelle: nach Loslassen -> kurzer Tastendruck
  • > longPressSchwelle: alle 300ms keyEventLong, Wiederholungen müssen mit selben keyEventCounter gesendet werden. Sonst gibt es probleme beim Dimmen
Ok, wenn die zeitliche Untergrenze für ein SHORT so die übliche Vorgehensweise ist, werd' ich mir das gerne einmal ansehen. :-)
Und wenn dann ab 300ms ein LONG geschickt wird, wäre das auch die Art, wie ich es bereits von anderen HM-Schaltern kenne.

Danke für die Infos!
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 18 Mai 2014, 11:52:17
Zitat von: Dirk am 18 Mai 2014, 11:33:05Nicht unbedingt. Ich habe mir das nochmal überlegt. Das Timing der AVR's haben wir komplett in der Hand. ggf. muss man auf Arduino-Libs hier verzichten aber das sollte gehen.
Wir haben die Zeit in der Hand, die vom Eintreffen der Discovery-Message bis zum Raussenden des F8 vergeht. Was ist aber mit der Zeit, bis die Discovery-Message wirklich beim jeweiligen Device ankommt?
ZitatIch hätte das Ganze evtl. sogar so ähnlich aufgebaut wie Trillus AskSin-Lib?
Muss ich mir mal anschauen...
ZitatIch vermute das ist ein Bug. Pasiert das auch, wenn du RAW-Messages schickst?
Muss ich mal ausprobieren...

Zitat

  • 0-49 ms: nix passiert
  • 50-longPressSchwelle: nach Loslassen -> kurzer Tastendruck
  • > longPressSchwelle: alle 300ms keyEventLong, Wiederholungen müssen mit selben keyEventCounter gesendet werden. Sonst gibt es probleme beim Dimmen
Der Default-Wert für "Long press" liegt bei 2 Sekunden. Wie kann ich nach 2 Sekunden nachträglich alle 300ms ein Event schicken???
Oder ist es so gemeint:
...und die 2000ms werden noch einstellbar.

Zitat von: Mr. P am 18 Mai 2014, 11:49:29Und wenn dann ab 300ms ein LONG geschickt wird, wäre das auch die Art, wie ich es bereits von anderen HM-Schaltern kenne.
Ich habe das noch nicht ausprobiert, aber ich glaube, dass die Untergrenze für LONG 400ms ist.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 18 Mai 2014, 12:09:10
Zitat von: Thorsten Pferdekaemper am 18 Mai 2014, 11:52:17
Wir haben die Zeit in der Hand, die vom Eintreffen der Discovery-Message bis zum Raussenden des F8 vergeht. Was ist aber mit der Zeit, bis die Discovery-Message wirklich beim jeweiligen Device ankommt?
In der Zeit müssen wir nix machen. Oder wie meinst du das?


ZitatDer Default-Wert für "Long press" liegt bei 2 Sekunden. Wie kann ich nach 2 Sekunden nachträglich alle 300ms ein Event schicken???
Wie nachträglich?
Wenn du länger als longPressTimeout (default 2 Sekunden) drückst, dann werden alle 300ms KeyEvents gesendet.
shortPressEvents werden nur nach dm Loslassen gesendet. Und nur, wenn longPressTimeout noch nicht erreicht ist.

ZitatIch habe das noch nicht ausprobiert, aber ich glaube, dass die Untergrenze für LONG 400ms ist.
Das ist abhängig vom Device und sollte in der XML-Datei stehen.
Beim hmw_io12_sw7_dr z.B. ist es Default 2s, Min 0,1s, Max 25,5s
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 18 Mai 2014, 14:51:34
Zitat von: Dirk am 18 Mai 2014, 12:09:10In der Zeit müssen wir nix machen. Oder wie meinst du das?
Ich meine es so: Angenommen wir haben zwei Devices. Eins hängt im Schaltschrank direkt neben dem LAN-Adapter. Zum anderen gehen 200m Leitung und es hängt noch ein Leitungstreiber dazwischen. Dann kann ich mir schon vorstellen, dass sich da ein paar Mikrosekunden Unterschied ergeben, bis das Signal von der Zentrale beim Device ist.
ZitatWie nachträglich?
Wenn ich erst nach 2000ms weiß, dass es ein LONG ist, dann kann ich nicht von Anfang an alle 300ms Nachrichten schicken. Ich kann erst bei 2000ms anfangen.
ZitatWenn du länger als longPressTimeout (default 2 Sekunden) drückst, dann werden alle 300ms KeyEvents gesendet.
shortPressEvents werden nur nach dm Loslassen gesendet. Und nur, wenn longPressTimeout noch nicht erreicht ist.
Das ist mir jetzt auch klar. Ich werde das auch noch ändern, ich kann nur nicht versprechen, dass es heute schon soweit ist.
Gruß,
    Thorsten

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 18 Mai 2014, 15:00:18
Zitat von: Thorsten Pferdekaemper am 18 Mai 2014, 14:51:34
Ich meine es so: Angenommen wir haben zwei Devices. Eins hängt im Schaltschrank direkt neben dem LAN-Adapter. Zum anderen gehen 200m Leitung und es hängt noch ein Leitungstreiber dazwischen. Dann kann ich mir schon vorstellen, dass sich da ein paar Mikrosekunden Unterschied ergeben, bis das Signal von der Zentrale beim Device ist.
Die Signale gehen mit Lichtgeschwindigkeit über die Leitung. Bis man hier Verzögerungen im µs-Bereich mitbekommt, könnte die Leitung schon recht lang werden. Im ms-Bereich noch vieeeeeel länger.
Was für Leitungstreiber hast du noch dazwischen. Von der Zentrale zu den Devices sollten keine weitere Hardware im Bus sein.
Mit Ausnahme des Interfaces.

ZitatWenn ich erst nach 2000ms weiß, dass es ein LONG ist, dann kann ich nicht von Anfang an alle 300ms Nachrichten schicken.
Die Events kannst du natürlich erst nach Ablauf der 2000ms Senden.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 Mai 2014, 22:45:57
So, ich habe gerade die neue Version eingecheckt. Die Tastendrücke sind jetzt korrigiert und es reagiert wie Dirk es beschrieben hat. (Mit longPressSchwelle fix auf 2000ms.)
Zitat von: Dirk am 18 Mai 2014, 11:33:05

  • 0-49 ms: nix passiert
  • 50-longPressSchwelle: nach Loslassen -> kurzer Tastendruck
  • > longPressSchwelle: alle 300ms keyEventLong, Wiederholungen müssen mit selben keyEventCounter gesendet werden. Sonst gibt es probleme beim Dimmen
Ich kann allerdings die LONG Wiederholungen im FHEM Event Monitor nicht sehen. Anscheinend wird nur ein Event getriggert, wenn sich der Key Counter ändert. 

Zitat von: Dirk am 18 Mai 2014, 11:33:05Ich vermute das ist ein Bug. Pasiert das auch, wenn du RAW-Messages schickst?
Das bezieht sich auf die "leeren Messages" wenn man per FHEM einen Aktor schaltet (also direkt mit "set ... on"). Wenn ich das per "set ... RAW" mache, dann funktioniert das so, wie ich erwartet habe. Die Zentrale schickt das Kommando, mein Device antwortet mit dem neuen Wert des Aktors und die Zentrale sendet daraufhin ein ACK. Keine seltsamen leeren Messages.

EDIT: Ich habe jetzt noch eine neue Version hochgeladen. Jetzt werden auch ACKs gesendet. Dadurch geht das Schalten per FHEM auch etwas schneller (aber der Bug oben sollte schon noch gelöst werden).
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 21 Mai 2014, 23:43:41
So, hier das heutige Update: In der aktuellen Version sind zwei Kleinigkeiten korrigiert:
Mir fallen während meiner Versuche immer wieder kleine Fehler in der FHEM-Integration auf. Kümmert sich darum momentan noch jemand oder ist das verwaist? Falls letzteres zutrifft, würde ich mich ggf. selbst darum kümmern. Man muss doch einiges mit set..RAW ausprobieren.

Ansonsten: Gibt es eigentlich Wünsche, was am HMW-Modul vorranging eingebaut werden soll? Ich meine damit: Womit soll es weitergehen?

Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 22 Mai 2014, 00:20:36
Hi Thorsten,

Zitat von: Thorsten Pferdekaemper am 19 Mai 2014, 22:45:57
Ich kann allerdings die LONG Wiederholungen im FHEM Event Monitor nicht sehen. Anscheinend wird nur ein Event getriggert, wenn sich der Key Counter ändert. 
Ja, Das hatte ich aktuell so gebaut.

Zitat
Das Modul antwortet nicht mehr auf Broadcast-Messages. (Außer in Zukunft auf "z" bzw. "Z" sowie Discovery.)
Ich muss mal prüfen ob das nicht noch mehr Befehle sind wo das Device auch auf Broadcast hören sollte.

Zitat
Mir fallen während meiner Versuche immer wieder kleine Fehler in der FHEM-Integration auf.
Die kannst du mir gerne mal schicken.

ZitatKümmert sich darum momentan noch jemand
Im Prinzip ja, auch wenn ich aktuell nur langsam weiter komme.

Ich war ja vor 2 Wochen beim Homematic-Usertreffen.
Dort habe ich unter anderem auch die Entwickler von Homegear kennen gelernt. Auch ein OpenSource Projekt bei welchem die HM-Wired integration schon deutlich weiter ist. Laut Entwickler vollständig.
Daher bin ich grade etwas hin und her gerissen wie ich die Entwicklung weiter führe.
Im Prinzip kann man Homegear jetzt schon per XML-RPC mit FHEM kommunizieren lassen.
Die Module existieren. Das Ganze läuft auch auf ARM und X86 Umgebungen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 Mai 2014, 09:14:16
Zitat von: Dirk am 22 Mai 2014, 00:20:36Ich muss mal prüfen ob das nicht noch mehr Befehle sind wo das Device auch auf Broadcast hören sollte.
Das ist kein großes Problem. Die meisten Befehle sind ja sowieso noch nicht implementiert. Wenn wieder einer dazukommt, dann ist es im Coding relativ einfach, das zu entscheiden.
ZitatDie kannst du mir gerne mal schicken.
Per PN/Mail oder hier? Folgendes habe ich gerade im Kopf:

ZitatDort habe ich unter anderem auch die Entwickler von Homegear kennen gelernt. Auch ein OpenSource Projekt bei welchem die HM-Wired integration schon deutlich weiter ist. Laut Entwickler vollständig.
Daher bin ich grade etwas hin und her gerissen wie ich die Entwicklung weiter führe.
Im Prinzip kann man Homegear jetzt schon per XML-RPC mit FHEM kommunizieren lassen.
Die Module existieren. Das Ganze läuft auch auf ARM und X86 Umgebungen.
...oder man installiert eine CCU (?).
Klar, das ist immer frustrierend, wenn man was entwickelt und dann gibt es das schon. Das führt leicht dazu, das man gar nichts mehr macht. Zumindest sollten wir entscheiden, was in FHEM funktionieren sollte und was per CCU/Homegear. Mir scheint, dass FHEM auf jeden Fall in Sachen Integration besser ist. Meiner Meinung nach sollte FHEM daher HMW-Module direkt schalten bzw. abfragen können. Die ganzen Einstellungen können wir auch (vorerst?) per Homegear/CCU machen.
Wäre so etwas vorstellbar?
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 22 Mai 2014, 09:48:13
Hi Thorsten

ZitatPer PN/Mail oder hier?
Vielleicht auch im Isuetracker vom Githiub.
Dann währ alles beisammen.

ZitatKlar, das ist immer frustrierend, wenn man was entwickelt und dann gibt es das schon. Das führt leicht dazu, das man gar nichts mehr macht.
So schlimm sehe ich das gar nicht. Ich habe die Entwickler vor 2 Wochen auf dem Homematic-Usertreffen kennengelernt und bin mit denen in Kontakt. Auch konnte deren Entwicklung von meiner Doku profitieren. Ebenso konnte ich einige noch unklare Fragen beantworten. Daher sehr ich die Entwicklung positiv.
Homegear ist auch kein vollständiges HA-System. Es fehlt hier z.B. das Frontend.

ZitatMir scheint, dass FHEM auf jeden Fall in Sachen Integration besser ist.
Da bin ich mir noch nicht so sicher. Aktuell aber ja. Im Prinzip würde sich Homegear ähnlich wie ein Inferfaceprozess, also z.B. dem HM485d verhalten.

Zitat...oder man installiert eine CCU (?).
Der große Vorteil von FHEM oder auch Homegear ist ja gerade der, das es Opensource ist.
Auch wenn EQ-3 gerade dabei ist die Binaries der CCU für andere Plattformen für die Fremdnutzung freizugeben, wird es zumindest die nächste Zeit keine Sourcen davon geben.

ZitatWäre so etwas vorstellbar?
Durchaus.
Evtl. hast du Zeit dir das mal anzusehen. Dann könnte man das gemeinsam entscheiden.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Franz74 am 22 Mai 2014, 10:49:57
Hallo Jungs,

erst einmal super was ihr hier leistet!

Weil ich in diesem Thread nach der Frage welche Aktoren / Sensoren wir brauchen könnten gelesen habe würde ich mir gerne folgenden Sensor wünschen:

Als Homematic CCU nutzer wäre ein HM Wired auf 1-Wire Adapter um damit Counter und Temperatur Sensoren ins HM System zu bekommen eine Geniale Komponente!

Ich weiß das es schon für FHEM direkt eine 1-Wire Integration gibt aber für eine CCU gibt es keine "schöne".

So könnte ich meinen Heizraum in dem schon HM Wired ist auf 1-Wire umstellen und das wäre mir auch was Wert!

Franz
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 Mai 2014, 20:18:35
Zitat von: Dirk am 22 Mai 2014, 09:48:13Vielleicht auch im Isuetracker vom Githiub.
Erledigt. Es gibt jetzt bei FHEM-HM485 drei neue Issues. Ich denke, dass das dorthin gehört.

ZitatDurchaus.
Evtl. hast du Zeit dir das mal anzusehen. Dann könnte man das gemeinsam entscheiden.
Kann ich machen, aber das dürfte ein paar Tage dauern.

Zitat von: Franz74 am 22 Mai 2014, 10:49:57erst einmal super was ihr hier leistet!
Danke!
Zitat
Weil ich in diesem Thread nach der Frage welche Aktoren / Sensoren wir brauchen könnten gelesen habe würde ich mir gerne folgenden Sensor wünschen:
Es war ein bisschen anders gemeint, aber ok.
Zitat
Als Homematic CCU nutzer wäre ein HM Wired auf 1-Wire Adapter um damit Counter und Temperatur Sensoren ins HM System zu bekommen eine Geniale Komponente!
Ich weiß nicht, ob ein allgemeiner Adapter wirklich machbar ist. Zumindest müsste man dann neue Gerätetypen erfinden mit XMLs usw. Was aber gehen dürfte wäre folgendes: Man sucht sich einen möglichst passenden existierenden Gerätetyp aus und baut dann ein Gerät, welches so tut, als ob es so eins wäre. In dem Fall hier würde sich vielleicht ein HMW-IO-12-Sw14-DR anbieten.  Das Ding hat 6 Analog-Eingänge. Die Auflösung scheint nicht gerade so großartig zu sein, aber für eine Temperaturmessung müsste es ausreichend sein. Statt A/D-Wandler könnte man in der Firmware ja direkt 1-Wire Sensoren abfragen.
Allerdings habe ich kein 1-Wire und weiß nicht wirklich, ob das sinnvoll ist.

Gruß,
   Thorsten


Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 22 Mai 2014, 20:30:25
Zitat von: Thorsten Pferdekaemper am 22 Mai 2014, 20:18:35
Erledigt. Es gibt jetzt bei FHEM-HM485 drei neue Issues. Ich denke, dass das dorthin gehört.
Super Danke.

ZitatIch weiß nicht, ob ein allgemeiner Adapter wirklich machbar ist. Zumindest müsste man dann neue Gerätetypen erfinden mit XMLs usw. Was aber gehen dürfte wäre folgendes: Man sucht sich einen möglichst passenden existierenden Gerätetyp aus und baut dann ein Gerät, welches so tut, als ob es so eins wäre. In dem Fall hier würde sich vielleicht ein HMW-IO-12-Sw14-DR anbieten.  Das Ding hat 6 Analog-Eingänge. Die Auflösung scheint nicht gerade so großartig zu sein, aber für eine Temperaturmessung müsste es ausreichend sein. Statt A/D-Wandler könnte man in der Firmware ja direkt 1-Wire Sensoren abfragen.
Ich hatte das mit Franz74 schon besprochen.
Das ist auch relativ einfach machbar.
Einen neuen Device-Type mit XML braucht man natürlich.
Beim Universalsensor hab ich das ja schon mal umgesetzt.
Die Idee von dem 1-Wire Teil währ dann z.B. n Temperaturkanäle zur Verfügung zu stellen.
Damit man über den HMW-Bus nicht ständig pollen muss, könnte der AVR das Pollen der 1-Wire Sensoren übernehmen.
Bei Abweichungen von z.B. 0.5 Grad wird über den HMW-Bus dann ein Event geschickt.
Im Idealfall kann man die Abweichung natürlich einstellen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Franz74 am 23 Mai 2014, 08:26:43
Hallo Dirk, Thorsten,

sorry wenn ich mich in euren Thread einmische, aber es ist mir ein Bedürfnis euch zu sagen wie wichtig eure Arbeit für mich und jeden Homematic Besitzer ist.

Weil ihr endlich Aktoren / Sensoren neben EQ3 entwickelt und dank eurer Basisarbeit auch andere welche Entwickeln können da sich EQ3 weigert so sinnvolle Aktoren wie z.B. einen Wired LED Dimmer zu entwickeln. Für jeden HM Besitzer kann ein zweiter (oder dritter...) Hersteller von Komponenten nur von Vorteil sein!

Jeder der HM Wired einsetzt hat aktuell die Wahl bei den wenigen Aktoren von HM zu bleiben oder auf ein anderes System umzusteigen, das finde ich sehr Schade weil gerade bei Neubauten kommt für mich nur Wired in Frage...

LG

Franz

PS: Vielleicht ließt EQ3 ja mit und kurbelt die Entwicklung von Wired etwas an, sonst macht es die Community und holt sich das Geschäft!
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 23 Mai 2014, 11:08:13
Zitat von: Dirk am 22 Mai 2014, 20:30:25Einen neuen Device-Type mit XML braucht man natürlich.
Ok, könntest Du mir mal so ein XML zusammenbasteln? Ich schau dann mal, ob ich dazu eine passende Firmware machen kann.
ZitatDie Idee von dem 1-Wire Teil währ dann z.B. n Temperaturkanäle zur Verfügung zu stellen.
Damit man über den HMW-Bus nicht ständig pollen muss, könnte der AVR das Pollen der 1-Wire Sensoren übernehmen.
Ich habe bisher noch nichts mit 1-wire gemacht. Was genau müsste ich mir bestellen, damit ich das mal ausprobieren kann? (Das ist kein Versprechen...) Das ganze klingt ja schon sehr interessant. Wenn das mit dem XML wirklich klappt, dann könnte man z.B. sowas wie einen 25-Kanal 1-wire Temperatursensor bauen...
ZitatBei Abweichungen von z.B. 0.5 Grad wird über den HMW-Bus dann ein Event geschickt.
Im Idealfall kann man die Abweichung natürlich einstellen.
Das wäre dann der nächste Schritt...

Zitat von: Franz74 am 23 Mai 2014, 08:26:43sorry wenn ich mich in euren Thread einmische,
Das ist ein Forum, ich hoffe, dass sich auch andere "einmischen".
ZitatWeil ihr endlich Aktoren / Sensoren neben EQ3 entwickelt und dank eurer Basisarbeit auch andere welche Entwickeln können da sich EQ3 weigert so sinnvolle Aktoren wie z.B. einen Wired LED Dimmer zu entwickeln. Für jeden HM Besitzer kann ein zweiter (oder dritter...) Hersteller von Komponenten nur von Vorteil sein!
Tja, das klingt ja so, als ob Du da sogar kommerzielles Potential siehst. Interessant...
Es wäre auch interessant, wie eq-3 darauf reagieren würde. Entweder sie fangen an, dagegen vorzugehen oder sie begrüßen die Vergrößerung ihres "Ökosystems" sogar. Naja, momentan ist das aber noch nicht wirklich relevant.

Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Franz74 am 23 Mai 2014, 11:50:16
Hallo Thorsten, Dirk,

also nach meiner Begegnung mit EQ3 auf dem Homematic Usertreffen kann ich nur sagen das sie solange nicht gegen jemanden Vorgehen werden solange dieser die Produkte nicht Kommerziell vertreibt. Da aber beide Projekte hier die RF und hier das Wired keinen Code von EQ3 einsetzen und die Funkkomunikation als solches ja nicht Patentgeschützt sein kann wird es EQ3 nicht leicht haben das zu verhindern.

Ich würde es aber begrüßen wenn ELV (EQ3 ist einen 100% ige Tochter von ELV --> die haben den selben CEO..) sich darauf besinnt das sie von Bastler gegründet und mit Basteler so groß geworden sind wie sie heute sind! Die Entwicklung das sie die Binarys der CCU2 für verschiedene Systeme Freigeben (Projekt OHCU) werden ist schon mal der erste Schritt in diese Richtung und wir können nur hoffen das auch die Sourcen Freigegeben werden.

Und ja ich sehe da sehr viel Potential in der Entwicklung von HM Kompatiblen Aktoren / Sensoren!

Um nur einige zu nennen...

1-Wire ist die billigste Lösung um Temperaturen Digital über einen Bus zu messen, es gibt z.B. Temperaturfühler bei dx.com um EUR 3,60 oder bei Ebay habe ich schon 5 Stück um EUR 7,50 gesehen, dieser werden mit 5V Parasitär über den Stern oder Serienbus versorgt und vom Busmaster gepoolt abgefragt, wobei sich jeder Sensor mit seiner Seriennummer und der Temperatur meldet.

@Thorsten, wenn du einen 1-Wire Fühler haben willst so schreib mir eine PN mit deiner Adresse und du bekommst Post!

LG

Franz
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 26 Mai 2014, 21:52:19
Hi,
ich wollte gerade mal wieder anfangen, die Konfiguration über's EEPROM einzubauen. Dabei habe ich ein kleines Problemchen, was denn das beste Design wäre. Es steht zur Auswahl:
Was meint ihr?
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 26 Mai 2014, 22:07:25
Hi Thorsten,

Die Zentrale hat grundsätzlich die volle Kontrolle über das EEprom.
Mit W kannst du also direkt in den Speicher schreiben. Und mit R Lesen.

Ich vermute das einige Daten nicht immer direkt aus dem EEprom gelesen werden. Das müsste man mal ausprobieren welche das sind.
Ich vermute das werden Geräteeinstellungen sein. Sicher nicht das Peering.
Mit 0x43 werden dann diese Daten eben neu eingelesen.
Diese Information stammt aber noch aus der HS485 Doku. Die Module reagieren zwar darauf. es ist aber gut möglich, dass das nicht mehr gebraucht wird.

0x43 und 0x21 Unterscheiden sich übrigens.
Bei 0x21 resetet wirklich der Controller. Also auch angesteuerte Ausgänge fallen dann wieder auf Default zurück.
Und dieser springt auch zum Bootloader.

Es gibt noch einen weiteren Reset 0x67 (g).
Hier wird nur ein Reset ausgeführt. Ohne Start am Bootloader.
Diesen Reset sollte man nach Konfigurationsänderungen ausführen.

Ich hoffe dass ich die Tage die überarbeitete Version der Doku fertig bekomme

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 27 Mai 2014, 00:03:45
So, das heutige Commit im GitHub kann wieder ein bisschen was Neues. Es werden jetzt Konfigurationsdaten aus dem EEPROM gelesen. Es werden die ersten 14 Byte gelesen, aber nur INPUT_LOCKED und LONG_PRESS_TIME wird wirklich verwendet.
Per FHEM kann man das leider nur per RAW-Kommando ausprobieren, da der entsprechende Dialog das nicht wirklich richtig macht. Es wird immer INPUT_LOCKED gesetzt und mit dem Lesen von LONG_PRESS_TIME stimmt etwas nicht. Beim zweiten Taster stimmt so ziemlich gar nichts. Ich habe das auch mit einem echten HMW-LC-Sw2-DR ausprobiert. Ich werde das noch in den Issue Tracker von FHEM-HM485 reinschreiben.

Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 27 Mai 2014, 11:04:40
Zitat von: Franz74 am 23 Mai 2014, 11:50:16@Thorsten, wenn du einen 1-Wire Fühler haben willst so schreib mir eine PN mit deiner Adresse und du bekommst Post!
Hi,
ich habe Dich nicht vergessen, aber die nächsten Tage wird das sowieso erstmal zeitlich schwierig. Ich hätte gerne erst einmal das von Dirk angesprochene XML. Dann würde ich versuchen, etwas dazu passendes zu bauen, was einfach die Analog-Eingänge vom Arduino verwendet.
Außerdem will ich mir eine CCU installieren. Die FHEM-Integration kann nicht wirklich mit der Konfiguration umgehen.
Schreib mir mal, welche Sensoren Du genau hast. Du hattest außer Temperatursensoren auch Counter erwähnt. Könntest Du zu beiden mal einen Link hier reinstellen, damit wir auch wirklich über das gleiche reden?
Danke&Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Franz74 am 27 Mai 2014, 12:05:57
Hallo Thorsten,

kein Problem und bitte keinen Stress es eilt nicht!

Wenn du einen ARM Einplatinencomputer hast kannst du dir einfach mit dem neuen lxccu Projekt eine per LXC Virtualisierte CCU2 installieren...

Und in dirks github ist das addon zum installieren seiner selfmade xml das die CCU2 den Selbstbau Sensor erkennt bereits zum download bereit:
https://github.com/kc-GitHub/Wettersensor/blob/master/Tools/CCU/HB-UW-Sen-THPL_CCU-addon.tgz (https://github.com/kc-GitHub/Wettersensor/blob/master/Tools/CCU/HB-UW-Sen-THPL_CCU-addon.tgz)

Dieses 1-Wire counter Modul habe ich
http://www.eservice-online.de/1-Wire-Bus/Digital-Ein-und-Ausgang-Analog-Eingang-Zaehler/1-Wire-Dual-S0-Zaehlermodul.html (http://www.eservice-online.de/1-Wire-Bus/Digital-Ein-und-Ausgang-Analog-Eingang-Zaehler/1-Wire-Dual-S0-Zaehlermodul.html)
Damit zähle ich einen Strom und einen Wasserzähler...

LG

Franz

PS: PN an mich mit deiner Adresse und du bekommst einen 1-Wire Temperatursensor...
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 27 Mai 2014, 12:22:31
Zitat von: Franz74 am 27 Mai 2014, 12:05:57
Und in dirks github ist das addon zum installieren seiner selfmade xml das die CCU2 den Selbstbau Sensor erkennt bereits zum download bereit:
Äh, fast. Hier ist das XML für den Funk-Universalsensor. für Wired noch nicht

Ich habe mir übrigens auch mal ein Paar 1-Wire Temperatursensoren (ds18b20+) bestellt.
Mist, hab grade gesehen dass der bei der Bestellung wohl aus dem Warenkorb geflogen ist.

Zitat von: Thorsten Pferdekaemper am 27 Mai 2014, 11:04:40
Ich hätte gerne erst einmal das von Dirk angesprochene XML.
Was soll das Device denn dann können / machen?
Dann baue ich die mal ein XML.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Franz74 am 27 Mai 2014, 12:27:05
Hallo Dirk,

Soll ich dir auch einen 1-Wire Temperaturfühler senden?

LG

Franz
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 27 Mai 2014, 12:30:12
Da sage ich nicht nein.
Die nächste Bestellung wird wohl noch ein paar Tage dauert.
Dann könnte ich damit schon mal spielen.

Wenn du willst kann ich ein paar 1-Wire-Sachen das nächste mal mitbestellen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 27 Mai 2014, 12:53:25
Zitat von: Franz74 am 27 Mai 2014, 12:05:57Wenn du einen ARM Einplatinencomputer hast kannst du dir einfach mit dem neuen lxccu Projekt eine per LXC Virtualisierte CCU2 installieren...
Das habe ich vor, alleine schon weil die Anbindung an FHEM für die ganzen EEPROM-Konfigurationen nicht so richtig funktioniert.
ZitatDieses 1-Wire counter Modul habe ich
Was genau liefert sowas denn als Output? Einen int?
ZitatPS: PN an mich mit deiner Adresse und du bekommst einen 1-Wire Temperatursensor...
Gerade rausgeschickt.

Zitat von: Dirk am 27 Mai 2014, 12:22:31Was soll das Device denn dann können / machen?
Dann baue ich die mal ein XML.
Erstmal als Beispiel: 5 1-Wire Temperatursensoren und 2 1-Wire Counter. Was da die geeigneten Datentypen sind weiß ich auch nicht so genau. Das Device soll sowohl auf Abfragen reagieren können als auch selbständig senden bei Überschreitung einer einstellbaren Differenz. Sowas in der Art habe ich mir gedacht.
Gruß,
   Thorsten 
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 27 Mai 2014, 19:19:32
Zitat von: Dirk am 22 Mai 2014, 09:48:13Evtl. hast du Zeit dir das mal anzusehen. Dann könnte man das gemeinsam entscheiden.
Ich habe jetzt eine CCU auf meinem RasPi installiert. Das Ding findet auch den HM485d.pl, zumindest sagt die CCU "verbunden" beim Status des RS485 Gateway. Dummerweise findet die CCU kein Gerät. Ich habe ein Original HMW-LC-Sw2-DR dranhängen, bei dem ich sogar ein Reset gemacht habe. Bei "Geräte anlernen" kann man "Geräte suchen" machen. An der Ausgabe des HM485d.pl kann ich sehen, dass ein kompletter Discovery-Lauf durchgeführt wird und an den Adressen kann ich auch sehen, dass der HMW-LC-Sw2-DR auch antwortet. Allerdings erscheint es nicht in der CCU.
Hat jemand einen Tipp?
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 27 Mai 2014, 19:26:27
Schau dir mal das Messages-Log der CCU an. Und setze den Loglevel vom dortigen HS485d auf Info.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 27 Mai 2014, 20:54:31
Hi,
das hier ist passiert während eines Discovery-Laufs:
May 27 20:50:08 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:08 homematic-ccu2 local0.info ReGaHss: Info: recvd 100 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:08 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:08 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:08 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #1 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:08 homematic-ccu2 local0.info ReGaHss: Info: recvd 104 bytes by web server #1 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:08 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:08 homematic-ccu2 local0.info ReGaHss: Info: http id #1 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:08 homematic-ccu2 user.debug hs485d: Doing discovery
May 27 20:50:08 homematic-ccu2 user.debug hs485d: HS485ControllerLGW::CheckBeforeSend(): Command type not handled: D (44  (hex) hex)
May 27 20:50:08 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:08 homematic-ccu2 local0.info ReGaHss: Info: recvd 326 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:08 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:08 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:09 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:09 homematic-ccu2 local0.info ReGaHss: Info: recvd 748 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:09 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /esp/system.htm?sid=@l2vLVgqZ7h@&action=UpdateUI [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:09 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:10 homematic-ccu2 user.err hs485d: response timeout
May 27 20:50:10 homematic-ccu2 user.err hs485d: HS485ControllerLGW::Discovery(): Error sending discovery (timeout).
May 27 20:50:10 homematic-ccu2 user.debug hs485d: 0 devices found
May 27 20:50:11 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:11 homematic-ccu2 local0.info ReGaHss: Info: recvd 100 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:11 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:11 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:11 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:11 homematic-ccu2 local0.info ReGaHss: Info: recvd 104 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:11 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:11 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:11 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:11 homematic-ccu2 local0.info ReGaHss: Info: recvd 442 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:11 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:11 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:12 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:12 homematic-ccu2 local0.info ReGaHss: Info: recvd 748 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:12 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /esp/system.htm?sid=@l2vLVgqZ7h@&action=UpdateUI [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:12 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:13 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:13 homematic-ccu2 local0.info ReGaHss: Info: recvd 326 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:13 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:13 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:15 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:15 homematic-ccu2 local0.info ReGaHss: Info: recvd 748 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:15 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /esp/system.htm?sid=@l2vLVgqZ7h@&action=UpdateUI [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:15 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:18 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:18 homematic-ccu2 local0.info ReGaHss: Info: recvd 748 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:18 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /esp/system.htm?sid=@l2vLVgqZ7h@&action=UpdateUI [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:18 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:18 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:18 homematic-ccu2 local0.info ReGaHss: Info: recvd 326 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:18 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:18 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:21 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:21 homematic-ccu2 local0.info ReGaHss: Info: recvd 748 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:21 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /esp/system.htm?sid=@l2vLVgqZ7h@&action=UpdateUI [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:21 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:21 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:21 homematic-ccu2 local0.info ReGaHss: Info: recvd 100 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:21 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:21 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:21 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:21 homematic-ccu2 local0.info ReGaHss: Info: recvd 104 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:21 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:21 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:23 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:23 homematic-ccu2 local0.info ReGaHss: Info: recvd 326 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:23 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:23 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:24 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:24 homematic-ccu2 local0.info ReGaHss: Info: recvd 748 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:24 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /esp/system.htm?sid=@l2vLVgqZ7h@&action=UpdateUI [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:24 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:25 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:25 homematic-ccu2 local0.info ReGaHss: Info: recvd 62 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:25 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:25 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:26 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:26 homematic-ccu2 local0.info ReGaHss: Info: recvd 748 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:26 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /esp/system.htm?sid=@l2vLVgqZ7h@&action=UpdateUI [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:26 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:27 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:27 homematic-ccu2 local0.info ReGaHss: Info: recvd 100 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:27 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:27 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:27 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:27 homematic-ccu2 local0.info ReGaHss: Info: recvd 104 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:27 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:27 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:28 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:28 homematic-ccu2 local0.info ReGaHss: Info: recvd 87 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:28 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:28 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:28 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:28 homematic-ccu2 local0.info ReGaHss: Info: recvd 326 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:28 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:28 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:28 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:28 homematic-ccu2 local0.info ReGaHss: Info: recvd 326 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:28 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:28 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:29 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:29 homematic-ccu2 local0.info ReGaHss: Info: recvd 748 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:29 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /esp/system.htm?sid=@l2vLVgqZ7h@&action=UpdateUI [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:29 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:30 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:30 homematic-ccu2 local0.info ReGaHss: Info: recvd 100 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:30 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:30 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
May 27 20:50:30 homematic-ccu2 local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
May 27 20:50:30 homematic-ccu2 local0.info ReGaHss: Info: recvd 104 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
May 27 20:50:30 homematic-ccu2 local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
May 27 20:50:30 homematic-ccu2 local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]


Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 27 Mai 2014, 23:45:38
Zitat von: Dirk am 26 Mai 2014, 22:07:25Ich vermute das einige Daten nicht immer direkt aus dem EEprom gelesen werden. Das müsste man mal ausprobieren welche das sind.
Ich vermute das werden Geräteeinstellungen sein. Sicher nicht das Peering.
Mit 0x43 werden dann diese Daten eben neu eingelesen.
Ich habe jetzt mal ein bisschen mit dem Peering herumgespielt. Da ich keine funktionierende CCU habe musste ich ziemlich viel mit set ... RAW rumprobieren, was etwas aufwändig ist. Ich habe aber herausgefunden, dass das Peering und auch Änderungen an den ganze Zeiten (ONDELAY, OFFDELAY etc.) kein 0x43 braucht.
Damit ist das Design für's EEPROM Lesen klar: Grundsätzliche Daten ("master") werden am Anfang, bei 0x43 etc. gelesen und ins SRAM kopiert. Das sind beim HMW-LC-Sw2-DR die ersten 14 Byte, also unkritisch. Alles, was darüber hinaus geht (Peering, Zeiten etc.) wird dann gelesen, wenn's gebraucht wird.
Gruß,
    Thorsten 
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 27 Mai 2014, 23:57:14
Hi Thorsten,

Das Loglevel vom ReGaHss kannst du runterschrauben. Das stört nur.
Dennoch ist das merkwürdig dass das bei dir aktuell nicht funktioniert.
Wenn die lust hast können wir das morgen abend oder so mal zusammen per Skype durchspielen.
Das muss funktionieren.

ZitatMay 27 20:50:10 homematic-ccu2 user.err hs485d: response timeout
Finde ich merkwürdig

Schau dir das Log mal beim starten der CCU an. Die Meldungen vom hs485d sind da interessant.

ZitatIch habe aber herausgefunden, dass das Peering und auch Änderungen an den ganze Zeiten (ONDELAY, OFFDELAY etc.) kein 0x43 braucht.
Ich werde das nochmal durchspielen.
Ich überarbeite auch das FHEM modul aktuell. So das diese Sachen hier auch bald laufen sollten.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 28 Mai 2014, 07:58:46
Ich hatte das gleiche Problem, dass die CCU keine Geräte gefunden hat.
Beim Discovery "Geräte anlernen" sehe ich Meldungen auf dem Bus. Aber die CCU hat auf nichts reagiert.
Irgendwie scheint die CCU von dem Daemon nichts zu empfangen. Der selbe als auch gleiche Daemon funktioniert mit fhem allerdings.


Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 28 Mai 2014, 09:08:34
Zitat von: Dirk am 27 Mai 2014, 23:57:14Wenn die lust hast können wir das morgen abend oder so mal zusammen per Skype durchspielen.
Ich fliege heute mal wieder nach London. Ab dem 5.Juni geht das erst wieder.
Zitat
Finde ich merkwürdig
Vielleicht ist auch das hier interessant:
May 27 20:50:08 homematic-ccu2 user.debug hs485d: HS485ControllerLGW::CheckBeforeSend(): Command type not handled: D (44  (hex) hex)
Ein 0x44 ist in Deiner Doku nicht aufgeführt. Vielleicht fehlt da irgendwo was?
ZitatIch überarbeite auch das FHEM modul aktuell. So das diese Sachen hier auch bald laufen sollten.
Das wäre schön, momentan ist eine Weiterentwicklung des Arduino-Codings doch sehr aufwändig.

Zitat von: stephan-221 am 28 Mai 2014, 07:58:46Beim Discovery "Geräte anlernen" sehe ich Meldungen auf dem Bus. Aber die CCU hat auf nichts reagiert.
Irgendwie scheint die CCU von dem Daemon nichts zu empfangen. Der selbe als auch gleiche Daemon funktioniert mit fhem allerdings.
Irgendwas scheint die CCU schon zu empfangen, da als Status ja "verbunden" angezeigt wird. Wenn man den Daemon im Vordergrund und mit --verbose 3 startet, dann sieht man auch, dass beim Discovery-Lauf die Adresse tatsächlich auf das existierende Device eingegrenzt wird. ...oder macht das der Daemon selbst?

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 28 Mai 2014, 10:28:12
Zitat von: stephan-221 am 28 Mai 2014, 07:58:46
Ich hatte das gleiche Problem, dass die CCU keine Geräte gefunden hat.
Ich schaue mir das noch mal an. Welche Version der CCU auf dem RPI benutzt ihr?
lxccu?

ZitatEin 0x44 ist in Deiner Doku nicht aufgeführt. Vielleicht fehlt da irgendwo was?
Vielleicht ein Teil der Komunikation CCU -> HMW-LAN. Auf Busseite kenne ich 0x44 zumindest nicht.

ZitatIrgendwas scheint die CCU schon zu empfangen, da als Status ja "verbunden" angezeigt wird.
Das ist die Verbindung von CCU zum HM485d

Zitat...oder macht das der Daemon selbst?
Ja. Das Discovery macht der HM485d bzw. auch ein HMW-LAN-GW selber.
Es werden "nur" die gefundenen Geräte an die CCU gemeldet.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 28 Mai 2014, 11:13:25
Zitat von: Dirk am 28 Mai 2014, 10:28:12
Ich schaue mir das noch mal an. Welche Version der CCU auf dem RPI benutzt ihr?
lxccu?
Ja.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Franz74 am 30 Mai 2014, 08:56:46
Hallo Dirk, Thorsten,

2 Briefe sind unterwegs...

LG

Franz
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 07 Juni 2014, 21:29:47
Hi,
Jetzt klappt's auch mit der CCU2!
Die neuste Version im git wird von einer CCU2 als Original HMW-LC-Sw2-DR erkannt. Dazu muss man eine Taste drücken (also Pin 5 oder 6 auf GND ziehen), da der Discovery Mode noch nicht implementiert ist. Das liegt im Wesentlichen daran, dass bei meiner CCU (lxccu auf RPi) Discovery nicht funktioniert, auch nicht mit Original-HMW Geräten.
Das Teil wird dann erkannt und man kann auch verschiedene Dinge damit tun:
Direkte Verknüpfungen (Peering) gehen leider noch nicht, nur Verknüpfungen über die Zentrale funktionieren bisher.

Ein kleines Problem hatte ich beim Pairing mit den "E" und "e" Messages. Wenn die CCU ein Gerät erkennt, dann schickt sie eine E-Message und erwartet anscheinend eine "e"-Message zurück. Ich habe keine Ahnung, was die Daten bedeuten und sende immer konstant das zurück, was mein Original-Aktor auch schickt. (Das war bisher immer 00 00 10 1F 00 00 00 00 00 60 00.)

@Franz: Dein Temperatursensor ist angekommen und ich habe auch schon einen kleinen Test-Sketch, der auch funktioniert. ...allerdings noch nicht als HMW-Device.

Gruß,
    Thorsten

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 08 Juni 2014, 22:48:27
Hi,
ich habe jetzt im git ein bisschen umstrukturiert. Es gibt jetzt Verzeichnisse für jedes Device. Ich habe auch ein paar Readme-Dateien spendiert.
Außerdem habe ich die erste Version eines HMW-Geräts, das die durch einen 1-Wire-Sensor gemessene Temperatur in einer CCU anzeigen kann. (Siehe Anhänge.) Das Teil erscheint als HWB-ONEWIRE, device type 129 (0x81). Dafür habe ich auch eine XML-Datei gebastelt, die man auf die CCU kopieren muss (/firmware/hs485types). Das Device reagiert nicht auf Discovery, aber es schickt alle 30 Sekunden die Temperatur und eine Announce-Message. Dadurch erkennt die CCU das Device automatisch, auch ohne Discovery.
Momentan gehen leider nur positive Temperaturen und auch nur genau ein Sensor, aber das wird noch besser. (Falls die CCU überhaupt negative Zahlen kennt...)
In FHEM dürfte das Ding nicht funktionieren (außer vielleicht per set RAW), da die FHEM-Integration noch nicht mit den XMLs funktioniert.
Gruß,
   Thorsten



Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Franz74 am 09 Juni 2014, 11:37:57
Hallo Thorsten,

Wow du bist der hit!

1-Wire am HM Wired Bus, genial!

Jetzt musst du nur noch einen Busmaster im Arduino Teil erstellen welcher eine XML mit den am 1-Wire bus befindlichen Geräten erstellt und diese irgendwie in die ccu über tragen...

LG

Franz

Gesendet von meinem Nexus 4 mit Tapatalk

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 09 Juni 2014, 12:06:54
Zitat von: Franz74 am 09 Juni 2014, 11:37:57Wow du bist der hit!
Danke.
ZitatJetzt musst du nur noch einen Busmaster im Arduino Teil erstellen welcher eine XML mit den am 1-Wire bus befindlichen Geräten erstellt und diese irgendwie in die ccu über tragen...
Keine Ahnung, wie das gehen soll. Ich denke nicht, dass wir das über RS485 schaffen können. Außerdem müsste man dann jedem Gerät einen eigenen Device Type geben. ...und das Übertragen müsste vor dem Pairing stattfinden.
Mein Plan ist momentan der: Das Device bekommt eine gewisse Anzahl von Analog-Channels, die dem entspricht, was an Sensoren maximal sinnvoll ist. (10? 25?) Beim Einschalten (setup()) wird der 1-Wire-Bus gescannt. Die gefundenen Adressen werden dann auf die ersten Channels gemappt. Z.B. wenn 3 Sensoren gefunden werden, dann bleiben eben die Channels 4 bis 10 leer, zeigen also immer 0.00 an.
Um das ganze etwas stabiler zu machen, könnte ich auch die gefundenen Adressen ins EEPROM schreiben. Dann würde die Zuordnung stabil bleiben, auch wenn mal ein Sensor ausfällt. Nur neu gefundene würden dann hinzugefügt werden.
Als kleines Extra könnte ich dann auch gleich die restlichen Channels von hinten mit Analog-Ports "auffüllen" und die restlichen Pins als "Key" definieren. Dann hätte man tatsächlich ein recht flexibles Device.
Irgendwie scheint es auch zu gehen, Channels flexibel zu definieren. Z.B. gibt es HMW-Devices, bei denen man Kanäle auf Input oder Output umschalten kann. Außerdem Eingänge, bei denen man Digital oder Analog wählen kann. Vielleicht kann man das mit den Eigenschaften der gefundenen Sensoren verbinden. Der CCU könnte man vorspielen, dass das ganz normale EEPROM-Einträge sind, aber die Werte würden dann tatsächlich vom 1-Wire-Bus ermittelt.
...aber das müsste sich Dirk mal ansehen, da mir nicht klar ist, was mit den XMLs so alles geht.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 09 Juni 2014, 19:09:16
Zitat von: Thorsten Pferdekaemper am 08 Juni 2014, 22:48:27
Außerdem habe ich die erste Version eines HMW-Geräts, das die durch einen 1-Wire-Sensor gemessene Temperatur in einer CCU anzeigen kann.
Cool. Da hast du ja einiges geschafft.

Zitat von: Franz74 am 09 Juni 2014, 11:37:57
Jetzt musst du nur noch einen Busmaster im Arduino Teil erstellen welcher eine XML mit den am 1-Wire bus befindlichen Geräten erstellt und diese irgendwie in die ccu über tragen...
Ich glaube das braucht man nicht mal.
Es muss für jeden Kanal lediglich ein Typ eingestellt werden.
Also nehmen wir an ein 1-Wire Busmaster der 7 Kanäle zur Verfügung stellt kann an Kanal 1-7 entweder ein Temperaturwert, ein Counter oder was auch immer anzeigen.
Das wird dann im XML definiert.

Zitat von: Thorsten Pferdekaemper am 09 Juni 2014, 12:06:54
Mein Plan ist momentan der: Das Device bekommt eine gewisse Anzahl von Analog-Channels, die dem entspricht, was an Sensoren maximal sinnvoll ist. (10? 25?) Beim Einschalten (setup()) wird der 1-Wire-Bus gescannt. Die gefundenen Adressen werden dann auf die ersten Channels gemappt.
So hätte ich mir das auch vorgestellt.
Allerdings nicht nur Analog, sondern Kanäle mit der entsprechenden Funktion.

ZitatUm das ganze etwas stabiler zu machen, könnte ich auch die gefundenen Adressen ins EEPROM schreiben. Dann würde die Zuordnung stabil bleiben, auch wenn mal ein Sensor ausfällt. Nur neu gefundene würden dann hinzugefügt werden.
Das sollte auf alle Fälle so sein.
Ggf. bekommt der Sensor noch Befehle um den Scan zu starten bzw. um einzelne Adresen zu löschen o.Ä.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 09 Juni 2014, 20:21:45
Zitat von: Dirk am 09 Juni 2014, 19:09:16Also nehmen wir an ein 1-Wire Busmaster der 7 Kanäle zur Verfügung stellt kann an Kanal 1-7 entweder ein Temperaturwert, ein Counter oder was auch immer anzeigen.
Das wird dann im XML definiert.
Ich nehme mal an, Du meinst nicht, dass es für jede Variante ein eigenes XML geben soll. Oder?
Zitat
So hätte ich mir das auch vorgestellt.
Allerdings nicht nur Analog, sondern Kanäle mit der entsprechenden Funktion.
Das sollte auf alle Fälle so sein.
Mach mir mal so ein flexibles XML. Ich versuche dann, den Sketch dazu zu basteln. (...auch wenn ich nur den einen Sensor habe.)
ZitatGgf. bekommt der Sensor noch Befehle um den Scan zu starten bzw. um einzelne Adresen zu löschen o.Ä.
...oder zumindest den "!"-Befehl.

Gruß,
    Thorsten

EDIT: Das mit dem "!"-Befehl ist natürlich Quatsch.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 09 Juni 2014, 23:59:04
So, die git-Version von heute hat mal wieder ein paar Neuerungen:
Ich konnte das nicht mit mehreren Sensoren testen, da ich nur einen habe.
Außerdem werden die Sensor-Adressen noch nicht ins EEPROM geschrieben. Es kann also nicht garantiert werden, dass die Zuordnung von Sensor zu Channel konstant bleibt. Das soll aber auch noch kommen.

Es wäre ganz nett, wenn das Ding noch jemand ausprobieren könnte.
Ich wäre auch daran interessiert, wenn jemand mal die "E" und "e" Messages beim Pairen an die CCU von verschiedenen Devices aufzeichnen könnte. Momentan mache ich einfach das nach, was ich bei meiner CCU gesehen habe, aber das muss ja nicht immer genau so sein.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Franz74 am 10 Juni 2014, 08:54:29
Hallo Thorsten,

ich habe die Sensoren inzwischen noch günstiger gefunden und zwar hier:
http://www.ebay.at/itm/5pcs-DS18B20-Waterproof-Digital-Thermal-Probe-Thermal-Sensor-18B20-for-Arduino-/231246952629?pt=Mess_Pr%C3%BCftechnik&hash=item35d76478b5 (http://www.ebay.at/itm/5pcs-DS18B20-Waterproof-Digital-Thermal-Probe-Thermal-Sensor-18B20-for-Arduino-/231246952629?pt=Mess_Pr%C3%BCftechnik&hash=item35d76478b5)

Der eine den ich dir gesendet habe kommt von dx.com, das dauert auf jeden Fall 3 Wochen bis eine Lieferung von dort Versandkostenfrei bei dir eintrifft...

Ich bin gerade dabei mir eine Platine zu "besorgen" und dann werde ich deine SW natürlich testen!

LG

Franz
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 10 Juni 2014, 12:55:31
Hi,
ich habe mir jetzt so ein 5er-Bündel bestellt. Das scheint aber auch mindestens zwei Wochen zu dauern. (Schicken die den Kram direkt aus China? Vielleicht sollte ich gleich mal 1000 bestellen und dann weiterverkaufen...)
Es gibt ja nicht nur Temperatursensoren. Was sollte denn sonst noch gehen?
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Franz74 am 10 Juni 2014, 13:38:50
Hallo Thorsten,

ich habe ein Counter Modul von hier:
http://www.eservice-online.de/1-Wire-Bus/ (http://www.eservice-online.de/1-Wire-Bus/)

Die haben aber auch noch andere Aktoren (Rolladen usw...)

Oder du baust dir ein 1-Wire IO Modul mit einer Platine aus dem Nachbarthread hier:
http://forum.fhem.de/index.php?topic=22045.0 (http://forum.fhem.de/index.php?topic=22045.0)

LG

Franz
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 10 Juni 2014, 14:35:48
Mmm...
Das ist mir momentan etwas zu teuer (Counter Modul) bzw. zu viel Gebastel für etwas, was ich momentan gar nicht brauche.
Ich würde sagen, ich mache erstmal mit den Temperatursensoren weiter. Wenn dann jemand konkret was anderes anschließen will, dann können wir das nach und nach einbauen.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Franz74 am 10 Juni 2014, 14:45:31
Hallo Thorsten,

sobald ich ein Platine habe werde ich gerne das Counter Modul Testen, aber das wichtigste hast du ja schon gemacht, die Temperaturmessung! Es gibt nichts auf dem Markt was so Genau und vor allem  Günstig Temperaturen Messen kann wie 1-Wire. Alles andere ist nur "Beifang"!

Die I/O's machen nur sinn wenn du z.B. deine Fenster / Türkontakte dezentral also z.B. pro Raum in eine Dose führst und dort mit dem 1-Wire Bus Kabel durchgehst, alles weitere ist gleich Teuer bzw. hat keinen Vorteil zum HM Wired Bus (außer vielleicht ein LED Dimmer ;-) )

Vielen Dank für deinen "Einsatz"!

LG

Franz
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 12 Juni 2014, 00:02:10
Hi,
das nächste Update für's 1-Wire Device ist im git. Ich bin nicht ganz so weit gekommen, wie ich wollte, da ich mich ein paar Mal um entschieden habe, wie das aussehen sollte.

Es ist jetzt vorgesehen, für die Sensorkanäle Einstellungen machen zu können (siehe Screenshot im Anhang). Man kann schon was einstellen und es wird auch von der CCU schon ins EEPROM des Device geschrieben, aber es bewirkt noch nichts. Das soll es bewirken:
Man kann ONEWIRE_TYPE auch ändern. Das ist natürlich nur bedingt sinnvoll.
@Dirk: Kann man sowas irgendwie auf Read-Only setzen?

Die zweite Sache ist ein "Factory Reset":
Voraussetzung ist, dass an Pin 5 ein Taster (gegen Masse, ist mit INPUT_PULLUP definiert) hängt und an Pin 13 eine LED (der Arduino-Uno hat da sowieso eine). Ich habe so ungefähr den Factory-Reset vom HMW-LC-Sw2-DR nachprogrammiert. Also:
Wenn man nach dem ersten Loslassen länger als 10 Sekunden wartet oder beim zweiten Mal nur kurz drückt, dann passiert nichts.
Das mit dem 0xFF muss ich nochmal überdenken, da die Defaults dann nicht überall richtig gesetzt werden. (Vor dem Schreiben lese ich jedes Byte, nur wenn es nicht sowieso 0xFF ist wird geschrieben.)

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 12 Juni 2014, 09:18:12
Hi Thorsten,

Du bist echt schnell.
Ich hoffe ich schaffe es am Wochenende hier auch mit zu machen.

Immerhin sind die neuen Platinen vom Sensorboard inzwischen gekommen.
Diese Sehen ganz gut aus:
http://forum.fhem.de/index.php/topic,20620.msg176142.html#msg176142

Ich mache am WE hier noch ein paar Tests damit.
Um die 1-Wire Sensoren da drauf zu bekommen, muss man lediglich auf die beiden Pinreihen Stecker- oder Buchsenleisten anbringen, dann kann ein Breakoutboard für 1-Wire oder was auch immer huckepack auf die Platine gesteckt werden.

ZitatKann man sowas irgendwie auf Read-Only setzen?
Ich meine schon. Muss ich mir am WE mal mit ansehen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 12 Juni 2014, 12:43:48
Zitat von: Dirk am 12 Juni 2014, 09:18:12
Du bist echt schnell.
Naja, ich habe bisher ein paar wichtige Sachen vom Protokoll einfach ignoriert. Das Modul wartet z.B. nicht auf einen freien Bus...

Zitat
Um die 1-Wire Sensoren da drauf zu bekommen, muss man lediglich auf die beiden Pinreihen Stecker- oder Buchsenleisten anbringen, dann kann ein Breakoutboard für 1-Wire oder was auch immer huckepack auf die Platine gesteckt werden.
Ich denke, das könnte ich für den HWB-1WIRE-TMP10 prototypenmäßig hinbekommen. Man braucht ja im Prinzip nur eine dreipolige Buchse für den 1-Wire-Bus. Ach ja: Hat die Platine überhaupt +5V oder reichen für 1-Wire auch 3,3V? Ansonsten braucht's doch etwas mehr.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 12 Juni 2014, 15:36:07
ZitatAch ja: Hat die Platine überhaupt +5V
Der RS485-Teil hat einen kleinen Schaltregler an Board der einen recht weiten Eingangsspannungsbereich von 6,5 V bis 30 V entgegennimmt und für den LT1785 5 V zur Verfügung stellt. Die 5 V können dann auch für andere Sensoren benutzt werden.
Dahinter ist noch ein kleiner Liniarregler der aus den 5 V 3,3 V für die restlichen Komponenten zur Verfügung stellt.

Der 1-Wire Part sollte trotzdem aus den 3,3 V Versorgt werden, weil sonst ggf. noch ein Pegelwandler notwendig ist.
Wenn keine weiteren 3,3 V Komponenten wie Sensoren verbaut sind, kann man den 3,3 V Spannungswandler auch weglassen und über eine Lötbrücke die Spannungsversorgung vom AVR auch auf 5 V umstellen. Somit ist man hier in der Spannungsversorgung recht flexibel.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 13 Juni 2014, 14:18:14
Zitat von: Dirk am 12 Juni 2014, 15:36:07Der 1-Wire Part sollte trotzdem aus den 3,3 V Versorgt werden, weil sonst ggf. noch ein Pegelwandler notwendig ist.
Ah, klar. Hatte ich nicht bedacht, wenn man die Dinger mit 5V antreibt, dann liefern sie auch 5V. Wenn für 1Wire aber auch 3,3V reicht, dann ist ja erstmal gut.

Kannst Du auf die RS485-Platinen auch wieder einen Arduino-Kompatiblen Bootloader brennen? Später können wir das ja ändern, aber momentan wäre das das einfachste.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 13 Juni 2014, 19:40:12
Zitat von: Thorsten Pferdekaemper am 13 Juni 2014, 14:18:14
Kannst Du auf die RS485-Platinen auch wieder einen Arduino-Kompatiblen Bootloader brennen? Später können wir das ja ändern, aber momentan wäre das das einfachste.
Ja, hier ist im Moment der Selbe drauf wie bei der Funkversion.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 Juni 2014, 01:26:54
Hi,
der neuste Update im git enthält folgende Neuerungen:
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 15 Juni 2014, 22:53:40
Hallo,

ich habe mal Thorsten seine Version jetzt auch auf den RS485-Fähigen Wettersensor-Platine (http://forum.fhem.de/index.php/topic,20620.0.html (http://forum.fhem.de/index.php/topic,20620.0.html)) "portiert".
Das war auch ein guter Test den RS485-Teil der Platine zu testen.

Auf dem Bildchen sind zwei 1-Wire Temperatur-Sensoren an der Platine.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Franz74 am 15 Juni 2014, 22:57:25
Hallo Dirk,

Super Arbeit!  Bis wann gibt es eine käufliche Version davon?

LG

Franz
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 16 Juni 2014, 00:12:07
Hi Franz,

ich kann die ein Platine bestücken.
Ich vermute ohne die "internen" Sensoren?

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 16 Juni 2014, 09:56:51
Hi Dirk,
ja, genau so habe ich mir den Anschluss an den 1-Wire-Bus vorgestellt...
Was für einen Anschluss (Stecker?) sollen wir dafür zur Verfügung stellen? Eine kleine Klinkenbuchse?
Gruß,
  Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Mr. P am 16 Juni 2014, 10:38:54
Zitat von: Thorsten Pferdekaemper am 16 Juni 2014, 09:56:51
ja, genau so habe ich mir den Anschluss an den 1-Wire-Bus vorgestellt...
Was für einen Anschluss (Stecker?) sollen wir dafür zur Verfügung stellen? Eine kleine Klinkenbuchse?
Ich glaub, das wird schwierig. Wenn ich da an Diskussionen denke, die hier bezüglich 1-wire Bus und welchen Anschluss man nehmen soll, geführt wurden, wird es immer 2-3 Meinungen geben. ;-)
Die einen wollen eine Klinkenbuchse, die anderen Schraubklemmen, und dann gibt es bestimmt noch welche, die ganz was anderes wollen. ;-)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 16 Juni 2014, 17:35:25
Zitat von: Mr. P am 16 Juni 2014, 10:38:54
Ich glaub, das wird schwierig. Wenn ich da an Diskussionen denke, die hier bezüglich 1-wire Bus und welchen Anschluss man nehmen soll, geführt wurden, wird es immer 2-3 Meinungen geben. ;-)
Die einen wollen eine Klinkenbuchse, die anderen Schraubklemmen, und dann gibt es bestimmt noch welche, die ganz was anderes wollen. ;-)
Klar, dass man das nicht jedem Recht machen kann. Man kann aber mal fragen, vielleicht gibt es ja eine Tendenz.
Ich hab jetzt mal ein bisschen rumgesucht. Es scheint so zu sein, dass RJ11/12 bzw. RJ45 so eine Art Standard ist.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Mr. P am 16 Juni 2014, 23:55:24
Zitat von: Thorsten Pferdekaemper am 16 Juni 2014, 17:35:25
Klar, dass man das nicht jedem Recht machen kann. Man kann aber mal fragen, vielleicht gibt es ja eine Tendenz.
Ich hab jetzt mal ein bisschen rumgesucht. Es scheint so zu sein, dass RJ11/12 bzw. RJ45 so eine Art Standard ist.
*lol* - wo wir auch schon beim Thema wären.
Ich zB mag die RJxy dafür überhaupt nicht. Dem würde ich Schraubklemmen immer noch vorziehen, denn die Crimperei von diesen Steckern ist immer eine Frickelei, man muss (je nach Kabel) gute Nerven mitbringen und natürlich hat nicht ein jeder entsprechendes Crimpequipment daheim. Bei Klinkensteckern wird einfach angelötet, bei Schraubklemmen überhaupt nur festgezogen und fertig! :-)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 10 Juli 2014, 22:52:01
Hi,
ich habe endlich mal wieder Zeit und Muße gefunden und mich wieder um die Firmware zum HMW-1-Wire gekümmert.
Eine dicker Brocken sind die E/e-Messages, die beim Pairing zwischen Zentrale und Device ausgetauscht werden. Wenn da was nicht stimmt, dann übernimmt die Zentrale die Einstellungen des Geräts nicht korrekt. Das war beim HMW-1Wire-Device auch so und sollte jetzt besser klappen. (Update von gerade eben im Git.)
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 18 Juli 2014, 12:32:03
Hi,
bei mir funktioniert jetzt Dirks Platine auch mit vier Sensoren. (Siehe Bilder.)
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 18 Juli 2014, 13:39:45
Ganz schön warm bei dir :)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 18 Juli 2014, 14:14:45
Die gefühlte Temperatur liegt noch höher und außerdem ist's hier drinnen noch relativ kühl.

Ich habe jetzt unsere Versionen der Firmware zusammengebracht. Die aktuelle Version in meinem Git-Branch enthält jetzt meine neusten Entwicklungen und ist mit dem Sensor-Board kompatibel.
Es gibt außerdem eine Compiler-Direktive (#define DEBUG_UNO), mit der man das ganze auf die Version mit SoftwareSerial zurückschalten kann. Allerdings haben sich die Pins gegenüber meiner alten Version etwas geändert, auch wenn man mit "DEBUG_UNO" übersetzt.

#ifdef DEBUG_UNO
  #define RS485_RXD 5
  #define RS485_TXD 6
  #define LED 13        // Signal-LED
#else
  #define LED 4         // Signal-LED
#endif
#define BUTTON 8            // Das Bedienelement
#define RS485_TXEN 2        // Transmit-Enable

#define ONEWIRE_PIN A3

Ich habe außerdem herausgefunden, dass man den USB-Adapter vom Hardware-UART abstöpseln muss, damit die Platine etwas empfängt. Ansonsten funktioniert nur senden. Keine Ahnung warum...
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 20 Juli 2014, 18:34:33
Hi,
es regnet...
Im aktuellen git gibt es folgende Neuigkeiten:

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 20 Juli 2014, 20:44:58
Hi,
es gibt jetzt auch einen ordentliche Wiki-Eintrag:
http://www.fhemwiki.de/wiki/HWB-1WIRE-TMP10 (http://www.fhemwiki.de/wiki/HWB-1WIRE-TMP10)
...es kann sich trotzdem noch so einiges ändern, aber wenn ich's nicht dokumentiere, dann verliere ich selbst so langsam den Überblick.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: ph1959de am 21 Juli 2014, 07:52:57
Hallo Thorsten,

ich hätte als Bezeichnung HB-1W-TMP10 erwartet ... habe ich das Namensschema im Wiki (http://www.fhemwiki.de/wiki/Kategorie:HomeBrew) falsch verstanden?

Peter
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 21 Juli 2014, 10:43:37
Zitat von: ph1959de am 21 Juli 2014, 07:52:57ich hätte als Bezeichnung HB-1W-TMP10 erwartet ...
Hi,
da hast Du recht, die Namensgebung ist nicht wirklich richtig. Danke für den Hinweis. Es ist allerdings kein "HB". Eigentlich müsste es sogar so heißen:
     HBW-1W-T10 oder sogar HBW-1W-T10-PCB
(siehe http://www.fhemwiki.de/wiki/HomeMatic_Namen_verstehen (http://www.fhemwiki.de/wiki/HomeMatic_Namen_verstehen))

Ich werde das demnächst noch ändern, komme aber vor übernächster Woche wahrscheilich nicht dazu. Es ist leider mit einer Änderung im Wiki nicht getan.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 23 Juli 2014, 22:04:05
Hallo zusammen,
hier hat sich in letzter Zeit ja richtig was getan! Mir hat in den letzten Wochen leider etwas die Zeit gefehlt, um mich mit dem Thema zu beschäftigen...
Ich habe allerdings angefangen, mir über einen Bootloader Gedanken zu machen. Für den Fall, dass die Eigenbau-Geräte mal irgendwo im Haus fest eingebaut sein sollten und man doch noch das ein oder andere Update einspielen möchte, könnte ein Bootloader, der den HM485-Bus verwendet, ja nützlich sein.

Meine Idee habe ich hier beschrieben:
https://github.com/kc-GitHub/HM485-Lib/tree/markus/hmwProgrammer (https://github.com/kc-GitHub/HM485-Lib/tree/markus/hmwProgrammer)
Mich würde Eure Meinung interessieren, ob so ein Bootloader überhaupt Sinn macht und was ihr von dem Konzept haltet.

Beim Bootloader selbst besteht derzeit noch das Problem, dass die ID des Geräts fest im Code implementiert ist, d.h. der Source-Code des Bootloaders müsste für jedes Gerät angepasst werden, um eindeutige IDs zu erhalten. Was haltet Ihr von den folgenden Ideen, um eindeutige IDs zu generieren?
- nachträgliche Vergabe der ID manuell (z.B. mit Befehl über serielle Schnittstelle)
- an jeden Client einem 1-wire Sensor anschließen - die 1-wire Sensoren haben angeblich alle eine eindeutige ID, die vom Client übernommen werden könnte
- generierung einer zufälligen ID, indem das Rauschen eines AD-Kanals ausgenutzt wird
- Zeitabstand auswerten (z.B. vom Reboot bis zum ersten Tastendruck oder dem ersten Empfang einer Busnachricht)
- sonstige Möglichkeiten?

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 24 Juli 2014, 21:21:55
Hallo zusammen,

ich war auch lange Zeit zu beschäftigt um an dem Thema zu arbeiten. Aber ich habe diese Woche auch etwas geschafft. Ich habe ein neues Device HBW-Sec-MDIR-2 (bei mir sollte die Bezeichnung stimmen :-) )angelegt. Das Device soll ein Unterputz-Gerät zur Anschaltung eines MDIR von Jung, Berker oder Gira an den HM485 realisieren. Damit ist es dann möglich einen Bewegungsmelder und sogar auch einen Präsenzmelder zu integrieren. Die Schaltung und die Logik stammt von: http://www.mikrocontroller.net/articles/24V_UP-Einsatz_f%C3%BCr_Bewegungsmelder_von_Jung,_Berker_und_Gira (http://www.mikrocontroller.net/articles/24V_UP-Einsatz_f%C3%BCr_Bewegungsmelder_von_Jung,_Berker_und_Gira). Die Firmware habe ich für Arduino bereits portiert. Die "richtige" Hardware muss noch angpasst werden. Tests stehen allerdings noch aus, da mir noch ein paar Bauteile fehlen, die ich diese Woche noch bestellen will.

Ich habe noch ein paar architekturelle Verbesserungen gefunden, die ich in einem nächsten Commit beisteuern werde, um doppelten Code zu beseitigen.

@Markus: Mit deinem Bootloaderkonzept könnte man zumindest Entwicklungsseitig ein FW-Update durchführen. Ich glaube ein FW-Update sollte auch von FHEM oder CCU funktionieren. Das ist mir noch nicht klar wie das mit deinem Konzept funktioniert. Die Vergabe der ID über einen Zeitbezug halte ich auch für sinnvoll. Hier sollte aber trotzdem sichergestellt werden, das es keine Dopplungen mit den Seriengeräten gibt. Vielleicht kennt ja jemand den Vergabealgorithmus oder man müsste als Fallback noch die manuelle Vergabe integrieren.

Gruß Rene 
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 25 Juli 2014, 00:07:04
Hallo,

der Bootloader zum Updaten über den Bus sollte auf alle Fälle noch kommen.

Die Adresse, die Seriennummer und ggf. sogar den Devicetype würde ich hier gerne im Hexfile des Bootloaders an definierten Adressen mit unterbringen. Vorteil: Man kann die Firmware flashen ohne diese Infos zu überschreiben. Das ist bei den fertigen Devices übrigens auch so implementiert.

Beim Flashen des Bootloaders kann man diese Informationen mit übergeben. So ähnlich mache ich das auch bei der Firmware vom Univeralsensor auch schon. Dort zwar noch nicht im Bootloader, aber das Verfahren währ ähnlich. Die zufällige Vergabe der Daten kann dann auch das "Flash-Tool" übernehmen.
Und da der Bootloader hier sowieso geflasht werden muss, können diese Infos dann hier auch mit rein.

Ein Speichern der Informationen im EEprom ist nicht ganz ungefärlich. Denn die CCU bzw. die Zentrale hat normalerweise die volle Kontrolle über den kompletten EEprom-Speicher eines Gerätes. Ansonsten muss man hier einen bestimmten Speicherbereich speziell schützen.

Gruß
Dirk

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 25 Juli 2014, 14:22:44
Hallo,

ZitatDie Adresse, die Seriennummer und ggf. sogar den Devicetype würde ich hier gerne im Hexfile des Bootloaders an definierten Adressen mit unterbringen.
Das halte ich auch für gut. Wobei die Seriennummer durchaus auch aus der aktuellen Systemzeit des Rechners generiert werden kann. Für mein neu angelegtes Device brauche ich auch noch einen Devicetype. Kann ich mir da einfach einen definieren oder muss ich irgendwelche Regeln befolgen?

ZitatSo ähnlich mache ich das auch bei der Firmware vom Univeralsensor auch schon.
Ist die Firmware dafür auch auf Arduino portiert ?

Gruß Rene
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: justme1968 am 25 Juli 2014, 15:03:21
wäre hier nicht auch ein i2c mac chip für die serien nummer gut?

gruss
  andre
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 25 Juli 2014, 17:19:58
Zitat von: justme1968 am 25 Juli 2014, 15:03:21
wäre hier nicht auch ein i2c mac chip für die serien nummer gut?
Ich finde die Idee nicht so gut.
Siehe hier: http://forum.fhem.de/index.php/topic,20620.msg186635.html#msg186635

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 25 Juli 2014, 17:49:18
Zitat von: reneFHEM am 25 Juli 2014, 14:22:44
Für mein neu angelegtes Device brauche ich auch noch einen Devicetype. Kann ich mir da einfach einen definieren oder muss ich irgendwelche Regeln befolgen?
Regeln sind mir nicht bekannt.
Die RF-Devices haben 2 Bytes als Devicetype. HM-Wired Geräte theoretisch auch, aber hier bin ich mir derzeit nicht so sicher. Hiuer scheint nur ein Byte benutzt zu werden. Das will ich aber noch mal untersuchen.

Für die RF-Devices haben wir hier die ID-Bereiche dokumentiert.
http://www.fhemwiki.de/wiki/Kategorie:HomeBrew

Du kannst ja erstmal eine höheren ID testen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 27 Juli 2014, 21:17:48
Zitat von: Dirk am 25 Juli 2014, 00:07:04Ein Speichern der Informationen im EEprom ist nicht ganz ungefärlich. Denn die CCU bzw. die Zentrale hat normalerweise die volle Kontrolle über den kompletten EEprom-Speicher eines Gerätes. Ansonsten muss man hier einen bestimmten Speicherbereich speziell schützen.
Im Endeffekt hat die Firmware des Geräts die Kontrolle darüber. Ich könnte relativ einfach die paar Bytes irgendwo reservieren und in der Firmware verhindern, dass sie überschrieben werden. (Auch beim "Factory-Reset.) Für eine CCU würde dieser Bereich dann immer als "leer" (0xFF) erscheinen.
Dazu dann noch einen speziellen "Befehl" und man könnte die Adresse bzw. Seriennummer von außen setzen. Das würde dann sogar über den Bus gehen.
Gruß,
   Thorsten

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 28 Juli 2014, 19:01:03
ZitatDie Adresse, die Seriennummer und ggf. sogar den Devicetype würde ich hier gerne im Hexfile des Bootloaders an definierten Adressen mit unterbringen.
Wie wär's die Seriennummer im Hexfile der Applikation unterzubringen, z.B. an der letzten Adresse bevor der Bootloader beginnt? Das hätte den Vorteil, das die Seriennummer vom Bootloader selbst geändert werden könnte. Dann hätte man alle Optionen offen und könnte die Nummer direkt beim Flashen reinschreiben oder aber eine Nummer durch Tastendruck o.ä. selbst generieren.

ZitatIm Endeffekt hat die Firmware des Geräts die Kontrolle darüber. Ich könnte relativ einfach die paar Bytes irgendwo reservieren und in der Firmware verhindern, dass sie überschrieben werden. (Auch beim "Factory-Reset.) Für eine CCU würde dieser Bereich dann immer als "leer" (0xFF) erscheinen.
Seriennummer im EEPROM fänd ich auch ok. Allerdings besteht dann immer die Gefahr, dass eine unreife Firmware "mal eben zum testen" geflasht wird, die das EEPROM löschen könnte.

ZitatDas ist mir noch nicht klar wie das mit deinem Konzept funktioniert.
Die Idee hinter dem Bootloader ist folgende: Wenn die fertigen Geräte irgendwann mal verbaut sind, kann man sich in der Regel nicht mehr über einen Programmieradapter oder RS232 verbinden, sondern nur noch über den HM485-Bus. Das Konzept sieht so aus, dass das Programmiergerät (ein normaler Arduino mit RS485-Interface) sich so verhält, wie ein normaler Arduino-Bootloader, die Daten allerdings nicht selbst verarbeitet, sondern in das HM485-Protokoll verpackt und auf den Bus legt. Der Bootloader im HM485-Device packt die Nutzdaten aus und verhält sich dann wieder wie ein "normaler" Arduino-Bootloader.
Damit kann man ein HM485-Device so flashen, als wäre es direkt über USB (bzw. RS232) an den Rechner angeschlossen. Das Ganze fand ich ganz attraktiv, weil ja das ganze Projekt auf Arduino-Basis läuft. Und weil ich aus der Arduino-IDE heraus keine Möglichkeit kenne, beim Flashen eine individuelle Seriennummer zu generieren und ins Hex zu schreiben, müsste dieser Bootloader sich die ID selbst generieren.

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 28 Juli 2014, 20:16:12
Zitat von: ph1959de am 21 Juli 2014, 07:52:57ich hätte als Bezeichnung HB-1W-TMP10 erwartet ...
Hi,
das Ding ist jetzt umbenannt und nennt sich HBW-1W-T10 (auch im Wiki). Ich glaube, dass das mit dem Namensschema konform ist. Damit das auch richtig in der CCU dargestellt wird, muss man das alte XML "hwb_1wire_tmp10.xml" durch das neue "hbw_1w_t10.xml" ersetzen (im Verzeichnis /firmware/hs485types). Danach die CCU durchstarten, das Gerät löschen und neu anlernen.

Ich habe jetzt auch das .hex-File mit ins Git gehängt. (https://github.com/kc-GitHub/HM485-Lib/tree/thorsten/HBW-1W-T10 (https://github.com/kc-GitHub/HM485-Lib/tree/thorsten/HBW-1W-T10)) Damit braucht man eigentlich nur noch das XML und das HEX File.

Ach ja: Die Adresse ist jetzt 0x42FFFFFF und die ID ist HBW4073471. Das war zur Vorbereitung für eine flexiblere Vergabe der Adresse und ID.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 29 Juli 2014, 00:04:58
Hi,
mit der aktuellen Version im Git ist jetzt die Adresse und die Seriennummer einstellbar. Es funktioniert folgendermaßen:
Die Adresse steht in den obersten vier Byte des EEPROM, high Byte first. Was auch immer dort beim Reset (oder Einschalten) steht wird als Adresse benutzt. Eine Ausnahme ist 0xFFFFFFFF. Falls das in den obersten vier Byte steht, dann wird die Adresse 0x42FFFFFF benutzt. Das bedeutet, dass 0x42FFFFFF sozusagen die Default-Adresse ist.
Zum Ändern der Adresse gibt es den "@a"-Befehl (0x4061). Das "@" benutzt die CCU hoffentlich nie. D.h. das steht für "HomeBrew"... Danach das "a" steht für "adresse". Danach folgt die neue Adresse des Geräts. (Mit dem "W"-Befehl geht es nicht, die Geräte-Adresse ist vor normalen Befehlen geschützt.)
So etwas kann man natürlich nicht mit der CCU machen (soweit ich weiß), aber mit einem FHEM-RAW Befehl geht das:
set hm485 RAW 42FFFFFF 1C 00000001 406142000013 
Dieser Befehl würde die Geräte-Adresse auf 0x42000013 setzen. Danach muss man natürlich das "alte" Gerät löschen und das "neue" anlernen.

Die Seriennummer wird dann aus der Adresse ermittelt. Sie beginnt immer mit "HBW", danach kommen die letzten sieben Ziffern der Dezimaldarstellung der Adresse. Für 0x42000013 ergibt sich damit HBW7296275.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 31 Juli 2014, 22:19:43
Hallo zusammen,

mein neues Device spricht erfolgreich mit FHEM und gibt sich als HMW_LC_Sw2_DR aus. Bei jedem Sensorerignis wird ein press_short erzeugt. Nun wäre es sinnvoll eine "richtiges Device" für FHEM anzulegen. Dazu muss ich in lib/HM485/Devices ein neues Device anlegen. Gibt es eine Beschreibung über die einzelnen Attribute ?

Gruß Rene

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 01 August 2014, 01:01:32
Hallo Thorsten,

Zitat von: Thorsten Pferdekaemper am 29 Juli 2014, 00:04:58
mit der aktuellen Version im Git ist jetzt die Adresse und die Seriennummer einstellbar.
Ich bin mir imme noch nicht Sicher, warum man die Adresse und / oder die Seriennummer vom Device nachträglich ändern muss.
Aber mal sehen, vielleicht findet sich ja noch eine Anwendung.

ZitatDie Adresse steht in den obersten vier Byte des EEPROM, high Byte first.
Passt du das dann auch im XML-File an? Oder werden die ersten 4 Bytes vor der Zentrale versteckt? In der Regel stehen an Bytes 01 LOGGING_TIME und 02-05 CENTRAL_ADDRESS.
Wie erfolgt dann die Adressierung der anderen Register?

ZitatZum Ändern der Adresse gibt es den "@a"-Befehl (0x4061).
Warum nicht normal mit "W"? Wenn man die Adresse ohnehin mit Deinem Spezialbefehl ändern kann.
Warum aber 2 Bytes für den Befehl? Das würde dann nicht mehr so dem Protokoll entsprechen.

Ich würde diese Art der Seriennummernverwaltung ggf. per Compilerdirective schaltar machen. Dann kann man sich den Code für das Parsen von "@a" im AVR sparen wenn man z.B. die Seriennummer aus dem Bootloaderbereich lesen möchte.




Hallo Rene,

Zitat von: reneFHEM am 31 Juli 2014, 22:19:43
Nun wäre es sinnvoll eine "richtiges Device" für FHEM anzulegen. Dazu muss ich in lib/HM485/Devices ein neues Device anlegen. Gibt es eine Beschreibung über die einzelnen Attribute ?
Nein, Soweit bin ich mit den Modulen noch nicht.
Es wird aber daraus hinaus laufen, dass man eine XML-Datei ähnlich denen der CCU erstellt. Damit funktioniert dein Device dann auch gleich dort.
Mit einem kleinen Perl-Script wird dieses dann in ein entsprechendes Device-File für FHEM transformiert.
Ich habe die FHEM-Module dahin gehend schon umgestellt, dass das funktioniert. Das Script gibt es hier auch schon. Allerdings bin ich noch nicht ganz fertig.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 01 August 2014, 09:19:12
Zitat von: Dirk am 01 August 2014, 01:01:32Ich bin mir imme noch nicht Sicher, warum man die Adresse und / oder die Seriennummer vom Device nachträglich ändern muss.
Aber mal sehen, vielleicht findet sich ja noch eine Anwendung.
Normalerweise muss man das nachträglich nicht ändern, aber was garantiert uns, dass es nicht ein anderes Device (z.B. eins von eq3 selbst) gibt, welches nicht dieselbe Adresse hat? Das kann sogar nachträglich passieren, wenn man seine Installation um ein (eq3-)Device erweitert. Dann wäre es schon blöd, wenn man das Ding ausbauen muss zum Flashen.

ZitatPasst du das dann auch im XML-File an? Oder werden die ersten 4 Bytes vor der Zentrale versteckt? In der Regel stehen an Bytes 01 LOGGING_TIME und 02-05 CENTRAL_ADDRESS.
Da gibt es nichts anzupassen (bisher). Ich verwende die letzten vier Byte, nicht die ersten. Das wird nur problematisch, wenn wir wirklich das ganze EEPROM brauchen.

ZitatWie erfolgt dann die Adressierung der anderen Register?
Ganz normal. Warum sollte sich da was ändern?

ZitatWarum nicht normal mit "W"? Wenn man die Adresse ohnehin mit Deinem Spezialbefehl ändern kann.
Warum aber 2 Bytes für den Befehl? Das würde dann nicht mehr so dem Protokoll entsprechen.
Die CCU verwendet den "W"-Befehl. Wenn ein "W"-Befehl versucht, die letzten 4 Bytes zu schreiben, dann ignoriert der Sketch das. D.h. die letzten 4 Byte können mit dem "W"-Befehl nicht geschrieben werden. Das garantiert, dass die Zentrale nicht "versehentlich" die Adresse ändern kann.
Jetzt habe ich aber einen Mechanismus gebraucht, der mit dem bisherigen Protokoll kompatibel ist und mit Sicherheit nicht von der CCU (auch in Zukunft) verwendet wird. Deshalb der @-Befehl. Nach dem @ haben wir dann die Freiheit, zu tun was wir wollen. Die CCU schickt so etwas nicht. Der Ausbruch aus dem Protokoll war also Absicht.

ZitatIch würde diese Art der Seriennummernverwaltung ggf. per Compilerdirective schaltar machen. Dann kann man sich den Code für das Parsen von "@a" im AVR sparen wenn man z.B. die Seriennummer aus dem Bootloaderbereich lesen möchte.
Das kann ich gerne einbauen, sobald wir einen Bootloader haben, der eine Adresse/Seriennummer enthält. Momentan haben wir das aber nicht.

ZitatEs wird aber daraus hinaus laufen, dass man eine XML-Datei ähnlich denen der CCU erstellt. Damit funktioniert dein Device dann auch gleich dort.
Mit einem kleinen Perl-Script wird dieses dann in ein entsprechendes Device-File für FHEM transformiert.
Könnte man das automatisieren? Es wäre gut, wenn man das XML einfach in ein bestimmtes Verzeichnis kopieren könnte und der Rest von alleine passiert.

ZitatIch habe die FHEM-Module dahin gehend schon umgestellt, dass das funktioniert. Das Script gibt es hier auch schon. Allerdings bin ich noch nicht ganz fertig.
Hast Du die Beiträge hier gesehen? http://forum.fhem.de/index.php/topic,10607.255.html (http://forum.fhem.de/index.php/topic,10607.255.html)
Mir scheint, dass gevoo auch an den FHEM-Modulen arbeitet. Wisst Ihr voneinander?

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 01 August 2014, 21:20:34
Zitat von: Thorsten Pferdekaemper am 01 August 2014, 09:19:12
Normalerweise muss man das nachträglich nicht ändern, aber was garantiert uns, dass es nicht ein anderes Device (z.B. eins von eq3 selbst) gibt, welches nicht dieselbe Adresse hat?
Ja, ich weiß. Das habe ich im Universalsensor-Tread auch schon mal als Begründung angeführt warum es keine gute Idee ist die Seriennummer eines 1-Wire-MAC-IC als Adresse/Seriennummer zu benutzen.
Aber, vor allem bei Wired ist die Warscheinlichkeit sehr gering ein fertiges Device mit der selben Adresse/Seriennummer zu bekommen. Und dann kann man das entweder durch Flashen eines neuen Bootloaders fixen, oder wenn man das Gerät nicht ausbauen will, definiert man eine andere Adresse/Seriennummer in der Firmware und Flasht diese über den Bus (wenn das dann geht). Daher würde ich die Adresse/Seriennummer aus dem Bootloader auch nur als default benutzen und in der Lib die Möglichkeit lassen diese bei Bedarf zu überschreiben.

Noch eine andere Idee:
Man nimmt die Adresse/Seriennummer aus dem Bootloader und "schaltet" mit einem einfachen Befehl nur die letzte Stelle "weiter". Dann hätte man bis zu 255 unterschiedliche Nummern und braucht nur 1 Byte im EEprom dafür.

ZitatDas garantiert, dass die Zentrale nicht "versehentlich" die Adresse ändern kann.
Wenn laut XML-File die reservierten Bytes nicht benutzt werden sollte die Zentrale diese Adressen gar interessieren.

ZitatDie CCU schickt so etwas nicht. Der Ausbruch aus dem Protokoll war also Absicht.
Die CCU interessiert uns hier zwar nicht, dennoch würde ich gerne eine Lösung finden welche auch dort funktioniert. Daher könnte man das oben genannte "rotieren" der Adresse/Seriennummer z.B. auch beim Einschalten bei gedrückter Config-Taste auslösen.

ZitatDas kann ich gerne einbauen, sobald wir einen Bootloader haben, der eine Adresse/Seriennummer enthält. Momentan haben wir das aber nicht.
Ich bau dir einen. Ich denke dafür werde ich dan auch wieder ein Flash-Tool bauen, mit dem man Adresse und Seriennummer selber festlegen kann.

ZitatKönnte man das automatisieren?
Ja, kann man. Das Script verarbeitet auf Wunsch alle XML-Dateien im Verzeichniss. Das sollte man dann auch aus FHEM aus ausrufen können.

ZitatHast Du die Beiträge hier gesehen? http://forum.fhem.de/index.php/topic,10607.255.html (http://forum.fhem.de/index.php/topic,10607.255.html)
Mir scheint, dass gevoo auch an den FHEM-Modulen arbeitet. Wisst Ihr voneinander?
Ja, allerdings wegen fehlender Hardware hier :) hab ich mich da noch nicht eingemischt.
Auch das werde ich die nächsten Tage nachholen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 03 August 2014, 01:06:47
Hallo Thorsten,
in letzter Zeit hast Du ja einige neue Funktionen implementiert. Deshalb habe ich mir nochmal die neusten Files geholt und würde gerne darauf basierend weitere Module basteln (z.B. HMW-LC-Bl1).
Ich habe allerdings schon Probleme die Dateien aus dem Github zu kompilieren. Einige Fehlermeldungen konnte ich schon beseitigen, aber jetzt komme ich einfach nicht weiter. Bevor ich jetzt noch ewig weiter suche, wär meine Frage, welche IDE Du verwendest und ob Du evlt. deine Projektdatei zur Verfügung stellen könntest? Als IDE nutze ich bisher das Atmel Studio 6.2. Mit der Arduino-IDE ließ sich das Projekt auch nicht kompilieren (auch nicht nach Anpassen von Dateiname und -endung / alle *.cpp und *.h files im Sketch-Ordner, ...).

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 03 August 2014, 10:12:00
Hallo Markus,

als IDE verwende ich Eclipse Juno mit dem "Arduino eclipse plugin" von Jan Baeyens.
Mit der Arduino-IDE könnte es tatsächlich etwas schwierig werden, da die keine Libraries kann, die wiederum selbst Libraries einbinden. Über das Atmel Studio kann ich nichts sagen. Ich kann mir aber vorstellen, dass das ein paar Arduino-spezifische Sachen nicht hat.
Das Projekt-File und die Verzeichnisstruktur, wie sie zurzeit bei mir aussieht, findest Du im angehängten Zip-File. Es enthält zwei Verzeichnisse (HBW-1W-T10 und HMW), die direkt ins eclipse-workspace Verzeichnis gehören.

Das Projekt hat dann den Namen des Geräts (HBW-1W-T10) und verweist auf das Library-Verzeichnis (HMW).
Das Hauptprogramm (der Sketch) ist sozusagen HBW-1W-T10.cpp.

Falls das dann immer noch nicht klappt, dann stell' mal die Fehlermeldungen hier rein. Das Projekt ist ja nicht wirklich komplex, das müsste hinzubekommen sein.

Noch ein Hinweis für Deine Entwicklungen: Die Struktur der HMW-Lib ist noch nicht stabil. Außerdem fehlt noch ein ganz großer Teil. Das Protokoll interessiert sich momentan noch nicht für andere Geräte auf dem Bus und sendet einfach drauflos. Es gibt noch keine Kollisionserkennung, keine Retries etc. Es wird also sicherlich passieren, dass sich das ganze noch ändert und die Änderungen nicht abwärtskompatibel sind. Ich werde das aber immer hier im Forum veröffentlichen.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 03 August 2014, 11:15:07
Hi Thorsten,

anbei der Bootloader mit Adress-Data-Bereich. Der Quellcode ist auch mit dabei. die addressData Section ist am ende vom C-File und auch am Ende des Bootloader bereiches im Hexfile. Dort kannst du die Daten auch ändern bis ich dafür das Flashtool angepasst habe.
Der Bootloader lässt sich im Eclipse kompilieren.

Die Firmware die über diesen Bootloader in den AVR kommt muss aber noch wie bisher seriell geflasht werden. Also nicht über den Bus.

an Adresse 0x7FF1 steht der Devicetype (wenn man den benutzen möchte)
an Adresse 0x7FF2 stehen die 10 Bytes der Seriennummer
an Adresse 0x7FFC stehen dann doe 4 Bytes der Serriennummer.

Im Kompilierten Hex-File stehen aktuell folgende Daten:
Device-Type: 0x81 (129)
Seriennummer: HBW0000001
Seriennummer: 0x42 0x43 0x44 0x45

Viele Grüße
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 03 August 2014, 12:29:50
Hi Dirk,

ich weiß noch nicht so genau, wie ich den Bootloader brennen kann.
Ich denke mal, ich nehme einen Uno und verdrahte das sinngemäß so:
http://arduino.cc/en/Tutorial/ArduinoISP (http://arduino.cc/en/Tutorial/ArduinoISP)
Brauche ich tatsächlich den 10uF Kondensator?

...und dann sowas wie das hier:
avrdude -c arduino -p atmega328 -P COMPORT -b 19200 -U flash:w:filetoburn.hex

Würde das gehen?

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 03 August 2014, 14:04:02
Zitat von: Thorsten Pferdekaemper am 03 August 2014, 12:29:50
ich weiß noch nicht so genau, wie ich den Bootloader brennen kann.
Ah, ok. da werde ich mal noch einen Beitrag im Wiki dazu schreiben müssen.
Wenn man keinen weiteren Arduino hat, würde das auch mit dem Raspberry Pi gehen.

ZitatBrauche ich tatsächlich den 10uF Kondensator?
Nö. Eigentlich nicht.

Zitat...und dann sowas wie das hier:
Ja. Würde ich mal so sagen.

kannst noch -vvv anhängen. Dann gibt es beim Brennen auch Infos.

Anschließend solltest du die Lockbits wieder setzen:


avrdude -c arduino -p atmega328 -P COMPORT  -U lock:w:0x0F:m

Ohne neu gesetztes Lockbit kann es passieren dass sich der Bootloader beim Flashen einer Firmwaredatei die zu groß ist zerschießt.


Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 03 August 2014, 17:30:27
Hi Dirk,
ich habe das jetzt mal mit einem Arduino Uno probiert. Erstmal den Programmer hochgeladen, wie hier beschrieben:
http://arduino.cc/en/Tutorial/ArduinoISP (http://arduino.cc/en/Tutorial/ArduinoISP)
Dann Pins 11,12,13 und GND verbunden. Außerdem Pin 10 vom Arduino auf Reset vom Device.
...dann

C:\Users\...\bin>avrdude -c arduino -p atmega328p -P COM15 -b 19200 -U flash:w:ATmegaBOOT_168_atmega328_pro_8MHz.hex

avrdude: stk500_program_enable(): protocol error, expect=0x14, resp=0x50
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

avrdude done.  Thank you.

oder auch diese Version:

C:\Users\...\bin>avrdude -c arduino -p atmega328p -P COM15 -b 19200 -U flash:w:ATmegaBOOT_168_atmega328_pro_8MHz.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.

avrdude done.  Thank you.


Was kann da schief gelaufen sein?
Ich höre jetzt mal auf, damit zu experimentieren, da der Uno 5V Levels hat und die Platine nur 3,3V. ...das hatte ich vergessen und ich will eigentlich nichts kaputt machen.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 03 August 2014, 23:45:59
Hi Thorsten,
vielen Dank für Deine Hilfe! Mit der Eclipse IDE und dem Arduino Plugin läufts jetzt. Komischerweise habe ich mit Deinen importierten Einstellungen weiterhin Fehler beim Build-Prozess gehabt (trotz angepassten Verzeichnissen). Irgend ein Make-File wurde nicht gefunden... Wie auch immer, wenn ich die einzelnen Dateien in ein neues Projekt übernehme, dann funktioniert alles. Also, besten Dank nochmal.

Ach ja, nochwas:
ZitatBrauche ich tatsächlich den 10uF Kondensator?
Ich würde das mal mit dem Kondensator probieren. Beim Flashvorgang aus der Arduino-IDE (und vermutlich auch über das Eclipse-Plugin) wird ein Reset auf den Arduino ausgelöst, um ihn in den Bootloader zu schicken. Das läuft darüber, dass die DTR-Leitung der seriellen Schnittstelle mit dem Hardware-Reset des Atmegas verbunden ist. Wenn du jetzt aber einen Arduino als Programmiergerät verwendest, musst Du verhindern, dass dieser Arduino den Reset ausführt, sonst landet das Programmiergerät im Bootloader. Mit dem Kondensator verhinderst Du, dass die Spannung während des Reset-Puls einbricht und der Arduino (das Programmiergerät) nicht in den Bootloader wechselt. Falls Du keinen 10µF zu Hand hast, sollten auch höhere Werte funktionieren.
siehe auch hier: http://playground.arduino.cc/Main/DisablingAutoResetOnSerialConnection (http://playground.arduino.cc/Main/DisablingAutoResetOnSerialConnection)

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 04 August 2014, 00:29:14
Zitat von: Thorsten Pferdekaemper am 03 August 2014, 17:30:27
ich habe das jetzt mal mit einem Arduino Uno probiert.
Ok, dein Hinweis mit dem Uno hatte ich vorhin überlesen. Da braucht es den Kondensator sonst reseted der 2. AVR. Ich hatte irgendwie noch in Erinnerung dass du noch einen Pro Micro hast.

Falls du einen Raspberry Pi "rumliegen" hast, den kannst du auch als ISP-Programmer benutzen:
http://www.forum-raspberrypi.de/Thread-tutorial-raspberry-als-programmiergeraet-fuer-atmel-%C2%B5controller

Dort hast du auch gleich 3,3V an den GPIO's

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 04 August 2014, 13:14:57
Zitat von: MarkusO am 03 August 2014, 23:45:59Mit der Eclipse IDE und dem Arduino Plugin läufts jetzt. Komischerweise habe ich mit Deinen importierten Einstellungen weiterhin Fehler beim Build-Prozess gehabt (trotz angepassten Verzeichnissen). Irgend ein Make-File wurde nicht gefunden...
Tja, bei Eclipse weiß ich auch nie so genau was warum funktioniert bzw. nicht funktioniert. ...aber wenn's jetzt klappt, dann ist ja gut.

ZitatAch ja, nochwas:Ich würde das mal mit dem Kondensator probieren. Beim Flashvorgang aus der Arduino-IDE (und vermutlich auch über das Eclipse-Plugin) wird ein Reset auf den Arduino ausgelöst, um ihn in den Bootloader zu schicken.
Ah, es geht dabei um den Programmier-Arduino. Gut, jetzt hab ich's kapiert.
Allerdings lass ich die Versuche jetzt lieber, da ja auch der Pegel nicht stimmt.

Zitat von: Dirk am 04 August 2014, 00:29:14Falls du einen Raspberry Pi "rumliegen" hast, den kannst du auch als ISP-Programmer benutzen:
Das werde ich vielleicht mal probieren, aber erstmal geht's wieder nach London, also nächste Woche vielleicht.
Mit was machst Du das denn?

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 04 August 2014, 13:26:35
Zitat von: Thorsten Pferdekaemper am 04 August 2014, 13:14:57
Mit was machst Du das denn?
Ich habe mir einen USBASP: http://www.fischl.de/usbasp/ gebaut.
Da der auch mit 5V vom USB-Bus versorgt wird, sind noch 2 Spannungsteiler (4 Widerstände) dabei, damit das Ganze 3,3V Kompatibel wird.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 11 August 2014, 20:48:37
Hallo zusammen,

mit meinem letzten commit habe ich nun noch einen ext. Tastereingang für den MDIR geschaffen. Dieser soll auch zum Peering mit anderen Homematic Modulen benutzt werden. Das ist meine nächste Baustelle ....

Gruß Rene
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 August 2014, 00:43:28
Hi,

ich habe auch mal wieder ein klein wenig weitergebaut. In meiner neusten Git-Version sendet das Device die Temperaturen jetzt an die Zentrale, wenn es angelernt wurde. Ansonsten weiterhin an 0xFFFFFFFF (broadcast).
Im Prinzip passiert das im Device selbst (also im Hauptprogramm), aber ich habe die Methode broadcastInfoMessage durch sendInfoMessage ersetzt (sorry Rene). Die Broadcast-Funktion bekommt man, wenn man als letzten Parameter 0xFFFFFFFF einsetzt.

Ich weiß, dass das wie ein Detail aussieht, da es der Zentrale im Prinzip egal ist. Allerdings bekommt man mit Broadcast-Messages kein fehlertolerantes Protokoll hin, da es kein ACK gibt.

Außerdem noch eine kleine Änderung: Beim Reset konnte es passieren, dass das Teil nach der Announce-Message eine Weile (1 Sekunde oder so) nicht reagiert hat. Dadurch konnte das Anlernen schief gehen. Das sollte jetzt nicht mehr der Fall sein.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 14 August 2014, 21:05:43
Hallo Thorsten,

das kleine syntaktische Detail sollte für mich nicht so schwierig zu lösen sein :-). Was das aus Protokollsicht bedeutet, kann ich für mich (noch) nicht abschätzen. Bisher war ich einfach nur Anwender.

Gruß Rene
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 15 August 2014, 21:18:11
Hallo Rene,
der Punkt ist, dass man per Broadcast keine sichere Kommunikation hinbekommt. Das Protokoll hat im Prinzip zwei Mechanismen um die Kommunikation zuverlässig zu machen. (Verkürzt dargestellt...)
Das ACK ist natürlich nur dann sinnvoll, wenn es einen bestimmten Empfänger gibt. Beim Broadcast müssten sonst alle ein ACK schicken. ...aber nichtmal das würde was bringen, da ein Gerät normalerweise nicht weiß, wie viele Geräte vorhanden sind. Es gibt also beim Broadcast kein ACK. Deshalb weiß das Gerät nicht, ob seine Nachricht angekommen ist und kann daher auch keine Wiederholung schicken.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 16 August 2014, 21:09:22
Hallo Thorsten,

das heißt für mich im Klartext ich muss erstmal die Config-informationen im EEPROM haben. Also das Peering mit Zentrale oder anderen HM-Devices und dafür muss ich die Gerätebeschreibungsdatei (xml-File) vervollständigen. Wenn nichts (also 0xffff) im EEPROM steht wird ein Broadcast gesendet.

Ist das so korrekt ?

Gruß Rene
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 16 August 2014, 23:25:15
Hi,
Du musst das nicht machen. Das ganze passiert eh im Hauptprogramm. Wenn Du das benutzen willst, dann musst Du das machen, ansonsten nicht.
Theoretisch könnten wir uns aber auch darauf einigen, dass bei "unseren" Geräten die Adresse der Zentrale immer an Speicherplatz 0x0002 im EEPROM beginnt. Dann könnte ich auch sowas wie "sendInfoMsgToCentral" bauen, das das alles automatisch erledigt.
(Es handelt sich dabei um das Pairing an die Zentrale. Peering an andere Devices ist komplizierter.)
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 17 August 2014, 18:30:28
Hallo nochmal,
ich bin gerade dabei, ein paar "strukturelle" Änderungen vorzunehmen. Falls also jemand das Coding, was er momentan verwendet, auf die neue Version anpassen will, dann bitte noch ein bisschen damit warten. Es wird wahrscheinlich bald noch eine neue Version geben, die ein paar größere Änderungen erfordert.
Das ist notwendig, um die Kommunikation sicherer zu gestalten. Dazu muss das Modul selbst (also im Wesentlichen die Kommunikationsschicht) das Timing im Griff haben. So ziemlich alles, was Device-spezifisch ist (Sensoren auslesen, Tastendrücke verarbeiten, Schalter schalten...) soll dann über Callbacks (C++-Interfaces) erledigt werden. 
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 18 August 2014, 10:58:41
Hi,
die neuste Git-Version:

Zu meiner Begrifflichkeit:

Für Verwender des ganzen (@Rene...): Es gibt jetzt eine neue Methode HMWRS485->loop(). Das ist jetzt die einzige Methode, die das Device in "seiner" loop() zyklisch und möglichst oft aufrufen muss. Aus dem hier:

if(hmwrs485.frameComplete) {
      if(hmwrs485.targetAddress == hmwrs485.txSenderAddress || hmwrs485.targetAddress == 0xFFFFFFFF){
        hmwrs485.parseFrame();
        hmwmodule->processEvents();
      }
   };

...wird also das hier:

hmwrs485.loop();

Wie das Modul mit der Kommunikationsschicht zusammenhängt klären die beiden jetzt unter sich.

Falls jemand in den nächsten zwei Tagen einen schwer wiegenden Fehler findet, dann kann ich den ggf. noch schnell reparieren. Ansonsten geht's erst Mitte/Ende September weiter. Ich fliege nach Hawaii...  :D  (SCNR)
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 18 August 2014, 20:34:54
Hallo Thorsten,

der Umbau sieht erstmal super aus. Ich werde Ihn bei mir mal integrieren.

ZitatDas ist jetzt die einzige Methode, die das Device in "seiner" loop() zyklisch und möglichst oft aufrufen muss

Möglichst oft aufrufen finde ich nicht ganz so hübsch. Da ich in meinem Device ohnehin einen 10 ms Takt über MSTimer erzeuge, hatte ich schon überlegt das Device zwischen den Timerevents in den Stromsparmodus zu schicken (Ob es funktionieren würde, muss ich probieren). Ist es aus Protokollsicht (mit Hardwareserial) unbedingt erforderlich so schnell wie möglich zu arbeiten?

Gruß Rene
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 18 August 2014, 22:14:57
Zitat von: reneFHEM am 18 August 2014, 20:34:54Möglichst oft aufrufen finde ich nicht ganz so hübsch. Da ich in meinem Device ohnehin einen 10 ms Takt über MSTimer erzeuge, hatte ich schon überlegt das Device zwischen den Timerevents in den Stromsparmodus zu schicken (Ob es funktionieren würde, muss ich probieren). Ist es aus Protokollsicht (mit Hardwareserial) unbedingt erforderlich so schnell wie möglich zu arbeiten?
Hi,

ich weiß nicht, ob das mit dem Stromsparmodus bei kabelgebundenen Sachen so der Hit ist. Wacht das Ding dann automatisch auf, wenn was über den Bus kommt? Funktioniert der Interrupt für die serielle Schnittstelle dann noch? Beim Funkprotokoll gibt es sozusagen ein festgelegtes Timing, aber nicht beim Kabel.
Ansonsten dürfte es kein Problem sein, zwischendurch 10ms zu schlafen. Es ist nur wichtig, dass loop() oft genug aufgerufen wird, dass der Empfangspuffer abgearbeitet werden kann. 

Was genau musst Du denn alle 10ms machen? Das könnte nämlich sowieso problematisch werden, da ich das ganze wahrscheinlich so umbauen will, dass die Library die Kontrolle über das Timing bekommt. Dann gibt es für das Device nur noch Callbacks. Der Grund dafür ist, dass das Protokoll auch bestimmte Vorgaben für das Timing hat.
Auf keinen Fall darfst Du in der Interrupt-Routine für den Timer irgendwas aufrufen, was Nachrichten über RS485 rausschickt. Das kann nämlich deutlich länger als 10ms dauern.

...aber sag' mal, was Du da genau machst, dann schaue ich mir's nochmal an.

Gruß,
  Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 19 August 2014, 20:58:35
Hallo Thorsten,

ich erzeuge mir mit dem ms-Timer einen Rechteckttakt mir 50 Hz. Diesen benötigt der IR-Sensor um die Pins (Licht Ein/Aus Motion Detection) entsprechend zu schalten. Dies geschieht in der Timer-ISR und liest auch nur paar GPIO's ein und setzt ein Statusbit. Das Versenden der Events wird dann aus der Mainloop gesteuert. Diese kann halt durch den Timer unterbrochen werden. Funktioniert bisher ohne Probleme, allerdings mit einem Rechtecktakt von 1 Hz (Ich erzeuge mit Tastern die Sensor-Impulse). 

Ob es tatsächlich funktioniert den uC schlafen zu legen und ob eine Einsparung an Strom daraus resultiert kann ich (noch) nicht sagen. In den BASCOM-Quellen von denen ich die Logik übernommen habe, wurde es mit dem Watchdog realisiert das der uC wieder aufwacht. 

Deine Neuerungen habe ich gestern bei mir integriert und sie funktionieren.

Gruß Rene
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 August 2014, 22:11:40
Zitat von: reneFHEM am 19 August 2014, 20:58:35ich erzeuge mir mit dem ms-Timer einen Rechteckttakt mir 50 Hz. Diesen benötigt der IR-Sensor um die Pins (Licht Ein/Aus Motion Detection) entsprechend zu schalten. Dies geschieht in der Timer-ISR und liest auch nur paar GPIO's ein und setzt ein Statusbit. Das Versenden der Events wird dann aus der Mainloop gesteuert.
Hi,
das sollte kein Problem sein. Wie gesagt, die serielle Schnittstelle muss halt noch die Chance haben, dazwischen zu kommen und hmwrs485.loop(); muss halt oft genug aufgerufen werden, um den Puffer der seriellen Schnittstelle abzuarbeiten.
Nettes Device, ich glaube, dass baue ich dann auch mal nach. ...aber wohl erst im Oktober oder so.
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 20 August 2014, 00:51:11
Zitat von: Thorsten Pferdekaemper am 19 August 2014, 22:11:40
Wie gesagt, die serielle Schnittstelle muss halt noch die Chance haben, dazwischen zu kommen und hmwrs485.loop(); muss halt oft genug aufgerufen werden, um den Puffer der seriellen Schnittstelle abzuarbeiten.
In den ISRs sollte halt möglichst wenig passieren. Am besten nur Register lesen/sichern und vielleicht ein paar Flags setzen.
Das Auswerten der Daten sollte dann im Main-Loop passieren. Dann solltes es recht unwahrscheinlich sein, dass sich die Interrupts blockieren.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Mr. P am 28 August 2014, 22:33:13
Hej folks,

nachdem Anfang der Woche meine 03er-Sensoren von Dirk eingetroffen sind und alle brav ihren Dienst verrichten, wollte ich an einen von diesen jetzt meine geplante 1-Wire Erweiterung anhängen.
Hilf- und planlos hab ich mir jetzt einen der Sensoren angesehen, ein wenig im Git und hier im Forum rumgesucht, aber so ganz schlüssig, wie ich es gerne wäre, bin ich leider noch nicht. :-/
Was will ich machen: An den einen Sensor würde ich gerne eine Klinkenbuchse anlöten, um daran die entsprechenden Sensoren anzuschließen.
Meine ersten beiden Fragen lauten daher:
1) Wo muss ich die drei nötigen Pins anlöten und
2) Welche Firmware muss ich nutzen (diese hier? (https://github.com/kc-GitHub/HM485-Lib/tree/thorsten/HBW-1W-T10)) um sowohl die bereits vorhandenen als auch 1-wire nutzen zu können?

Vielen Dank für die Infos! :-)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 28 August 2014, 23:10:09
Im Prinzip brauchst du nur noch die 1-Wire-Lib
Das Handling der 1-Wire Sensoren muss man noch bauen. Weil da jeder Sensor ja eine eigene ID hat. Die muss man dann intern auf verschiedene Kanäle mappen.

ZitatWo muss ich die drei nötigen Pins anlöten und
Den Pin kann man sich bei der Initialisierung der Lib aussuchen. Ist ja nur einer. In der Beispiel-Firmware ist das A3 (PC3 vom Atmega328).
Zusätzlich kommt dann noch GND und VCC an den Sensor.
Schau mal im Wiki, da ist auch der Schaltplan und der Bestückungsplan vom Sensor.

ZitatWelche Firmware muss ich nutzen (diese hier?) um sowohl die bereits vorhandenen als auch 1-wire nutzen zu können?
Ja. Das ist die Firmware für HM-Wired.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 30 August 2014, 00:18:57
Hallo,
ich hab in den letzten Tagen Thorstens 1-Wire-Client nachgebaut. Scheint soweit auch zu laufen, das Modul sendet die Daten korrekt auf dem Bus. Allerdings habe ich Probleme, das Modul im FHEM anzulegen. Ich verwende FHEM auf einem RPi zusammen mit einem einfachen USB-RS485-Wandler, d.h. ich kann nicht direkt das xml-File aus dem Github verwenden, sondern muss daraus erst ein pm-File erstellen. Zum Konvertieren habe ich Dirks xmlHelper.pl verwendet. Das pm-File sieht allerdings fehlerhaft aus (z.B. werden nicht alle " durch ' ersetzt), so als wäre das Skript nicht komplett durchgelaufen. Jetzt weiß ich nicht, ob der Fehler beim Skript oder im xml-File liegt.

Hat jemand schon mal das 1-Wire-Device über das pm-File in FHEM eingebunden und könnte die Datei zur Verfügung stellen? Oder hat jemand einen Tipp zur Fehlersuche - meine Perl-Kenntnisse gehen leider gegen null... Die konvertierte Datei ist angehangen.

Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 30 August 2014, 16:01:20
Hallo Markus,
Zitat von: MarkusO am 30 August 2014, 00:18:57
Allerdings habe ich Probleme, das Modul im FHEM anzulegen.
Dafür gibts bei HM-Wired noch keine Unterstützung für FHEM. Da müsstest du aktuell selber die Module Patchen.
Am besten du benutzt dafür die Module aus der DEV-Branch.
Hier kann ich die auch ein entsprechendes Device-PM für den Sensor schicken. Das sollte man dann etwas einfacher zum laufen bekommen.

ZitatZum Konvertieren habe ich Dirks xmlHelper.pl verwendet. Das pm-File sieht allerdings fehlerhaft aus (z.B. werden nicht alle " durch ' ersetzt), so als wäre das Skript nicht komplett durchgelaufen. Jetzt weiß ich nicht, ob der Fehler beim Skript oder im xml-File liegt.
Ah, ok, das benutz du schon. Ich kann mir das heute Abend mal anschauen.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 01 September 2014, 23:51:08
Hi Dirk,
wär großartig, wenn du mir dazu ein pm-File zuschicken könntest. Vielen Dank vorab.

Weil ich mit dem Temperatursensor nicht so richtig weiter komme, habe ich angefangen, das HMW-LC-Bl1 nachzubauen. Leider habe ich kein Original-Modul und kann das Verhalten deshalb nicht testen. Vielleicht kann jemand, der ein Original-Modul hat, die folgenden Fragen beantworten:

1. In Dirks Protokollbeschreibung habe ich folgendes für die Rollo-Aktoren gefunden (gelb hinterlegt, also noch nicht verifiziert): Runter - 0x20, Hoch - 0x10, Aus - 0xFE, Auf Schlitz fahren - 0xFF.
Die FHEM-Zentrale verschickt jedoch die folgenden Werte: 0x00 bis 0xC8 - Sollposition.
Hat jemand Erfahrung mit dem Gerät und kann irgend etwas davon bestätigen? Besonders würde mich interessieren, ob es tatsächlich einen Befehl für "auf Schlitz fahren", Togge und Stop gibt.

2. Wenn eine Taste lang gedrückt und dann losgelassen wird, kommt dann ein bestimmtes Event, dass sich von den "Wiederholungs-Events" unterscheidet? Konkret wäre das hilfreich, wenn man bei lang gedrückter Taste das Rollo nur so lange verfährt, bis die Taste wieder losgelassen wird. Mir ist klar, dass das im Device intern gelöst werden könnte, aber schicker wäre es, wenn das HMW-Protokoll so etwas schon vorsieht und ich nicht vom Standard abweichen müsste.

Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 21 September 2014, 14:20:32
Zitat von: MarkusO am 01 September 2014, 23:51:08
2. Wenn eine Taste lang gedrückt und dann losgelassen wird, kommt dann ein bestimmtes Event, dass sich von den "Wiederholungs-Events" unterscheidet? Konkret wäre das hilfreich, wenn man bei lang gedrückter Taste das Rollo nur so lange verfährt, bis die Taste wieder losgelassen wird. Mir ist klar, dass das im Device intern gelöst werden könnte, aber schicker wäre es, wenn das HMW-Protokoll so etwas schon vorsieht und ich nicht vom Standard abweichen müsste.
Hi,
soweit ich das sehe (und gerade bei meinem Original-HMW-LC-Sw2-DR ausprobiert habe) kommt beim Loslassen nach einem langen Tastendruck nicht nochmal ein Extra-Event. Nach der Zeit, die für einen langen Tastendruck eingestellt ist, kommt der erste "4B-lang", der dann alle etwa 300ms wiederholt wird. Beim Loslassen kommt nichts mehr.
Im Prinzip muss man das wahrscheinlich so machen: Fahre bei einem "4B-lang" immer 300ms weiter (oder vielleicht ein bisschen mehr um Ruckler zu vermeiden). Wenn danach keine Wiederholung kommt, dann aufhören.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 21 September 2014, 14:33:52
Hi,
ich habe gerade mal wieder angefangen, mich mit der Kollisionsvermeidung zu befassen. Ich bin bisher davon ausgegangen, dass die Wired-Devices immer "mitlauschen" und nur dann eine Kommunikation initiieren, wenn auf dem Bus seit mindestens 200ms (+Zufallsanteil) Ruhe herrscht.
Jetzt habe ich mir zum Test ein Device gebaut, welches auf Knopfdruck den Bus belegt. Damit habe ich fest gestellt, dass ein Original HMW-LC-Sw2-DR nur so ungefähr 10 bis 20 auf "Bus frei" wartet (wenn überhaupt, das ist schwer definitiv festzustellen). Erst wenn ich die Pausen zwischen den Messages auf etwa 5ms herabsetze hält das Teil die Klappe.
Ich konnte allerdings nie feststellen, dass es zwischen einer Message an die Zentrale und das zugehörige ACK gefunkt hat.
Hat vielleicht sonst noch jemand ähnliche Versuche gemacht und kann dazu was sagen?
Dirk?
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 22 September 2014, 22:04:48
Hi,
danke für die Info zu den langen Tastendrücken. Ich werd das jetzt erstmal weglassen und nur auf normale Tastendrücke reagieren. Eine erste Version vom HMW-LC-Bl1-DR (Rollo-Steuerung) habe ich eben online gestellt.
Zur Kollisionsvermeidung kann ich leider nichts beitragen - hab noch immer kein Original-Device...

Grüße,
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 10 Oktober 2014, 22:29:24
Hallo,
hab gerade eine erste Version von einem 4-fach Rolladenaktors online gestellt: https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Bl4
Weitere Infos dazu stehen in der Readme. Falls das jemand gebrauchen kann, freue ich mich über Feedback.

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 11 Oktober 2014, 15:22:11
Hi Markus,

Sehr cool. Das werde ich mir die Tage auf alle Fälle ansehen.
Und die Arbeit an dem HM485-Module wird die Tage auch wieder weiter gehen.
Ziel ist es dass für HB-Devices dann der Code auch nicht mehr geändert werden muss.
Es muss dann nur ein XML-File erstellt werden.

Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 11 Oktober 2014, 19:39:13
Hallo Dirk, kann man auch die Raffstore Steuerung von Markus für das HMW-LC-BL1-DR Modul übernehmen? Oder dort sowas implementieren?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 11 Oktober 2014, 23:13:49
Hallo Holzwurm,
falls Du auf der Suche nach einem HMW-LC-Bl1-DR auf Arduino-Basis bist: das Modul hatte ich auch schon mal implementiert:
https://github.com/kc-GitHub/HM485-Lib/tree/markus/HMW-LC-Bl1-DR (ftp://github.com/kc-GitHub/HM485-Lib/tree/markus/HMW-LC-Bl1-DR)
Dafür werden dann auch keine extra pm-Files benötigt, da FHEM ein "Original-Device" erkennt.

Für Thorstens 1-wire Temperatursensor habe ich jetzt übrigens ein passendes pm-File gebaut, mit dem das Modul in FHEM erkannt wird (das Skript zur Umwandlung von xml in pm lief bei mir leider nicht):
https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-1W-T10

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 11 Oktober 2014, 23:43:45
Hallo Dirk,

irgendwas scheint mit dem ersten Link nicht zu stimmen?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 11 Oktober 2014, 23:46:41
Welchen Link meinst du?

Oder meinst du diesen:
https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Bl4

Der ist von Marcus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 12 Oktober 2014, 00:41:08
Tut mir leid Dirk! Ich hatte es überlesen und dachte, dass der letzte Beitrag von Markus von dir wäre.

@Markus: Das kommt für mich leider zu spät  :(. Ich habe bereits alle Module im Original.
Aktuell lassen ich die Raffstore mit einem HMW-LC-Bl1-DR außer rauf und runter nicht wirklich steuern und daher wollte ich wissen ob Dirk deine Steuerung (Lamellenstellung,....) einbauen kann?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 20 Januar 2015, 22:17:19
Hallo zusammen,

ich habe mich in letzter Zeit mal wieder mit den Homebrew-Devices beschäftigt und ein paar neue Module zusammen gebaut.

HBW-LC-Sw8: 8fach Relaismodul. Damit können mit einem Arduino und einem einfachen Relaismodul für ca. 6€ acht 230V Kanäle geschaltet werden https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Sw8 (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Sw8)

HBW-Sen-SC8: 8fach Tastermodul. Ließt acht Eingänge ein. Neben den langen und kurzen Tastendrücke werden auch Doppelklicks erkannt und ein Event geschickt, wenn ein langer Tastendruck wieder losgelassen wird. Hilfreich, wenn z.B. ein Rollo nur so lange fahren soll, wie eine Taste gedrückt ist. https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-SC8 (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-SC8)

HBW-Sen-KEY: Ließt mit einem RFID-Modul Transponder aus und schickt die ID an die Zentrale. Könnte man z.B. für die Türöffnung verwenden (wenn man der Sicherheit der RFID-Karten vertraut) https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-KEY (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-KEY)

HBW-Sen-EP: Wertet die S0-Schnittstelle aus, wie sie z.B. von Strom-, Gas-, Wasserzählern verwendet wird. Die gezählten Impulse werden an die Zentrale geschickt. https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-EP (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-EP)


Was mir jetzt noch fehlt ist ein 230V Mehrfachdimmer (Phasenanschnittsteuerung). Hierfür gibt es im Netz auch einige ganz gute Vorlagen, z.B. hier: http://www.instructables.com/id/Arduino-controlled-light-dimmer-The-circuit/?lang=de (http://www.instructables.com/id/Arduino-controlled-light-dimmer-The-circuit/?lang=de)
Allerdings würde ich mir gerne den Aufwand sparen, den Dimmer selbst zu entwerfen und würde lieber einen vorhandenen Dimmer über den Arduino an den HM485-Bus anbinden.

Kennst jemand günstige Dimmermodule, die z.B. über DMX oder andere kabelgebundene Protokolle gesteuert werden können?


Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: reneFHEM am 21 Januar 2015, 20:53:09
Hallo zusammen,

für DMX hätte ich eine Link mit Bauanleitung für Dich. http://www.hoelscher-hi.de/hendrik/light/dmxdimmer.htm (http://www.hoelscher-hi.de/hendrik/light/dmxdimmer.htm)

Gruß Rene
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 22 Januar 2015, 21:25:07
Hallo Rene,

danke für die Info, die Anleitung sieht ganz gut aus, werde ich mir nochmal genauer anschauen.
Eigentlich suche ich aber noch etwas anderes. Ich würde gerne den Aufwand sparen, den Dimmer selbst zu bauen, sondern suche ein fertiges (günstiges) Dimmer-Modul (egal für welches Protokoll), dass man über ein Arduino-Homebrew-Device nur noch an den HM485-Bus anschließen muss.
So in etwa wie bei den Relais-Boards, die auch schon fertig aufgebaut sind und über das Arduino-Modul nur noch an den Bus angeschlossen werden.

Mal schauen, ob ich irgendwo noch was passendes finde. Falls nicht, baue ich so ein Dimmerpack vielleicht doch selbst.

VG
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: hglaser am 25 Januar 2015, 23:53:00
Hallo liebe Heimbrauer

Ich habe mal so ein HBW Teil auf einem breadbord zusammengfrickelt und es funktioniert :-). Nun habe ich beobachtet, daß
bei einem Tastendruck auf meinem originalen io12sw7, das Modul zuerst ein "K" schickt und ca 20ms darauf ein "A".
2015.01.25 17:48:01.474 3: HM485d: Rx:  I[3](3,Y,F,B)(FE) 00009624 -> FFFFFFFF [6] 4B(K) 01002E {F24C}
2015.01.25 17:48:01.496 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 00009624 -> FFFFFFFF [18] 41(A) 01120003064A455130343937373233 {241C}

Nun habe ich einmal auf dem Nachbau eine Taste gedrückt, aber dieses schickt wohl nur ein "K". Danach fragt die Zentrale den Sensorzustand mit einem "S" ab.
2015.01.25 17:57:20.374 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 0000CA35 -> FFFFFFFF [6] 4B(K) 010022 {78C4}
2015.01.25 17:57:22.430 3: HM485d: Tx: (243:1) I[3](0,F,B)(1E) 00000001 -> 0000CA35 [4] 53(S) 02 {BDC8}
2015.01.25 17:57:22.452 3: HM485d: Rx: Response: (243) I[0](3,F,B)(78) 0000CA35 -> 00000001 [6] 69(i) 020000 {B0D8}
2015.01.25 17:57:22.461 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 0000CA35 [2] {1376}

Nun habe ich in der Protokoll-Doku gesucht und finde, daß ein "A" geschickt wird  wenn ein Modul noch nicht an die Zentrale angelernt wurde. Stimmt denn das ?. Mein io12sw7 ist ja eigentlich an die Zentrale angelernt. Ist daß bei euch auch so, oder ist es nur in der Doku falsch beschrieben? Wenn ja könnte man so eine "A" Nachricht ja eigentlich auch in die HBW Devices einbauen.

Edit: vergesst es. Im HMWHomebrew ist es bereits so. Nur im HMW_LC_Bl1_DR war es auskommentiert, ich weiss jetzt nicht wieso aber wird wohl einen Grund haben.
Ich habe bei dieser Gelegenheit diesen HMWHomebrew an die neue Version angepasst, damit er sich kompilieren lässt und auf HMW_LC_Sw2_DR umgetauft, falls es jemand braucht, Dateien anbei.

lg Harald
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: hglaser am 05 März 2015, 20:41:24
Hallo

Ich habe mir einmal die schönen Sachen von Markus angesehen und darauf aufbauend auch einmal etwas gebastelt.

Eine einfache Ventilsteuerung für meine Thermischen 24V Ventile. Ich habe
es mittels eines TIP 220 angesteuert, es geht natürlich auch über ein Relaismodul
oder ähnliches. Verwendet wird zur Umrechnung der Ventilstellung die von FHEM gesendet wird, "time proportioning control" eine Art extrem langsames PWM. Der Grund dafür war eigentlich, daß meine Stellventile (HM-CC-VT) immer wieder einmal diesen 3% bug haben und ich die Dinger los werden wollte.

lg Harald.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Artur74 am 10 März 2015, 08:29:21
Hallo,

Ich bin auch gerade dabei mir meine eigenen Module zu basteln. Basierend auf den Codes von Markus, Dirk und Thoraten habe ich mir auf dem Bredboard ein kleines System von Arduions mit unterschiedlichen Modulen zusammengesteckt. Das One-Wire Modul mit den 10 Temperatursensoren funktioniert super mit meiner CCU2.

Ich verstehe allerdings nicht ganz was es mit den XML-Dateien auf sich hat. Eigentlich müsste doch für jedes von euch entwickeltes Modul eine neue XML-Datei auf die CCU kopiert werden? Ist das Konzept mit FHEM anders?
Kann mir jemand grob erklären wie ich die XML-Datei für die CCU2 aufbauen muss?

Ich habe mir mal die XML-Dateien aus der CCU2 ausgelesen und etwas aufbereitet. So wie ich es verstehe wird dort festgelegt an welchen Stellen im Modul EEPROM die einzelnen Konfigurationsparameter abgelegt werden. Wie muss es aber aussehen wenn ich 10 normale Tastereingänge (SHORT- und LONG-Press und 8 Schaltausgänge (ohne das gedöne das ein Direkter Link zwischen den Modulen notwendig ist) haben möchte?

Über eine Antwort würde ich mich sehr freuen.

Viele Grüße,

Artur
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 15 März 2015, 23:22:18
Hallo zusammen,

Harald, Dein Modul sieht Heizungssteuerung sieht ganz interessant aus, ich überlege auch gerade, wie ich meine Heizung am besten regeln kann. Wenn Du damit eine ganz langsame PWM steuerst, gehe ich davon aus, dass damit eine Fußbodenheizung geregelt wird, bei der die Ventile immer komplett auf oder zu sind, oder? Womit bestimmst Du die Pulsweite, also den Sollwert? Kommt der aus einer PID-Temperaturregelung? Vielleicht kannst Du ja mal ein Beispiel aus Deiner Konfig schicken. Ich wäre auch daran interessiert, wie gut die Temperaturregelung damit funktioniert. Hast Du zufällig einen Plot mit Soll- und Isttemperatur und ein paar Regelparametern?
Bisher hatte ich geplant die Fußbodenheizung über das Modul Threshold mit einer Zweipunktregelung zu betreiben, aber ich könnte mir vorstellen, dass es mit so einer PWM-Steuerung eine geringere Regelabweichung gibt.

@Artur: Wenn Du das direkte Peering nicht benötigst, wird das EEPROM-Layout recht einfach. Da stehen dann nur noch ein paar Infos wie die ID etc. drin. So wie ich das verstanden habe, werden die XML-Dateien benötigt, wenn Du eine richtigen Homematic-Zentrale hast. Wenn die Module mit FHEM betrieben werden, brauchst Du ein pm-File. Bei den pm-Files für meine Homebrew-Geräte habe ich immer irgend ein anderes pm-File als Vorlage genommen und darin einfach die Anzahl der Eingänge geändert und nicht benötigte Sachen rausgelöscht. Irgendwie ist dann am Ende was funktionierendes rausgekommen. Das wäre der einzige Tipp, den ich dir bei den XMLs geben kann: einfach ein anderes Modul mit Tastereingängen als Vorlage nehmen und modifizieren.

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: hglaser am 16 März 2015, 05:01:51
Hallo Markus

Nun ich steuere derzeit probehalber nur einen Raum damit. Jedoch ist es eine ganz normale Heizkörperheizung. Die Werte für die Steuerung bekomme ich von einem HM_CC_TC, der mit einem Virtuellen VD gepeert ist, damit er Werte ausgibt. den HM_CC_TC überwache ich per notify auf Änderung und setze den entsprechenden Wert. Ich denke das ganze geht auch mit einem Software-PID, hab ich aber nicht ausprobiert. Ich hab das Teil eigentlich nur zusammengebaut weil ich schon öfters Probleme mit meinem HM-CC-VD hatte, der nicht richtig schloss. Das ganze funktioniert und ich werde jetzt mitloggen. Werde ich dann in ein paar Tagen posten. Schön wäre natürlich einen 1-wire Temp-sensor und einen PID ins Modul einzubauen. Libraries dafür gäbs ja schon. Aber dafür hab ich zuwenig Zeit. Hier die Auszüge aus der cfg:

#ein ganz normaler TC gepeert mit vcc
define CUL_HM_HM_CC_TC_1D2BAB_Climate CUL_HM 1D2BAB02
attr CUL_HM_HM_CC_TC_1D2BAB_Climate event-on-change-reading .*
attr CUL_HM_HM_CC_TC_1D2BAB_Climate fp_wohnung 430,305,2, ,
attr CUL_HM_HM_CC_TC_1D2BAB_Climate model HM-CC-TC
attr CUL_HM_HM_CC_TC_1D2BAB_Climate peerIDs 00000000,22113301,
attr CUL_HM_HM_CC_TC_1D2BAB_Climate room hidden

#der vcc, brauch ich nur damit der HM_CC_TC was zu stellen hat, sonst kommen keine Ventilstellwerte
define vvd1 CUL_HM 22113301
attr vvd1 model HM-CC-VD
attr vvd1 peerIDs 1D2BAB02,
attr vvd1 room Büro
attr vvd1 stateFormat ValvePosition
attr vvd1 subType thermostat
attr vvd1 webCmd getConfig:clear msgEvents

#notify zum Verstellen des wired Aktor
define setze_Ventil notify CUL_HM_HM_CC_TC_1D2BAB.actuator:.* set HMW_CC_Vd2_T_HBW4073471_01 LEVEL $EVTPART1
attr setze_Ventil room Heizung

#Der wired VD
define HMW_CC_Vd2_T_HBW4073471 HM485 42FFFFFF
attr HMW_CC_Vd2_T_HBW4073471 firmwareVersion 3.06
attr HMW_CC_Vd2_T_HBW4073471 model HMW_CC_Vd2_T
attr HMW_CC_Vd2_T_HBW4073471 room HM485
attr HMW_CC_Vd2_T_HBW4073471 serialNr HBW4073471
define HMW_CC_Vd2_T_HBW4073471_01 HM485 42FFFFFF_01
attr HMW_CC_Vd2_T_HBW4073471_01 alias Ventil Buero
attr HMW_CC_Vd2_T_HBW4073471_01 firmwareVersion 3.06
attr HMW_CC_Vd2_T_HBW4073471_01 model HMW_CC_Vd2_T
attr HMW_CC_Vd2_T_HBW4073471_01 room HM485
attr HMW_CC_Vd2_T_HBW4073471_01 serialNr HBW4073471
attr HMW_CC_Vd2_T_HBW4073471_01 subType BLIND
attr HMW_CC_Vd2_T_HBW4073471_01 webCmd LEVEL
define HMW_CC_Vd2_T_HBW4073471_02 HM485 42FFFFFF_02
attr HMW_CC_Vd2_T_HBW4073471_02 firmwareVersion 3.06
attr HMW_CC_Vd2_T_HBW4073471_02 model HMW_CC_Vd2_T
attr HMW_CC_Vd2_T_HBW4073471_02 room HM485
attr HMW_CC_Vd2_T_HBW4073471_02 serialNr HBW4073471
attr HMW_CC_Vd2_T_HBW4073471_02 subType BLIND


Grüße Harald
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 18 März 2015, 00:30:53
Hallo Harald und alle zusammen!

Bei meinen Experimenten mit HomeBrew zur Darstellung von HomeMatic Wired-Komponenten auf Arduino bin ich hier auf den Beitrag von Harald gestoßen... Vielen Dank zunächst einmal an Dich für die Arbeit am HMW_LC_Sw1_DR-Modul welches bislang ja wohl noch nicht erfolgreich lief, soweit ich das bisher wußte. Nun hatte ich zuvor auf meinem Arduino das HMW-LC-Bl1-DR-Sketch als Rolladenaktor erfolgreich laufen bzw. erfolgreich an die LXCCU angelernt. Hier nun auch gleich ein kurze Zwischenfrage: Die Tasteninputs werden über die CCU an die Ausgänge gebunden? Ist das richtig? Würde das Modul ansonsten auch autark funktionieren, also ohne CCU, sowie das Original-Modul (nach dem Anlernprozess an die CCU und der Tasten)?

Natürlich wollte ich weiter testen und habe nun den Schaltaktor HMW_LC_Sw1_DR in den Arduino geladen. Nun folgende Beobachtungen:
Es wird nicht ein neuer Aktor in der CCU erkannt wenn man Geräte suchen in der CCU aktiviert. Warum nicht? Es sollte doch nun der HMW_LC_Sw1_DR erkannt werden?
Daraufhin habe ich nun gedacht es ist vielleicht im EPROM noch der Rest vom HMW-LC-Bl1-DR drin? Habe in den Sketch wieder die handleButton()-Funktion eingefügt um einen factoryReset des Aktors machen zu können... Funktion wird ausgeführt, aber leider ist ja noch die factoryReset()-Funktion auskommentiert bzw. nicht aktiv, dachte aber daß hmwmodule->setNewId(); vielleicht Abhilfe schafft. Erstaunlicherweise funktionieren die bereits zuvor angelernten Tasten des HMW-LC-Bl1-DR-Sketches weiterhin und führen ein zugeordnetes Programm aus. Also mit anderen Worten: nachdem ich zuvor den Arduino für HMW-LC-Bl1-DR genutzt habe und nun aber als HMW_LC_Sw1_DR nutzen wollte wird er in der CCU immer noch als HMW-LC-Bl1-DR geführt und verwaltet...?? Was mache ich falsch? Wie kann ich das ändern und dafür sorgen daß der Arduino nun als HMW_LC_Sw1_DR arbeitet??

Eine weitere Frage habe ich noch:
Gibt es bereits Neuigkeiten bezgl. des HMW-IO-12-FM Modules? Gibt es auch da eine bereits funktionierende Version? In der Lib von Markus läuft das noch nicht... (https://github.com/kc-GitHub/HM485-Lib/tree/markus)
Das wäre super wenn es auch ein funktionierendes IO-Modul gäbe...

Generell an alle Mitwirkenden für die tollen Sketches und die bisher geleistete Arbeit ein riesen Dankeschön und Respekt für das geleistete!!!!
Gerne möchte ich mich an diesen Projekten soweit ich es kann beteiligen und unterstützen. Ich arbeite mich gerade noch etwas ein...

Besten Dank schon einmal im Voraus für Eure Hilfe!
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: hglaser am 18 März 2015, 10:32:46
Hallo Björn

ZitatVielen Dank zunächst einmal an Dich für die Arbeit am HMW_LC_Sw1_DR-Modul welches bislang ja wohl noch nicht erfolgreich lief
Vielen Dank, aber ich habs blos auf die neuere Version umgeschrieben. Es ging nur mit der alten Version und Thorsten hat es einfach noch nicht umgeschrieben. Leider bin ich auch nicht so der Profi und muß mich in die Materie auch noch einarbeiten (C++ lernen dauert).
ZitatEs wird nicht ein neuer Aktor in der CCU erkannt wenn man Geräte suchen in der CCU aktiviert. Warum nicht?
Das wird im Modul leider noch nicht richtig unterstützt. Die Module schicken nur beim Einschalten eine "Announce" Message an die Broadcast Adresse und FHEM legt dadurch automatisch ein neues Device an. Wie das über die CCU funktioniert weiss ich leider nicht. Ich denke das wird erst richt funktionieren, wenn der "discovery mode" implementiert ist.
Zitatnachdem ich zuvor den Arduino für HMW-LC-Bl1-DR genutzt habe und nun aber als HMW_LC_Sw1_DR nutzen wollte wird er in der CCU immer noch als HMW-LC-Bl1-DR geführt und verwaltet...??
Hier könntest Du versuchen die Adresse Deines HMW_LC_Sw1_DR ins Eeprom zu schreiben. Wie das geht ist msg187477 (http://forum.fhem.de/index.php/topic,22952.msg187477.html#msg187477) hier beschrieben. Dazu müsstest Du aber in FHEM einsteigen, was ich sehr empfehlen kann. Meine CCU liegt seit einem Jahr im Kasten. :-). In der CCU müsste man "HMW-LC-Bl1-DR" wohl vorher irgendwie komplett löschen.
Bezüglich HMW-IO-12-FM kann ich leider auch nicht helfen, da ich derzeit sehr wenig Zeit habe und ich mich damit auch noch nicht beschäftigen konnte. Bestimmt wird sich der Sache Thorsten oder ein anderer Entwickler, die sich da besser auskennen als ich, Früher oder später annehmen. Es freut mich, Daß sich hier immer mehr Leute auch mit Wired Komponenten beschätigen und ich hoffe Dir zumindest ein wenig weiter geholfen zu haben. Es ist halt alles noch in Entwicklung und noch nicht alles Implementiert :-).

lg Harald
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: BrainHunter am 18 März 2015, 20:46:13
Hallo,

ersteinmal ein Dankeschön an alle Macher für die Library HMW485-lib!
Ich bin gerade dabei einen Controller für z.b. RGB LedStripes zu bauen. Natürlich soll dieser auch HMW "spechen" was er dank der Library auch schon im großen und ganzen kann. Es war zwar etwas Arbeit die "Arduino c++ style" Library in mein STM32 projekt einzubinden aber er gibt sich brav als SW8 aus  ;)

Jetzt habe ich aber ein paar Fragen hauptsächlich bzgl. Fhem:
Kommunikation:
Wie sollte ich am besten das Device pm file aufbauen das ich einen Farbwert (z.b. uint32) an das Device als level schicken kann? Welche Types sind hier gültig? Ich sehe immer nur key und switch... Muss man dazu womöglich in der Fhem HMW implementation etwas hinzufügen?
Macht es alternativ Sinn für jeden Farbkanal einen extra "channel" zu definieren? --> als 3Fach Dimmer. Hier sehe ich aber den Nachteil das viel Overhead auf dem Bus produziert wird, der eig. nicht nötig ist.
Am Ende wäre es natürlich am Schönsten einen ColorPicker zu haben um die Farbe auszuwählen. Leider bin ich in den Interna von Fhem nicht so drin. Wird das Aufwändig?

Naming:
Wie sollte so ein Device eig. heißen? hbw_lc_rgb1, hbw_dim3 ?

Noch eine generelle Frage:
Hat es eigendlich einen bestimmten Grund warum die Fhem-hmw-lib hier im Forum per zip-File "Versioniert" wird? Das hat mich am Anfang von meinen hmw Experimenten doch sehr ausgebremst ;)
Das sollte die neueste Version sein? http://forum.fhem.de/index.php/topic,10607.msg270812.html#msg270812

Vielen Dank schonmal
Nico
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: hglaser am 19 März 2015, 00:20:41
Hallo Markus

Wie versprochen habe ich einmal die Temp-Werte mitgeloggt. Screenshot anbei

Grüße Harald

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 19 März 2015, 01:15:39
Hallo Harald!

Vielen lieben Dank für Deine Rückmeldung! Da weiß ich dann schon einmal ein bißchen mehr... Ist denn der Discovery-Mode im HMW-LC-Bl1-DR-Modul bereits integriert? Es wäre großartig wenn auch die anderen Module in der CCU/LXCCU erkannt und funktionieren würden, wie zB das HMW_LC_Sw2_DR-Modul. Ein Traum wäre es wenn es zum IO-Modul (HMW-IO-12-FM) auch eine funktionierende Version gäbe - darauf freue ich mich schon, falls es jemand hinbekommt!! :-) Meine Fähigkeiten reichen dazu leider noch nicht aus, das weiterzuentwickeln, hoffe aber auf den Ehrgeiz der Entwickler... :-))

ZitatHier könntest Du versuchen die Adresse Deines HMW_LC_Sw1_DR ins Eeprom zu schreiben. Wie das geht ist msg187477 hier beschrieben. Dazu müsstest Du aber in FHEM einsteigen, was ich sehr empfehlen kann. Meine CCU liegt seit einem Jahr im Kasten. :-). In der CCU müsste man "HMW-LC-Bl1-DR" wohl vorher irgendwie komplett löschen.

Ja, den Rolladenaktor hatte ich in der CCU gelöscht, dennoch wurde der Schalt-Aktor als Rolladen-Aktor erkannt... Ich nutze letzten Endes die LXCCU auf nem Raspi - bin damit soweit auch erstmal zufrieden. Im Zusammenhang mit CUxD läßt sich ja schon jede Menge anstellen.

ZitatEs freut mich, Daß sich hier immer mehr Leute auch mit Wired Komponenten beschätigen und ich hoffe Dir zumindest ein wenig weiter geholfen zu haben.

Ich bin ebenfalls ein großer Befürworter für die Wired Komponenten und freue mich über die Entwicklung in diesem Bereich! Daher hoffe ich auch, daß die Basic-Module weiterentwickelt werden und natürlich ist es ebenfalls toll, daß auch neue Komponenten entwickelt werden und sie auch über XML-Files in die CCU/LXCCU implementiert werden können.

@Arthur: Ich bin gespannt, ob das mit den 10 Taster-Eingängen und 8 Ausgängen und der Konfiguration mit den XML-Files klappt - freue mich auf neue Erkenntnisse hierzu... :-) Entspräche dieses Vorhaben denn nicht ansonsten dem HMW-IO-12-Sw7-DR-Modul? Oder auch von der Funktion her einem 12fach-IO-Modul (HMW-IO-12-FM)? Aber an sich sonst bestimmt auch eine feine Sache...

Eine Frage mal zum HMW-IO-12-Sw14-DR: Der soll auch PWM an seinen Ausgängen unterstützen... Ließen sich hierüber dann nicht auch RGB-Stripes per PWM steuern, Mosfets natürlich nachgeschaltet? Somit ließen sich über Programme doch PWM-Werte für Farbwerte verwenden? Fertig wäre der sonst immer noch im Programm fehlende RGB-Dimmer??

Viele Grüße und erstmal eine gute Nacht zusammen...
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 März 2015, 09:38:37
Hi,
ich melde mich hier mal zurueck. Ich habe zurzeit einige andere Projektchen und die Arbeit an "Homematic Wired" wurde ein bisschen frustrierend, da es relativ wenig Feedback gab. Ausserdem kommt mir das HMW-Protokoll inzwischen nicht mehr ganz so geschickt vor. Na egal, es scheint sich ja ganz schoen viel getan zu haben und ich habe mir vorgenommen, mich wieder zu beteiligen. Hat sich mal jemand die Muehe gemacht, alle bisher entstandenen Devices zu sammeln? Wenn nicht, dann koennte ich das tun. Allerdings auch nicht sofort...
Das Protokoll ist auch nocht nicht ganz fertig, was aber im praktischen Betrieb moeglicherweise keine Probleme macht.
Gruss,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 März 2015, 10:04:44
Zitat von: BrainHunter am 18 März 2015, 20:46:13
Ich bin gerade dabei einen Controller für z.b. RGB LedStripes zu bauen. Natürlich soll dieser auch HMW "spechen"
So etwas interessiert mich derzeit auch. Wenn man hier aber "pures HMW" machen will, dann hat man einige Einschraenkungen. Ich denke z.B., dass die CCU nicht wirklich auf RGB-Steuerungen vorbereitet ist. Das beste, was man vielleicht hinbekommen kann, ist wahrscheinlich ein dreifach-Dimmer und ggf. ein paar Tastereingaenge, mit denen man verschiedene Beleuchtungsprogramme auswaehlen kann.
Ich habe zurzeit eine Steuerung im Kopf, mit der ich ungefaehr 500RGB-LEDs einzeln steuern will und dazu noch etwa 40 "Segmente" von weissen LEDs. In HMW "uebersetzt" waeren das dann 1540 Dimmer-Kanaele, was natuerlich Bloedsinn ist. Mal davon abgesehen, wie man sowas sinnvoll in FHEM visualisiert.

Zitat
Jetzt habe ich aber ein paar Fragen hauptsächlich bzgl. Fhem:
Schau vielleicht mal im Nachbar-Thread zu HMW vorbei. Ich glaube, dass dort mehr ueber die FHEM-Integration diskutiert wird.

Zitat
Wie sollte ich am besten das Device pm file aufbauen das ich einen Farbwert (z.b. uint32) an das Device als level schicken kann? Welche Types sind hier gültig? Ich sehe immer nur key und switch... Muss man dazu womöglich in der Fhem HMW implementation etwas hinzufügen?
Es kann gut sein, dass wir das noch nicht als HBW haben. Im Prinzip muesste es so laufen, wie bei den HMW-Dimmern.

Zitat
Macht es alternativ Sinn für jeden Farbkanal einen extra "channel" zu definieren? --> als 3Fach Dimmer. Hier sehe ich aber den Nachteil das viel Overhead auf dem Bus produziert wird, der eig. nicht nötig ist.
Ich denke aber trotzdem, dass das die Variante ist, die am ehesten machbar ist. Wenn man keine wilden Farbwechsel oder -verlaeufe haben will, dann duerfte das auch nicht schlimm sein. Farbwechsel-Spielereien wuerde man ohnehin besser als festes Programm im Device programmieren.

Zitat
Wie sollte so ein Device eig. heißen? hbw_lc_rgb1, hbw_dim3 ?
Tja, ich denke, Du kennst das hier: http://www.fhemwiki.de/wiki/HomeMatic_Namen_verstehen (http://www.fhemwiki.de/wiki/HomeMatic_Namen_verstehen). Ich wuerde sagen, am ehesten sowas wie HBW-DIM3, wenn man es als Dimmer implementiert. Ansonsten neu erfinden, wie z.B. HBW-RGB-1 (eine 1-Kanal-RGB-Steuerung?)

Zitat von: Bromm am 19 März 2015, 01:15:39
Ist denn der Discovery-Mode im HMW-LC-Bl1-DR-Modul bereits integriert?
Wenn ich mich recht erinnere, dann ist das mit dem Discovery-Mode nicht ganz so einfach, da ein Teil davon im RS485-Daemon implementiert sein muesste. Ich hatte das so gemacht, dass ein Geraet unter bestimmten Voraussetzungen ein Announce schickt (z.B. wenn man eine bestimmte Taste drueckt). Das kapiert die CCU und ich glaube auch FHEM.

Zitat
Es wäre großartig wenn auch die anderen Module in der CCU/LXCCU erkannt und funktionieren würden, wie zB das HMW_LC_Sw2_DR-Modul. Ein Traum wäre es wenn es zum IO-Modul (HMW-IO-12-FM) auch eine funktionierende Version gäbe
Wie schon gesagt, wir braeuchten mal eine Auflistung etc. Allerdings habe ich keinen grossen Ehrgeiz, Module zu entwickeln, die man einfach kaufen kann.

Zitat
Eine Frage mal zum HMW-IO-12-Sw14-DR: Der soll auch PWM an seinen Ausgängen unterstützen... Ließen sich hierüber dann nicht auch RGB-Stripes per PWM steuern,
Normalerweise haben RGB-Stripes WS2811 oder aehnlich an Bord. Die werden dann per FastSPI oder so angesteuert. Man braucht also gar kein PWM. In so einem Fall waere es ggf. interessant, den eigentlich existierenden HMW-IO-12-Sw14-DR "nachzuprogrammieren", so dass drei seiner "Ausgaenge" als RGB-Wert aufgefasst werden, aber das ganze dann an einen LED-Stripe geschickt werden kann.

So, jetzt nochmal zur Steuerung der LED-Stripes. Wie schon gesagt, mir schwebt da was "grosses" vor. Im Prinzip will ich jede LED einzeln steuern koennen. Das wird natuerlich per HMW oder auch per FHEM unhandlich. Das muesste man dann irgendwie anders machen. Es gibt aber keinen echten Grund, warum das Device sich nicht zusaetzlich als irgend ein HMW/HBW-Device ausgibt, so dass man darueber Grundfunktionen steuern kann. Dann kann man das Ding in die normale Automatisierung haengen, aber ueber eine spezielle Oberflaeche (ob jetzt FHEM oder nicht) koennen trotzdem weitere Einstellungen vorgenommen werden. Ob das ganze dann noch in einen 328er passt ist natuerlich nicht so ganz sicher, aber es gibt ja auch groessere Hardware.

Gruss,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 19 März 2015, 10:34:17
Hi Thorsten,

schön dich mal wieder "zu sehen"

Zitat von: Thorsten Pferdekaemper am 19 März 2015, 10:04:44
So etwas interessiert mich derzeit auch. Wenn man hier aber "pures HMW" machen will, dann hat man einige Einschraenkungen. Ich denke z.B., dass die CCU nicht wirklich auf RGB-Steuerungen vorbereitet ist.
Kommt drauf an was du alles machen  willst.
Bei einer einfachen RGB(W) Steuerung wirst du ggf. einfach eine Farbe und Helligkeit wählen.
Das wird intern dann als Drei- bzw. Vierfarbwert umgesetzt und die Helligkeit dann per SPI, PWM o.ä. an der Lichquelle eingestellt.
Das Ganze kann man im Protokoll entweder als 3(4) Dimmerwerte an den Aktor übertragen oder aber z.B. auch direkt als Farbwert. z.B. mit einem Colorpicker o.ä.
Das kommt dann darauf an wie man das umsetzen möchte.
Ich sehe hier aber noch keine Einschränkung bei HMW.

ZitatIch habe zurzeit eine Steuerung im Kopf, mit der ich ungefaehr 500RGB-LEDs einzeln steuern will und dazu noch etwa 40 "Segmente" von weissen LEDs. In HMW "uebersetzt" waeren das dann 1540 Dimmer-Kanaele, was natuerlich Bloedsinn ist.
Auch hiermt ist aus meiner Sicht HMW noch überfordert.
Anders sieht es aus, wenn du die 1540 LED's alle in Echzeit ändern willst. Und das ggf. noch mehrmals pro Sekunden.
Dann kommt man aber auch mit DMX recht schnell an seine Grenzen.

ZitatWenn man keine wilden Farbwechsel oder -verlaeufe haben will, dann duerfte das auch nicht schlimm sein. Farbwechsel-Spielereien wuerde man ohnehin besser als festes Programm im Device programmieren.
So sehe ich das auch. So läuft das auch bei meiner "alten" FS20 Steuerung für meine LED-Leisten.
Selbst Farbverläufe und auch "Animationen" lassen sich damit realisieren. Aber eben als "Programm".

ZitatWenn ich mich recht erinnere, dann ist das mit dem Discovery-Mode nicht ganz so einfach, da ein Teil davon im RS485-Daemon implementiert sein muesste.
Ist er schon. Leider funktioniert das "melden" gefundener Geräte aktuell an der LXCCU nicht. Obwohl die alle gefunden werden. Das kann man im Log sehen.

ZitatIch hatte das so gemacht, dass ein Geraet unter bestimmten Voraussetzungen ein Announce schickt (z.B. wenn man eine bestimmte Taste drueckt)
Das machen die "fertigen" Geräte übrigens immer sofern diese noch nicht mit einer Zentrale gepeert sind.

ZitatDas kapiert die CCU und ich glaube auch FHEM.
So solltes es sein.

ZitatSo, jetzt nochmal zur Steuerung der LED-Stripes. Wie schon gesagt, mir schwebt da was "grosses" vor. Im Prinzip will ich jede LED einzeln steuern koennen.
Willst du da eine art Video Draufschicken.
Das wird mit den Gängigen Hausbus-Systemen, egal ob Funk oder Kabel  nix werden.

Viele Grüß
Dirk

Ps. Bist du am Samstag mit in Karlsruhe?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 März 2015, 11:52:50
Zitat von: Dirk am 19 März 2015, 10:34:17
schön dich mal wieder "zu sehen"
Danke.

Zitat
Bei einer einfachen RGB(W) Steuerung wirst du ggf. einfach eine Farbe und Helligkeit wählen.
Das wird intern dann als Drei- bzw. Vierfarbwert umgesetzt und die Helligkeit dann per SPI, PWM o.ä. an der Lichquelle eingestellt.
Ja, klar. Das geht natuerlich. Das meinte ich ja auch. Grundsaetzlich kann man das mit HMW integrieren.

Zitat
Ist er schon. Leider funktioniert das "melden" gefundener Geräte aktuell an der LXCCU nicht. Obwohl die alle gefunden werden. Das kann man im Log sehen.
Ich wusste nicht mehr genau, wo eigentlich das Problem war. Jetzt erinnere ich mich. Genau das war's...

Zitat
Willst du da eine art Video Draufschicken.
Das wird mit den Gängigen Hausbus-Systemen, egal ob Funk oder Kabel  nix werden.
Nein, kein Video. Was ich vorhabe ist etwa das: Ich baue momentan ein Dachstudio aus. Als Beleuchtung will ich so genannte "Lichvouten" machen, in denen LED-Streifen drinliegen. Die Streifen gehen also sozusagen rund um die Decke. Das werden dann etwa 20m LED-Streifen. Ich will mich aber nicht vorab entscheiden muessen, welche Ecke z.B. warmweiss bekommt, wo ggf. ein Farbakzent gesetzt wird etc. Mein Plan ist jetzt, dass eine WS2811-gesteuerte RGB-Leiste und parallel eine (warm)weisse Leiste mit 5630er LEDs reingelegt wird. Letztere in 50cm-Stuecke zerteilt und per PWM oder KSQ geregelt.
D.h. den RGB-Stripe koennte ich dann auf Pixelebene steuern und die weissen zumindest pro 50cm-Segment.
Das ganze soll einmal so reagieren koennen wie eine normale Wohnraumbeleuchtung, also ein-/ausschalten per Lichschalter oder Taster. Es soll aber moeglich sein, die Zuordnung der Segmente/LEDs zu den Schaltern flexibel zu konfigurieren. Ausserdem soll es moeglich sein, weitere Sachen z.B. ueber Bluetooth (oder auch ueber FHEM) per Smartphone oder Rechner zu steuern. So ganz ausgegoren ist es noch nicht, aber ich denke, es ist ungefaehr klar, in welche Richtung es geht

Zitat
Ps. Bist du am Samstag mit in Karlsruhe?
Leider wahrscheinlich nicht. Ich habe da Freunden versprochen beim Umzug zu helfen und hatte das FHEM-Treffen vergessen. Vielleicht komme ich spaeter dazu.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 19 März 2015, 12:24:20
Hallo Thorsten! Hallo Dirk!!

Vielen Dank Euch beiden für Eure Antworten! Und ich freu mich, daß wir auch Thorsten wieder etwas motivieren konnten? :-) Das Thema Homematic Wired ist finde ich ein wichtiges und spannendes Thema, was nicht untergehen sollte... Finde es für vieles besser als alles durch die Luft oder IP-gesteuert zu schicken. Zugegebenermaßen hängt ja der Bus nun auch am Lan durch das Gateway, aber trotzdem. Also ich persönlich freue mich über die Projekte und Weiterentwicklung am Bus!
Auch finde ich es gut, wenn man wenigstens ein paar Standardmodule nachbauen kann. Wie eben halt HMW-LC-Bl1-DR, HMW_LC_Sw2_DR und HMW-IO-12-FM. Damit kommt man dann schon ziemlich weit. Natürlich finde ich auch die Projekte gut, die neue Funktionen implementieren, erst recht wenn sie in FEHM aber vor allem auch in der CCU/LXCCU mit eingebunden werden können als würden es "natürliche" Geräte seien die eben zum System gehören und sich auch so dann steuern bzw. nutzen lassen. Wenn ich das also bisher richtig verstanden habe, dann lassen sich eigene Entwicklungen per XML-File auch in der CCU/LXCCU bekannt machen??

Thorsten, ich wollte eigentlich erstmal im einfachen Fall nur ganz normale analoge RGB-Stripes per Dimmerkanäle ansprechen. Da es die ja bei Homematic bisweilen nicht gibt, ließe sich das ja nachträglich über ein eigenes Modul nachholen. Aber nun habe ich gesehen, daß der HMW-IO-12-Sw14-DR wohl PWM-Ausgänge hat. Nun habe ich ein solches Modul nicht und daher mit diesem auch keine Erfahrung. In der Anleitung steht hierzu auch nicht viel drin. Nur auf der Webseite von ELV und der dortigen Artikelbeschreibung steht eben, daß PWM ausgegeben werden kann. Das dürfte insofern interessant sein, daß man diese ja dann einfach für RGB-Stripes verwenden könnte. Farben ließen sich über Programme steuern. Alles ohne weiteres Zutun, ganz nativ mit vorhandenem Homematic-Material. Das dürfte einige interessieren. Wer ein solches Modul hat, kann ja einmal berichten, ob das mit den PWM-Ausgängen stimmt???
Wenn Du nun so ein großes Projekt mit über 500 einzeln ansteuerbaren RGB-LEDs vorhast, dann ließe sich das tatsächlich aus meiner Sicht nur mit zB WS2801-Chips, DMX oder ArtNet umsetzen. Für DMX und ArtNet gibt es ja bereits viele Beispiele, nachbaubare Controller und auch fertige Komponenten. Über DMXControl (OpenSource) läßt sich zB auch animierte Grafiken über Matrix darstellen. Aber auch für RGB-LEDs mit WS2801 gibt es interessante Lösungen. Die Intelligenz zu diesen Dingen müßte dann wohl tatsächlich auslagern. DMX/ArtNet läßt sich doch auch über FEHM steuern? Zumindest ja über CUxD und die LXCCU. Und somit wiederum über HM, wenn auch in der geplanten Größe ein externes Programm abgefahren wird.
Auf jeden Fall würde ich mich freuen wenn die Entwicklung im Bereich HomeMatic Wired weitergeht, und auch, wie oben gesagt, die bereits angefangenen Projekte weiterentwickelt werden... :-))
Eine Liste welche Geräte welchen Entwicklungsstatus haben wäre wohl tatsächlich gut... Ich kann bisher zumindest berichten, daß ich mit dem HMW-LC-Bl1-DR bisher positive Erfahrung gemacht habe, soweit ich das bisher beobachten konnte. Ich habe dieses Modul über die Arduino IDE auf den Arduino gebracht und es wird von meiner LXCCU erfolgreich eingebunden.
Beim HMW_LC_Sw2_DR hakt es bisher noch. Dieses wird leider bisher als HMW-LC-Bl1-DR erkannt (die Tastereinänge gehen dann auch weiterhin, wie vom zuvor angelernten Rolladenmodul - sollte jetzt ja aber ein Schaltaktor mit gegenüber der CCU/LXCCU neuen Tastereingängen sein)....

Dirk auch Dir besten Dank für Deine schnelle Rückmeldung! Du meinst die nachgebauten Module haben also bereits ein Discovery Mode alle integriert und dieser funktioniert nur mit der CCU? Habe ich Dich dahingehend richtig verstanden? Hmm... Wie oben erwähnt, ich habe eine LXCCU... Und dort wird zumindest HMW-LC-Bl1-DR erfolgreich eingebunden, wenn ich über Geräte suchen gehe, dann Posteingang, dann ist es dort...
Die anderen Module funktionieren bisher nicht bzw. habe ich noch nicht testen können, da ich davon ausgegangen bin, das die Homebrew-Module eh nicht erkannt werden in der CCU/LXCCU ohne XML-File?? Und die Files habe ich nicht gefunden....? Ich habe die Module aus Markus Lib genutzt. https://github.com/kc-GitHub/HM485-Lib/tree/markus

So - jetzt erstmal raus in die Sonne...

Vielen Dank für Eurer aller Hilfe und wie gesagt - ich ziehe den Hut für Eure bisher tolle Arbeit und Euer Engagement...!!! Macht weiter so!! Danke Danke Danke!

Viele Grüße!!
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 19 März 2015, 12:31:36
Hmm... Da kam mittlerweile Thorstens Antwort, während ich tippte... :-)) Cooles Projekt Thorsten! Klingt gut. Dann würde ich das auch über WS2801 lösen. Da gibt es ja Lösungen für zB TV-Ambient-Light (BobLight). Ein Zimmer ist ja im Prinzip nicht anderes als ein großer TV... ;-) Vielleicht läßt sich das ja auf diesem Wege integrieren... Schöner Gedankenanstoß den ich mir mal merke für eigene Projekte...

Viele Grüße!!
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 März 2015, 12:47:18
Zitat von: Bromm am 19 März 2015, 12:24:20Wenn ich das also bisher richtig verstanden habe, dann lassen sich eigene Entwicklungen per XML-File auch in der CCU/LXCCU bekannt machen??
Ja, siehe hier: http://www.fhemwiki.de/wiki/HBW-1W-T10 (http://www.fhemwiki.de/wiki/HBW-1W-T10). Das Ding funktioniert auch in der (LX)CCU.

Zitat
Thorsten, ich wollte eigentlich erstmal im einfachen Fall nur ganz normale analoge RGB-Stripes per Dimmerkanäle ansprechen. Da es die ja bei Homematic bisweilen nicht gibt,
Es gibt keine Dimmer? Bei mir im Keller werkelt ein HMW-LC-Dim1L-DR. Ich bin mir daher ganz sicher, dass es diesen gibt. Allerdings macht der natuerlich eine Phasenanschittsteuerung und kann keine LEDs dimmen. Da muesste man dann einen HBW-LC-Dim3 oder so basteln. Das sollte erstmal nicht ganz sooo schwierig sein. Was der dann hinten genau steuert ist dann ja egal. Da kann man dann PWM, FastSPI oder was auch immer machen. 

Zitat
Aber nun habe ich gesehen, daß der HMW-IO-12-Sw14-DR wohl PWM-Ausgänge hat.
[...]
Das dürfte insofern interessant sein, daß man diese ja dann einfach für RGB-Stripes verwenden könnte.
Wie schon gesagt, RGB-Stripes haben normalerweise schon WS2811 oder sowas. Ansonsten ja, das koennte man vielleicht. Dummerweise ist allerdings PWM nicht gleich PWM.

Zitat
Wenn Du nun so ein großes Projekt mit über 500 einzeln ansteuerbaren RGB-LEDs vorhast, dann ließe sich das tatsächlich aus meiner Sicht nur mit zB WS2801-Chips, DMX oder ArtNet umsetzen.
Die Steuerung selbst bekomme ich wahrscheinlich schon in den Griff, denke ich. Zur Not mit ein paar Arduino Nanos.

Zitat
Dirk auch Dir besten Dank für Deine schnelle Rückmeldung! Du meinst die nachgebauten Module haben also bereits ein Discovery Mode alle integriert und dieser funktioniert nur mit der CCU? Habe ich Dich dahingehend richtig verstanden?
Meiner Meinung nach funktioniert das nicht. Der Daemon bekommt es zwar mit, aber die CCU nicht.

Zitat
Hmm... Wie oben erwähnt, ich habe eine LXCCU... Und dort wird zumindest HMW-LC-Bl1-DR erfolgreich eingebunden, wenn ich über Geräte suchen gehe, dann Posteingang, dann ist es dort...
Das ist weil die Geraete auch Announce-Messages senden.

Zitat
a ich davon ausgegangen bin, das die Homebrew-Module eh nicht erkannt werden in der CCU/LXCCU ohne XML-File?? Und die Files habe ich nicht gefunden....?
Die werden schon "gesehen" und sie tauchen auch im "Posteingang" auf, aber die CCU weiss ohne die XMLs nicht, was sie damit anfangen soll.

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 19 März 2015, 12:55:51
Zitat von: Thorsten Pferdekaemper am 19 März 2015, 11:52:50
Nein, kein Video. Was ich vorhabe ist etwa das: Ich baue momentan ein Dachstudio aus. Als Beleuchtung will ich so genannte "Lichvouten" machen, in denen LED-Streifen drinliegen. Die Streifen gehen also sozusagen rund um die Decke. Das werden dann etwa 20m LED-Streifen.
Ja, so hatte ich das auch gemacht. Auch 0,5 m lange Abschnitte die einzeln adressierbar sind, aber nur 12m. Allerdings nicht mit WS2811 sondern je einen Atmega. Ist aber auch schon etwas älter. Damals gab es die WS2811 noch nicht bzw. nicht so dass ich mir das leisten wollte.

Da ich das "damals" noch mit FS20-Technik umgesetzt hatte, konnte man die "Programme" die Abrufbar waren auf einer SD-Karte hinterlegen.
Mit HMW sollte das hier aber auch keine Problem sein das ganze über den Bus zu "programmieren".
Das Interface dazu ist natürlich eine kleine Herausforderung

ZitatDas ganze soll einmal so reagieren koennen wie eine normale Wohnraumbeleuchtung, also ein-/ausschalten per Lichschalter oder Taster.
Hier kommt das das Peering mit Tastern und anderen Sensoren in Aktion.

ZitatVielleicht komme ich spaeter dazu.
Das würde  mich freuen.



Zitat von: Bromm am 19 März 2015, 12:24:20
Aber nun habe ich gesehen, daß der HMW-IO-12-Sw14-DR wohl PWM-Ausgänge hat.
ZitatIn der Anleitung steht hierzu auch nicht viel drin. Nur auf der Webseite von ELV und der dortigen Artikelbeschreibung steht eben, daß PWM ausgegeben werden kann.
PWM kann man das leide nicht nennen.
Man kann die Ausgänge "blinken" lassen. Auch mal schnell. Für PWM reicht das aber nicht.

ZitatDirk auch Dir besten Dank für Deine schnelle Rückmeldung! Du meinst die nachgebauten Module haben also bereits ein Discovery Mode alle integriert und dieser funktioniert nur mit der CCU?
Das wollte ich damit nicht sagen. Es ging nur um den Discovery-Mode vom HM485-Daemon.
Der funktioniert zusammen mit der CCU2 nicht.

ZitatWie oben erwähnt, ich habe eine LXCCU... Und dort wird zumindest HMW-LC-Bl1-DR erfolgreich eingebunden, wenn ich über Geräte suchen gehe, dann Posteingang, dann ist es dort...
Aber nur mit dem HMW-LAN-GW.
Der HM485-Daemon ersetzt quasi das HMW-LAN-GW. Damit lässt sich ein einfacher USB-RS485-Adapter als SChnittstelle an FHEM oder auch an der CCU2/LXCCU verwenden.

ZitatDie anderen Module funktionieren bisher nicht bzw. habe ich noch nicht testen können, da ich davon ausgegangen bin, das die Homebrew-Module eh nicht erkannt werden in der CCU/LXCCU ohne XML-File??
Das ist richtig. Zumindest an der CCU/CCU/LXCCU kann man mit einer eigenen XML-Datei die Module dann benutzen.
Die HMW-Module für FHEM sind da noch nicht so weit. Leider fehlt mir da aktuell die Zeit hier aktiv weiterzuentwickeln.


Gruß
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 März 2015, 14:04:50
Zitat von: Dirk am 19 März 2015, 12:55:51
Ja, so hatte ich das auch gemacht. Auch 0,5 m lange Abschnitte die einzeln adressierbar sind, aber nur 12m. Allerdings nicht mit WS2811 sondern je einen Atmega.
Direkt koennten das bei meinem Plan die WS2811 auch nicht. Meine Segmente werden wohl 12V oder 24V haben und 750mA bzw. 375mA. Eigene Stripes zu loeten will ich momentan vermeiden. Die WS2811 hatten sich auf die RGB-Stripes bezogen, da es die so zu kaufen gibt.
Aber im Prinzip ist es natuerlich eine gute Idee, die weissen Segmente ueber WS2811 zu versorgen. Dann kann man einfach jedem Segment ein WS2811 und ein Transistor spendieren. Ich kann mir nur vorstellen, dass man mit der Kabel-Laenge zu kaempfen hat, zumindest bei fastSPI.

Zitat
Mit HMW sollte das hier aber auch keine Problem sein das ganze über den Bus zu "programmieren".
Klar, man kann ja im Prinzip direkt das EEPROM schreiben und dann von dort lesen, was man machen will.
Beim User-Interface kann man sich natuerlich austoben, oder man macht die komplexen Sachen nur per Arduino-Programmierung. Mal sehen, wie das wird...
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 20 März 2015, 12:28:56
Hallo zusammen!

Danke für Eure Antworten!
ZitatEs gibt keine Dimmer? Bei mir im Keller werkelt ein HMW-LC-Dim1L-DR. Ich bin mir daher ganz sicher, dass es diesen gibt. Allerdings macht der natuerlich eine Phasenanschittsteuerung und kann keine LEDs dimmen.
Genau...  ;)

Die vorhandenen Homebrew-Module sind dann also soweit fertig... Funktionieren also soweit schon unter FEHM? Und in der CCU/LXCCU theoretisch vorausgesetzt die XML-Datei würde existieren? Gut. Vielleicht kann ich mich da ja etwas betätigen. Habt Ihr da vielleicht ein paar Tipps was ich da genau beachten muss, bevor ich es auf eigene Faust versuche? Wie genau müßten die Informationen von dem pm-File ins XML-File übersetzt werden? Also, es folgen ja beide sicher immer dem gleichen Muster... Oder gibt es dazu schon ein Tool?
Oder liege ich da falsch, daß nur die XML-Dateien fehlen?

Viele Grüße!!
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 20 März 2015, 13:17:08
Zitat von: Bromm am 20 März 2015, 12:28:56
Die vorhandenen Homebrew-Module sind dann also soweit fertig... Funktionieren also soweit schon unter FEHM? Und in der CCU/LXCCU theoretisch vorausgesetzt die XML-Datei würde existieren? Gut.
Alles das muesste man mal zusammenstellen. Ich bin mir nicht sicher, ob das alles funktioniert.

Zitat
Vielleicht kann ich mich da ja etwas betätigen. Habt Ihr da vielleicht ein paar Tipps was ich da genau beachten muss, bevor ich es auf eigene Faust versuche? Wie genau müßten die Informationen von dem pm-File ins XML-File übersetzt werden? Also, es folgen ja beide sicher immer dem gleichen Muster... Oder gibt es dazu schon ein Tool?
Oder liege ich da falsch, daß nur die XML-Dateien fehlen?
Wie gesagt, keine Ahnung, ob das nur an den XML-Files liegt. Jedenfalls wird es ohne die nicht gehen.
Von wegen Tool: Dirk wollte mal was schreiben (oder hat es sogar), das die XML-Dateien in die .pm-Dateien uebersetzt. Normalerweise (fuer die gekauften Module) hat man ja das XML, aber keine .pm.
Ansonsten muss man halt anhand der existierenden XML files orakeln, wie es fuer ein neues Device gehen koennte.
Gruss,
  Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 20 März 2015, 13:25:32
Zitat von: Bromm am 20 März 2015, 12:28:56
Wie genau müßten die Informationen von dem pm-File ins XML-File übersetzt werden? Also, es folgen ja beide sicher immer dem gleichen Muster... Oder gibt es dazu schon ein Tool?
Am besten währ es zuerst die XML-Files zu erstellen. Hier kann man aus den existierenden "spicken"
In meiner der DEV-Version der HM485-Module ist ein Converter der die XML-Files nach .pm konvertiert.
Da ich aktuell kaum mit deren Weiterentwicklung vorankomme hat Gevoo hier einiges weiter gemacht.
Leider scheint er hier einen eigenen Weg zu gehen. Somit funktioniert das bei seinen Entwicklungen wohl nicht.
Ich muss hier dann wohl zeitnah mal weitermachen.

Viele Grüße
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 20 März 2015, 14:14:53
Also, ein guter Ansatz wäre dann tatsächlich, wenn man erst die XML-Files bei der Erstellung eines Moduls hätte, die dann nach pm-Files für FHEM konvertiert werden - oder FHEM XML versteht... Nun, für die existierenden Projekte ist ja nun erstmal der umgekehrte Weg von Nöten. Also werde ich mal versuchen zu "orakeln" und versuchen zu verstehen, wie die XML-Files genau aufgebaut sind bzw. welche Informationen die CCU/LXCCU benötigt und wo bzw. welche die entsprechenden Informationen im pm-File sind... Eine grobe Vorstellung vom Inhalt habe ich schon, aber der Teufel liegt ja im Detail... Es müßte so eine Art Schablone oder Vorlage für die von der CCU/LXCCU benötigten Daten geben, in die man dann einfach nur noch modulspezifische Daten eintragen braucht. Das wäre dann vielleicht für zukünftige Entwicklungen einfacher...

Beste Grüße!!
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: BrainHunter am 20 März 2015, 17:53:41
Hallo,

danke für die Antworten.
Ich habe jetzt eine Version von meinem RGB Controller als "3fach Dimmer" am laufen. Das funktioniert schon echt gut. Ich werde jetzt versuchen meine ganzen Änderungen gerade zu ziehen, dass ich das ganze dann wieder ins Github packen kann.

Zu den config Files:
Hier wäre es sicherlich Sinnvoll mal alle Informationen zu sammeln und eine kleine Doku zu machen. Wenn jemand im Wiki oder so eine Seite beginnen könnte wäre ich gerne bereit mitzuwirken soweit ich kann.

grüße,
Nico
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 20 März 2015, 22:18:37
Hallo Nico!

Das klingt spannend! :-) Freue mich jetzt schon auf Dein Projekt... Wäre toll wenn da dann auch gleich ein passendes XML-File entsteht. Da arbeite ich mich auch gerade hinein, da diese bei den anderen Projekten leider noch fehlt... Prima, daß es bald ein RGB-Modul gibt - das wird sicher einigen fehlen...

Viele Grüße!
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: gevoo am 21 März 2015, 19:23:04
Hallo,

der xml --> pm Konverter ist fertig und in diesem Packet http://forum.fhem.de/index.php/topic,10607.msg276180.html#msg276180 enthalten.

Grüße gevoo
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: BrainHunter am 22 März 2015, 00:08:30
Hallo gevoo,

Ich habe die Version auf meinem Testsystem mal installiert, hier bekomme ich aber mit den Homebrew Devices fehler:
configfile: model of "HBW_LC_Sw8_HBW4073471" must one of HMW_IO_SR_FM HMW_LC_Dim1L_DR HMW_LC_Sw2_DR HMW_IO_12_Sw14_DR HMW_IO_4_FM HMW_LC_Bl1_DR HMW_IO_12_FM HMW_IO_12_Sw7_DR
Eine komplette Neuinstall habe ich nicht versucht bisher, aber auf den ersten Blick sieht es so aus als ob man die Devices erst noch irgendwo anders bekannt machen muss?

Zitat von: Bromm am 20 März 2015, 22:18:37
Das klingt spannend! :-) Freue mich jetzt schon auf Dein Projekt... Wäre toll wenn da dann auch gleich ein passendes XML-File entsteht.
Ich habe bisher noch nicht mit den XML Files gearbeitet, da ich keine ccu installiert habe. Evtl spiele ich mal mit einer lxccu. Aber wie du siehst gibt es noch andere ungelöste Probleme ;-)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: gevoo am 22 März 2015, 09:23:47
Hallo Nico,

Dir wird nur ein kompletter Dateitausch der HMW Dateien übrigbleiben, wenn Du eine Version kleine als 0.5.130 benutzt hast.

Gruß gevoo
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 März 2015, 11:36:41
Hi,
ich habe mir mal die Mühe gemacht, die mir bisher bekannten Homebrew-Geräte bzw. geplante Entwicklungen solcher Geräte zusammenzustellen. Siehe hier: http://www.fhemwiki.de/wiki/HomeMatic_Wired#Aktoren_.2F_Sensoren (http://www.fhemwiki.de/wiki/HomeMatic_Wired#Aktoren_.2F_Sensoren).
Die Tabelle enthält den momentanen Stand, soweit er mir bekannt ist. Ich habe nichts davon aktuell ausprobiert, sondern nur alles aus dem Forum und Github übernommen.
Es wäre nett, wenn die Geräte-Entwickler mal kurz drüberschauen könnten. Ich habe auch die Hoffnung, dass wir diese Liste irgendwie aktuell halten können.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: hglaser am 22 März 2015, 12:10:53
Hallo Thorsten

Danke, daß Du Dich darum kümmerst. Ich sehe gerade daß die ID 0x91 schon vom HBW-Sec-MDIR-2 belegt ist. Wusste ich leider nicht, und werde es beim HBW-CC-Vd2-T auf 0x87 ändern. Dies scheint die nächste freie ID zu sein. Darf ich die nehmen?

edit: typo

Grüße Harald
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 März 2015, 12:42:14
Zitat von: honk am 22 März 2015, 12:10:53
Ich sehe gerade daß die ID 0x91 schon vom HBW-Sec-MDIR-2 belegt ist. Wusste ich leider nicht, und werde es beim HBW-CC-Vd2-T auf 0x87 ändern. Dies scheint die nächste freie ID zu sein. Darf ich die nehmen?
Hi,
klar darfst Du das. Leider hat halt das Homematic-Wired-Konzept das Problem, dass man die Gerätetypen und (auch die Geräte-Adressen) global gültig definieren muss. Da kann es immer mal wieder zu Kollisionen kommen.

EDIT: Hab's gleich im Wiki geändert.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 März 2015, 12:44:31
Zitat von: BrainHunter am 20 März 2015, 17:53:41Ich habe jetzt eine Version von meinem RGB Controller als "3fach Dimmer" am laufen.
Könntest Du das Coding zur Verfügung stellen? Ich würde mir gerne einen "40-fach Dimmer" bauen...
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: hglaser am 22 März 2015, 13:07:08
Zitat von: Thorsten Pferdekaemper am 22 März 2015, 12:42:14
klar darfst Du das. Leider hat halt das Homematic-Wired-Konzept das Problem, dass man die Gerätetypen und (auch die Geräte-Adressen) global gültig definieren muss.

EDIT: Hab's gleich im Wiki geändert.
Danke Thorsten,

ich habs nun geändert und ins github (https://github.com/hresalg/HBW) gestellt. könntest Du das im Wiki auch noch ändern?

Grüße Harald
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 März 2015, 13:19:33
Erledigt.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: BrainHunter am 22 März 2015, 15:54:55
Hallo,

Zitat von: gevoo am 22 März 2015, 09:23:47
Dir wird nur ein kompletter Dateitausch der HMW Dateien übrigbleiben, wenn Du eine Version kleine als 0.5.130 benutzt hast.
Gestern war es schon spät.. heute habe ich beim ersten Blick gesehen das sich der Aufbau der pm-files zu den früheren Versionen komplett geändert hat. --> am besten also ich erstelle ein xml und erzeuge mit dem converter das pm.

Zitat von: Thorsten Pferdekaemper am 22 März 2015, 12:44:31
Könntest Du das Coding zur Verfügung stellen? Ich würde mir gerne einen "40-fach Dimmer" bauen...
Das wollte ich eig. erst machen wenn das Projekt etwas weiter fortgeschritten ist, aber ich kann das auch schon früher angehen.
40Fach Dimmer hört sich schon recht "groß" an ;-) Denkst du da an Phasen-an/abschnitt oder "nur" PWM ausgang für Led's?

grüße Nico
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 März 2015, 17:50:43
Zitat von: BrainHunter am 22 März 2015, 15:54:5540Fach Dimmer hört sich schon recht "groß" an ;-) Denkst du da an Phasen-an/abschnitt oder "nur" PWM ausgang für Led's?
Das ist für LEDs gedacht.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 März 2015, 17:59:02
Zitat von: MarkusO am 11 Oktober 2014, 23:13:49
Für Thorstens 1-wire Temperatursensor habe ich jetzt übrigens ein passendes pm-File gebaut, mit dem das Modul in FHEM erkannt wird
Das Device-File lief bei mir nicht. Möglicherweise gab es inzwischen wieder zu viele Änderungen an der FHEM-Anbindung. Ich habe mit Hilfe des XML->PM-Tools ein eigenes gemacht, was ich aber auch noch ein bisschen ändern musste.
Mit meinem File funktioniert es jetzt so einigermaßen. Ich habe es in "mein" git gelegt: https://github.com/kc-GitHub/HM485-Lib/tree/thorsten/HBW-1W-T10 (https://github.com/kc-GitHub/HM485-Lib/tree/thorsten/HBW-1W-T10)
Ein paar kleine Probleme gibt es damit auch noch, aber die schiebe ich mal auf die unfertige HMW-Integration in FHEM.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: BrainHunter am 22 März 2015, 18:13:58
Zitat von: Thorsten Pferdekaemper am 22 März 2015, 17:50:43
Das ist für LEDs gedacht.
Nice! das gibt einen schönen Kabelverhau  ;D

Ich habe mich heute Nachmittag auch etwas mit den Files beschäftigt. Die ganzen pm Devicefiles aus den Repos dürften nicht mehr funktionieren. Die muss man alle überarbeiten :-(
Am besten wird hier sein dann gleich ein xml zu erstellen und zu konvertieren. So habe ich das für meinen RGB-ctrl auch mehr oder weniger erfolgreich auf Basis des DIM1 xmls versucht.

gruß,
Nico
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 März 2015, 18:22:11
Zitat von: BrainHunter am 22 März 2015, 18:13:58
Nice! das gibt einen schönen Kabelverhau 
Der Punkt ist, dass ich das vermeiden will. Meine momentane Idee ist, für die Ansteuerung eines Segments (also eins der 40) mit je einem Attiny oder sowas und einem Mosfet so eine Art Power-WS2801 zu realisieren. D.h. die einzelnen Segmente werden verkettet.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: hglaser am 22 März 2015, 19:03:51
Hallo

Ich habe auch ein xml gebastelt und es in eine ccu gespielt. Nun wäre noch die Frage, woher er denn die Typenbezeichnung nimmt ? steht das auch im xml-File?
Das das Bild fehlt ist mir klar. aber die Bezeichnung "DEVICE" und "unbekanntes Gerät" hätt ich noch gern irgendwie gelöst. Ansonsten lässt sich das Gerät auch in der CCU bedienen. Zwar noch nicht schön (wie ein Blind-Aktor halt), aber es geht.

lg Harald
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: BrainHunter am 22 März 2015, 21:18:19
Zitat von: Thorsten Pferdekaemper am 22 März 2015, 18:22:11
Der Punkt ist, dass ich das vermeiden will. Meine momentane Idee ist, für die Ansteuerung eines Segments (also eins der 40) mit je einem Attiny oder sowas und einem Mosfet so eine Art Power-WS2801 zu realisieren. D.h. die einzelnen Segmente werden verkettet.
Klingt gut. Das lässt sich kompakt bauen und nahe an den LEDs unterbringen. Das Programm am Attiny wird auch trivial: Spi rein - PWM raus ;) Ich bin gespannt.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 23 März 2015, 23:17:35
Zitatich habe mir mal die Mühe gemacht, die mir bisher bekannten Homebrew-Geräte bzw. geplante Entwicklungen solcher Geräte zusammenzustellen. Siehe hier: http://www.fhemwiki.de/wiki/HomeMatic_Wired#Aktoren_.2F_Sensoren.
Großartig! Bei der Vielzahl an Homebrew-Modulen ist so eine Übersicht auf jeden Fall hilfreich.

Ich habe auch mal direkt ein Update für dem vierfach Rollo-Aktor hochgeladen
https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Bl4 (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Bl4)

Das .pm-File dabei funktioniert mit dem HM485-Modul aus Dirks Master-Branch. Für die Version aus dem HM485-Thread von gevoo habe ich die Files noch nicht aktualisiert. Wie ist denn hier eigentlich der Trend? Gibt es eine Empfehlung auf welche Version man setzen sollte?

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 24 März 2015, 00:55:32
Hallo zusammen!

Ich habe hier mal eine Frage an alle Homebrew-Entwickler bzw. zu den bereits entwickelten Devices... Zu den meisten hier bereits erstellten Devices fehlen die XML-Dateien. Diese sind für eine Einbindung in die native Umgebung der CCU/LXCCU nötig. Habt Ihr solche XML-Files die ggf. nur nicht veröffentlicht wurden? Mein Vorschlag ist zu selbstentwickelten Homebrew-Devices eine entsprechende XML-Datei zu erstellen und diese dann mit Hilfe des Konverters dann in pm-Files umzuwandeln. Somit wären beide Welten abgedeckt - CCU/LXCCU und FHEM. Ich wollte ansonsten versuchen die fehlenden XML-Dateien zu erstellen, allerdings möchte ich das Rad auch nicht neu erfinden... Daher die Frage, ob die entsprechenden XML-Files bereits existieren und sie ebenfalls zur Verfügung gestellt werden können??

Ich muß mich aber auch noch etwas in die benötigten Daten für die XML-Dateien und die zugehörigen Devices einarbeiten. Denn momentan müßten so erstmal die pm-Files in XML-Files gewandelt werden....

Die Übersicht für die bereits existierenden Devices ist gut und sollte weitergeführt werden! Danke Thorsten!

Vielen Dank schon einmal für Eure Hilfe und Euch einen schönen Abend!
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 24 März 2015, 12:04:36
Zitat von: MarkusO am 23 März 2015, 23:17:35
Das .pm-File dabei funktioniert mit dem HM485-Modul aus Dirks Master-Branch. Für die Version aus dem HM485-Thread von gevoo habe ich die Files noch nicht aktualisiert. Wie ist denn hier eigentlich der Trend? Gibt es eine Empfehlung auf welche Version man setzen sollte?
Also eine echte Empfehlung habe ich nicht, aber ein paar Kommentare um die Diskussion anzuregen. Ich persönlich verwende momentan die Version von gevoo (sorry Dirk). Ich habe einfach den Eindruck, dass da schon mehr funktioniert und dass hier gerade aktiver weiterentwickelt wird. Ich habe allerdings die Hoffnung, dass die zwei Versionen irgend einmal wieder zu einer werden. Es wäre schön, wenn gevoo und Dirk mal direkt miteinander reden würden und das klären.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 24 März 2015, 12:10:03
Zitat von: Bromm am 24 März 2015, 00:55:32Mein Vorschlag ist zu selbstentwickelten Homebrew-Devices eine entsprechende XML-Datei zu erstellen und diese dann mit Hilfe des Konverters dann in pm-Files umzuwandeln.
Also prinzipiell fände ich das auch gut. Allerdings kann ich mir vorstellen, dass das nicht ganz so einfach ist. Es hat ja nicht jeder eine CCU (ob jetzt eine "echte" oder lxCCU). Außerdem ist es trotz allem ein gewisser Aufwand, das XML zu erstellen. Bei mir ist das immer etwas trial&error, wobei man dazwischen die CCU immer wieder neu starten muss. Das dauert meistens ziemlich lange.
Dazu kommt noch, dass der Konverter zurzeit auch nicht wirklich das pm-Format erzeugt, das gebraucht wird. Details dazu habe ich schon in diesem Thread ein paar Posts vorher beschrieben.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 24 März 2015, 15:18:21
Zitat von: Thorsten Pferdekaemper am 24 März 2015, 12:04:36
Ich persönlich verwende momentan die Version von gevoo (sorry Dirk). Ich habe einfach den Eindruck, dass da schon mehr funktioniert und dass hier gerade aktiver weiterentwickelt wird.
Warum auch nicht. Gevoo hat halt die ältere Version von mir weiterentwickelt.
Das ist doch völlig legitim. Daher gibt es keinen Grund die alte Version zu verwenden.

Zitat von: Thorsten Pferdekaemper am 24 März 2015, 12:04:36
Ich habe allerdings die Hoffnung, dass die zwei Versionen irgend einmal wieder zu einer werden.
Das Vorgehen hatte ich früher schon einmal vorgeschlagen.
Leider bleiben meine Ideen und Hinweise zumeist ohne Feedback.

Zitat von: Thorsten Pferdekaemper am 24 März 2015, 12:10:03
Bei mir ist das immer etwas trial&error, wobei man dazwischen die CCU immer wieder neu starten muss. Das dauert meistens ziemlich lange.
Es sollte auf der (LC)CCU ausreichen den hs485d neu zu starten dann werden die die XML-Dateien neu geladen.
Das geht deutlich schneller

Viele Grüße
Dirk
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 24 März 2015, 15:54:53
Zitat von: Dirk am 24 März 2015, 15:18:21
Warum auch nicht. Gevoo hat halt die ältere Version von mir weiterentwickelt.
Das ist doch völlig legitim. Daher gibt es keinen Grund die alte Version zu verwenden.
Ok, dann lautet die "offizielle" Empfehlung, dass man gevoos Version verwenden soll.

ZitatEs sollte auf der (LC)CCU ausreichen den hs485d neu zu starten dann werden die die XML-Dateien neu geladen.
Das wundert mich zwar ein bisschen, aber ich werde es das nächste mal ausprobieren.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Dirk am 24 März 2015, 16:25:12
Meine Empfehlung dazu war und ist, die Änderungen mit ins Github zu integrieren.
Dann muss man sich die Files auch nicht aus dem Forum zusammensuchen.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 24 März 2015, 16:37:21
Zitat von: Dirk am 24 März 2015, 16:25:12
Meine Empfehlung dazu war und ist, die Änderungen mit ins Github zu integrieren.
Ok, ich bringe das im anderen Thread nochmal zur Sprache.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 26 März 2015, 17:41:21
Also, ich fände es wirklich sinnvoll mit den XML-Files. Denn wozu sollte man denn Homebrew-Devices Homematic-kompatibel erstellen, wenn sie dann hinterher doch nicht mit Homematic kompatibel sind bzw. mit der CCU/LXCCU "nativ" nutzbar sind. Sonst könnte man ja auch irgendein Protokoll für den Datenaustausch verwenden. Daher fände ich es schade, wenn es nur unter FHEM läuft, obwohl man sich doch an einem existierenden System orientiert und passend baut. Klar, es ist erstmal ein gewisser Aufwand diese Dateien zu erstellen. Er kann allerdings auch nicht wesentlich größer oder anders sein als eine pm-Datei zu erstellen. Nur eben ein anderes Format. Man muß eben, wie ich denke, nur erst einmal ein bekanntes Grundgerüst haben, in das man dann die Konfigurations-Daten bringt, denn die XML-Files folgen ja auch immer dem gleichen Muster. Ist es nicht so, daß die gleichen Basis- bzw. Konfigurationsinformationen in beiden Datei-Formaten enthalten sind?

Ich würde mich wie gesagt freuen, wenn die Entwicklung in Richtung der XML-Files weitergeht.

Mit besten Grüßen!!
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 26 März 2015, 17:47:01
Hi,
ich wollte ja auch gar nicht sagen, dass ich die XML Files blöd finde. Ich wollte nur erklären, warum das nicht ganz so einfach ist.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 26 März 2015, 21:47:06
Hi!!

Es sollte kein böses Meckern sein... Tut mir leid, wenn das so rüber kam!! Du hattest ja gesagt, daß Du es auch gut findest, mit den XMLs... Und ich finde es ja auch gut, wenn hier ein Austausch über das Für und Wider stattfindet. :-)

Viele Grüße!!
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 29 März 2015, 18:06:33
Hallo!

Ich habe nun einmal eine Frage zum hbw_lc_bl4, HBW-Device für 4fach Rollosteuerung. Ich bin gerade dabei hierfür eine XML-Datei für die CCU/LXCCU zu erstellen. Vielmehr nahm ich nun erstmal die XML-Datei zum Original 1fach-Aktor und versuche diese anzupassen. Als Referenz dient die pm-Datei zum hbw_lc_bl4. Jetzt stellte sich mir die Frage, wie das nachher denn dargestellt wird. Als einzelner 4-fach-Aktor oder als 4 einzelne 1-fach-Aktoren?? Ich denke, es soll wohl als 4-fach-Aktor dargestellt werden?

Viele Grüße!
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 29 März 2015, 18:50:16
ZitatIch bin gerade dabei hierfür eine XML-Datei für die CCU/LXCCU zu erstellen
Hi Björn, find ich super, dass Du die passende XML-Datei für den vierfach-Aktor baust. Ich selbst habe keine CCU und verwende nur FHEM. Daher habe ich selbst auch keine Testmöglichkeiten (und zugegeben auch etwas wenig Motivation) ein XML-File für den Aktor zu erstellen.

ZitatVielmehr nahm ich nun erstmal die XML-Datei zum Original 1fach-Aktor und versuche diese anzupassen
Genauso hab ich das bei dem pm-File auch gemacht. Damit wird in FHEM jetzt ein Aktor mit vier Kanälen angezeigt. In der SW auch ein Aktor (mit einer ID) mit vier Kanälen implementiert.

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 30 März 2015, 23:56:48
Hallo Markus!

Danke für Deine Antwort!! Zumindest versuche ich es mit dem erstellen der XML-Datei und hoffe, ich werde hier bald positives berichten können. Wenn alles läuft werde ich es hier berichten und natürlich zur Verfügung stellen, damit es auch ins GitHub aufgenommen werden kann... Ich bin aus zeitlichen Gründen noch nicht zum Testen gekommen, aber erstellt habe ich zumindest schon einmal eine XML-Datei für den hbw_lc_bl4. Ich bin auch gespannt wie es sich dann später in der CCU/LXCCU darstellt.
Mir ging sonst auch schon der Gedanke durch den Kopf, ob sich der Aktor nicht auch wie vier einzelne Aktoren gegenüber der CCU/LXCCU verhalten könnte? Nur einmal als Gedankenspiel...
Noch eine generelle Frage: Wo wird zur Zeit eigentlich nun die Geräte-Seriennummer festgelegt bzw wie erstellt? Geschieht es nun beim Upload des Sketches? Wird sie zB auf Grund der Uploadzeit generiert und ins EEPROM geschrieben? Läßt sie sich anpassen? Wie ist hierbei das Verfahren? Es sollte ja möglich sein das gleiche Sketch auf verschiedenen Arduinos zu installieren und alle haben dann natürlich verschiedene Seriennummern. Ich frage nur deshalb, damit ich hier für mich etwas mehr Klarheit bekomme. Das Thema wurde zwar hier und da diskutiert, mich interessiert nun der aktuelle Stand der Dinge und wie es im Moment funktioniert?
Die Geräte-ID 0x82 für zB den hbw_lc_bl4 ist nicht in der pm-Datei und auch nicht in der XML-Datei hinterlegt sondern wird aus dem EEPROM ausgelesen?

Viele Grüße
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 31 März 2015, 23:29:24
Hallo zusammen!

Kleiner Zwischenbericht zum HBW-LC-Bl4. Eine hierzu angepasste XML-Datei habe ich nun auf die CCU/LXCCU geladen. Das Sketch von Markus habe ich auf den Arduino gespielt - zunächst die vorletzte Version und dann die letzte Version. In der CCU/LXCCU erhalte ich nach dem Anlernen leider nur ein folgendes Device: HMW-Generic HBW0417068
Es sind keine Parameter unter Geräteeinstellungen verfügbar und auch wird das Device nicht als HBW-LC-Bl4 erkannt.
Folgende Fragen stelle ich mir nun:
Wo liegt der Marker der das Device als HBW-LC-Bl4 ausweist? Also, wie erkennt die CCU/LXCCU das Device und wählt die richtige XML-Datei aus? In welcher Datei von den Source-Dateien wird dies markiert bzw. festgelegt? Es muß ja irgendwo die Verknüpfung zwischen der XML-Datei und dem Device beim Anlernen existieren?
Auch beim Quervergleich zum funktionierenden 1wire-Modul bin ich noch nicht auf die entsprechende Stelle gestoßen, so daß ich die korrekte Erkennung nachbauen könnte. Wer weiß hierzu Rat?

Im Übrigen sendet das HBW-LC-Bl4-Device nun ständig über den Bus folgende Statusmeldungen:

.....
State: RELAY_OFF - Time: 781172 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 801172 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 821172 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 841172 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 861172 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 881172 - Target: 0 - Actual: 0
und so weiter....

Soll das so sein?? Ist das nötig? Das passierte in der vorletzten Version des Sketches nicht... Sehe auch nicht so recht den Sinn darin??

Viele Grüße und ich würde mich über Tipps freuen...
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: BrainHunter am 01 April 2015, 00:06:47
Hallo Björn

Zitat von: Bromm am 30 März 2015, 23:56:48
Die Geräte-ID 0x82 für zB den hbw_lc_bl4 ist nicht in der pm-Datei und auch nicht in der XML-Datei hinterlegt sondern wird aus dem EEPROM ausgelesen?

Die Geräte-ID steht im XML File nicht in Hex form sondern in Dezimal. Bei dir dann --> 0x82 = 130


<supported_types>
<type name="RS485 One Wire 10 Channel Temperature Module" id="HBW-1W-T10" priority="2">
                <parameter index="0" size="1" const_value="129"/>    <<---- HIER


Wenn du das hast sollte die CCu auch das richtige Device finden. Ich habe jedoch noch keine ccu getestet, deshalb alle Angaben ohne Pistole du weist schon ;-)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 01 April 2015, 00:11:31
Hi Björn,

die Statusmeldungen sollten eigentlich nur auf der Debug-Schnittstelle gesendet werden. Standardmäßig ist das bei dem Hex-File das "Softserial"-Interface auf den Pins 5/6. Auf dem RS485-Bus (an den Pins 0/1) sollten diese Statuswerte nicht geschickt werden, oder? Wenn das doch so ist, schau ich mir den Code nochmal an - vielleicht hab ich da irgend einen Bug nicht entdeckt.

ZitatWo liegt der Marker der das Device als HBW-LC-Bl4 ausweist? Also, wie erkennt die CCU/LXCCU das Device und wählt die richtige XML-Datei aus? In welcher Datei von den Source-Dateien wird dies markiert bzw. festgelegt? Es muß ja irgendwo die Verknüpfung zwischen der XML-Datei und dem Device beim Anlernen existieren?

In dem Quellcode für das Device wird die Geräte ID fest vergeben:

hmwmodule = new HMWModule(&hmwdevice, &hmwrs485, 0x82);


In dem pm-File wird dann auf die gleiche ID verwiesen. Allerdings nicht im Hex-Format, sondern als Dezimalzahl, daher nicht so schnell zu entdecken (0x82 = 130):

'name' => 'RS485 blind actuator 4-channel',
'type' => 130,
'minFW_version' => 0x0303


ZitatFrage: Wo wird zur Zeit eigentlich nun die Geräte-Seriennummer festgelegt bzw wie erstellt? Geschieht es nun beim Upload des Sketches? Wird sie zB auf Grund der Uploadzeit generiert und ins EEPROM geschrieben? Läßt sie sich anpassen?
Die Geräte-ID wird im EEPROM gespeichert (ganz am Ende, wenn ich mich richtig erinnere). Standardmäßig steht die ID auf 0x42FFFFFF und kann über per "@a" Befehl geändert werden.
Um nach dem Flashen auch ohne diesen Befehl eine neue individuelle ID vergeben zu können, hatte ich für den Rollo-Aktor aber auch eine Funktion eingebaut, die eine ID vergibt, wenn das Device zurückgesetzt wird (Taster 5 sek drücken, loslassen, nochmal 3 sek drücken). Die vergebene ID ergibt sich aus der Zeit zwischen dem Starten und dem Reset. Ich denke, die Wahrscheinlichkeit, dass jemand seine Geräte nach dem Flashen nach exakt der gleichen Zeit (ms) zurück setzt und damit eine ID zweimal vergibt, ist recht gering.

Ich hoffe, das hilft Dir weiter.


Viele Grüße
Markus


Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 01 April 2015, 00:12:16
Oh, da war schon jemand schneller...
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 01 April 2015, 01:31:06
Hallo Jungs!

Vielen Dank für Eure Antworten!! Das hilft mir schon einmal sehr weiter! Das mit dem Daten auf den Bus senden muss ich tatsächlich zurücknehmen, das hatte ich erst nach meinem Post realisiert, daß das nur vom Debug kommt. Sorry für die Verwirrung!
Aber das mit der Dezimal-Angabe für das Device ist gut zu wissen, denn darauf ist wirklich nur sehr schwer zu kommen... :-)) Sehr gut, gebe es nun einen neuen Versuch mit der Hoffnung, daß das Device nun korrekt erkannt wird... Werde berichten...

Viele Grüße und nochmals besten Dank für die Hilfe!
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 01 April 2015, 01:46:33
Hmm... Habe das im XML-File auf 130 für 0x82 verändert... Das Device wird trotzdem noch nicht korrekt erkannt. Es bleibt beim HMW-Gen
eric HBW0417068 ohne Einstell- und Bedienmöglichkeiten... Auch ein Reset über den Button für eine neue ID änderte nichts, ist bei der alten ID geblieben. Auch komisch. Jetzt mach ich aber erstmal Feierabend...

Viele Grüße!
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 01 April 2015, 14:00:03
Kleiner Teilerfolg:
Nun wird der HBW-LC-Bl4 als HBW-LC-Bl4-DR HBW0417068 erkannt. Ich hatte bemerkt, daß es scheinbar irgendwie Schwierigkeiten mit dem Format der XML-Datei gab bzw. beim Speichern scheinbar irgendwas mit der Datei passierte was der CCU anscheinend nicht schmeckte, also Encodierung der Datei oder so. Jedenfalls habe ich nun nochmals eine Original-HM-Datei abgewandelt und nun wird diese zumindest erkannt. Scheinbar sind aber noch nicht alle Daten korrekt angepasst. Folgende Fragen nun:
Der Original-Aktor hat 3 Kanäle (2 Eingangskanäle und 1 Ausgangskanal). Der Homebrew-Aktor ist ja nun ein 4-fach-Aktor. Hat dieser dann nun 12 Kanäle hinterlegt?? So wie ich das gesehen hatte, sind ja keine Eingangstaster definiert wie sie sonst beim Original vorhanden wären... Wäre es nicht sinnvoll diese auch im Homebrew-Device zu haben? Wie ist es bei FHEM geführt? Für wieviele Kanäle ist das Device programmiert? Nur 4? Also pro Rolladen ein Ausgangs-Kanal für die Fahrparameter? Das heißt im Homebrew-Device gibt es keine Eingangskanäle, richtig?

Viele Grüße!!
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 01 April 2015, 15:18:22
Weiterer Erfolg!! :-)

Ich habe das XML-File weiterbearbeitet und nun wird der HBW-LC-Bl4 richtig in der CCU/LXCCU dargestellt. Es lassen sich auch Einstellungen vornehmen. Es sind jetzt 4 Ausgangskanäle definiert. Keine Eingänge. Bisher läßt sich nur Kanal 1 bedienen, also rauf, runter und stopp. Aber die anderen 3 Kanäle (2, 3, 4) reagieren nicht. Warum weiß ich nicht. Aber immerhin schon einmal ein Stückchen weiter. :-) Wenn auch das noch zufriedenstellend gelöst ist, dann kann es gerne öffentlich gemacht werden. Wem schicke ich das dann am besten für das GitHub? Thorsten?
Ich nehme an, es laufen unter FHEM alle 4 Kanäle erfolgreich, oder gab es hier auch Probleme?

Viele Grüße!
Björn

PS:
Die Levels werden auch noch nicht korrekt angezeigt... Hmm... Hoffentlich klappt das auch noch.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 03 April 2015, 09:34:03
Zitat von: Bromm am 01 April 2015, 15:18:22Wem schicke ich das dann am besten für das GitHub? Thorsten?
Ich denke, eher mal Markus. In meinem Branch gibt es das Device gar nicht. Es wäre auch gut, wenn Du dann die Übersicht im Wiki aktualisieren könntest. ...oder einfach mir sagen, dann mache ich das.

Zitat
Ich nehme an, es laufen unter FHEM alle 4 Kanäle erfolgreich, oder gab es hier auch Probleme?
Die Levels werden auch noch nicht korrekt angezeigt... Hmm... Hoffentlich klappt das auch noch.
Die Implementierung von Markus habe ich nicht ausprobiert, aber ich hatte mir mal was ähnliches zum Testen gebastelt. Im Anhang ist ein XML-File mit 5 Dimmer-Kanälen. (Ich hatte auch mal 99, das geht auch.) Vielleicht kannst Du da was abschauen.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 03 April 2015, 12:29:36
Hallo Thorsten!

Danke für das XML-File! Das hilft weiter und ebenfalls beim Erforschen der nötigen Informationen. Prima. Gut, stimmt, das GitHub bzw. der HBW-LC-Bl4-Aktor ist ja Markus Bereich, für das Wiki wäre es natürlich toll, wenn Du das dann eintragen könntest. Noch bin ich aus zeitlichen Gründen nicht weitergekommen, es wird aber natürlich die Tage weiter verfolgt...

Gibt es denn bereits einen Homebrew IO-Aktor bzw. den HMW-IO-12-FM als funktionierende Version? Mag Markus das weiterentwickeln?
Was ist mit dem 8-Tasten-Sensor HBW-Sen-SC8? Funktioniert dieser bei Euch? Ich habe dieses Sketch ausprobiert und dazu die ClickButton.h aus dem Netz geladen, das Sketch spuckt aber Fehler aus...

HBW-Sen-SC8.ino:118:1: error: too many initializers for 'ClickButton [2]'
HBW-Sen-SC8.ino: In function 'void setDefaults()':
HBW-Sen-SC8.ino:147:26: error: 'struct hmw_config_key' has no member named 'inverted'
HBW-Sen-SC8.ino:147:65: error: 'struct hmw_config_key' has no member named 'inverted'
HBW-Sen-SC8.ino:148:26: error: 'struct hmw_config_key' has no member named 'pullup'
HBW-Sen-SC8.ino:148:63: error: 'struct hmw_config_key' has no member named 'pullup'
HBW-Sen-SC8.ino: In member function 'virtual void HMWDevice::readConfig()':
HBW-Sen-SC8.ino:196:64: error: 'struct hmw_config_key' has no member named 'inverted'
HBW-Sen-SC8.ino:196:89: error: 'struct hmw_config_key' has no member named 'pullup'
Fehler beim Kompilieren.

Beste Grüße und ein schönes Osterfest!!
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 03 April 2015, 15:07:06
Hi Björn,
wenn Du ein funktionieres XML-File für den Rollo-Aktor hast, kann ich den gerne bei Github online stellen.

Es gab doch auch mal die Idee, alle Module, die schon einigermaßen funktionieren, zentral zu sammeln. Würde sich dafür nicht der Master-Branch anbieten?
@Thorsten: wer verwaltet den Master-Branch eigentlich? Machst Du das?

ZitatGibt es denn bereits einen Homebrew IO-Aktor bzw. den HMW-IO-12-FM als funktionierende Version? Mag Markus das weiterentwickeln?
Das HMW-IO-12-FM Modul hatte ich nur aus dem Branch von Thorsten kopiert, aber nie wirklich angeschaut... Weil ich für mich kein Universalmodul für In-/Output benötige, sondern ganz konkret erstmal nur Taster einlesen und Relais ansteuern will, hatte ich mich entschieden ein Modul für Eingänge (HBW-Sen-SC8) und ein Modul für die Relaisansteuerung (HBW-LC-Sw8) zu bauen.

Beide Module habe ich auch grob getestet, aber nur mit dem "alten" HM485 Master-Branch von Dirk. Ich werde jetzt in den nächsten Tagen auf die neuere Version von gevoo umsteigen und dann auch meine pm-Files anpassen. Dabei werde ich mir auch nochmal alle Module anschauen - vielleicht finde ich dabei noch ein paar Fehler.

Deine Fehlermeldungen sehen so aus, als würde auf die falsche HMWRegister.h verwiesen. In der aktuellen Datei sind die Parameter "inverted" und "pullup" angelegt und müssten eigentlich auch gefunden werden.


Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 03 April 2015, 15:31:48
Zitat von: MarkusO am 03 April 2015, 15:07:06Es gab doch auch mal die Idee, alle Module, die schon einigermaßen funktionieren, zentral zu sammeln. Würde sich dafür nicht der Master-Branch anbieten?
@Thorsten: wer verwaltet den Master-Branch eigentlich? Machst Du das?
Der master-Branch "gehört" Dirk. Ich kann aber gerne versuchen, das ganze mal in meinem Branch zu sammeln. Allerdings müsste man da auch die Abhängigkeiten analysieren. Ich glaube, es gibt auch Änderungen an der Library, die nicht in meinem Branch sind.

Zitat
Das HMW-IO-12-FM Modul hatte ich nur aus dem Branch von Thorsten kopiert, aber nie wirklich angeschaut...
Das Teil funktioniert ziemlich sicher nicht. Das waren mal meine Anfänge, aber da ich kein Original-Modul hatte war es etwas schwierig, damit weiterzumachen. Es wäre relativ einfach, ein Modul zu basteln, dass ein paar Ausgänge und ein paar Eingänge hat. Das Problem ist das Umschalten. D.h. derselbe "Pin" als Ein- oder Ausgang konfigurieren zu können.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: nelzon am 04 April 2015, 19:25:53
Zitat von: Dirk am 19 März 2015, 12:55:51
Der HM485-Daemon ersetzt quasi das HMW-LAN-GW. Damit lässt sich ein einfacher USB-RS485-Adapter als SChnittstelle an FHEM oder auch an der CCU2/LXCCU verwenden.



Verstehe ich das richtig, dass eine HM-LAN-Gateway + RS485-Gateway nicht nötig ist, wenn man einen ganz normalen (ebay) USB-RS485 anschließt?

Mein Projekt ist folgendes.. Ich bin am Neubau und möchte Homematic WIRED implentieren. Banana Pi ist schon vorhanden..mehr noch nicht. Ich werde wahrscheinlich LxCCU verwenden wollen, weil in FHEM anscheinend noch nicht alle Aktoren (hauptsächlich benötige ich erstmal HMW-IO-12-SW7-DR und  HMW-IO-12-Sw14-DR) voll unterstützt werden.

Desweiteren möchte ich 1wire verwenden. Bekommt man das interface zu kaufen? Das hat sich mich noch nicht erschlossen, trotz durchlesen dieses ganzen Threads und der wiki seiten. Ich bin kein löter und Programmierer, kann aber Schaltplan lesen und n config am Computer bearbeiten, wenn gesagt wird was wie wo.

Denn ist noch die frage, ob ich einen 16er Relaiskarte an den Bana anschließen und steuern kann? http://www.ebay.de/itm/16-Kanal-Channel-Relay-12V-Relais-Module-for-Arduino-Raspberry-Pi-Opto-couple-/320935471571

Zumannengefasst möchte ich folgendes:
Software (lxccu oder fhem)auf Banana Pi , 1wire zur Temperaturmessung, RS485 zum anbinden von Tastereingängen und Schaltaktoren.

Kann mir einer helfen Ordnung in mein Projekt zu bringen?? ;)

Dankeschööön
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 04 April 2015, 23:00:31
ZitatKann mir einer helfen Ordnung in mein Projekt zu bringen?? ;)
Ich werd's mal versuchen.

ZitatVerstehe ich das richtig, dass eine HM-LAN-Gateway + RS485-Gateway nicht nötig ist, wenn man einen ganz normalen (ebay) USB-RS485 anschließt?
Um Deinen Banana Pi (oder einen Raspberry, oder sonst was) an den RS485-Bus anzuschließen brauchst Du ein Gateway, also ein Modul, dass die Zentrale an den Bus anschließt. Ein solches Gateway kann man entweder über LAN anschließen (wie das HM-LAN-Gateway) oder über USB (wie den einfachen USB-RS485-Stick).

ZitatDesweiteren möchte ich 1wire verwenden. Bekommt man das interface zu kaufen? Das hat sich mich noch nicht erschlossen, trotz durchlesen dieses ganzen Threads und der wiki seiten. Ich bin kein löter und Programmierer, kann aber Schaltplan lesen und n config am Computer bearbeiten, wenn gesagt wird was wie wo.
In diesem Thread geht es darum, Module die das Homematic wired Protokoll verwenden, auf Basis von Arduino selbst zu bauen. Fertig aufgebaut kann man keins davon im Laden kaufen. Es kann aber sein, dass der ein oder andere mal ein paar Platinen zu viel angefertigt hat und man irgendwo ein Board bekommt, dass man nur noch bestücken muss. Ums Löten kommst Du da aber wahrscheinlich nicht herum.

ZitatDenn ist noch die frage, ob ich einen 16er Relaiskarte an den Bana anschließen und steuern kann?
Ohne den Banana Pi genau zu kennen, würde ich davon ausgehen, dass das möglich ist. Dann hätte das Ganze aber nichts mehr mit Homematic zu tun. Bei HMW werden alle Geräte über den Bus mit der Zentrale verbunden. Wenn Du die Relais direkt mit dem BananaPi steuern willst, solltest Du erst schauen, ob sowas von FHEM unterstützt wird.

ZitatZumannengefasst möchte ich folgendes:
Software (lxccu oder fhem)auf Banana Pi , 1wire zur Temperaturmessung, RS485 zum anbinden von Tastereingängen und Schaltaktoren.
Prinzipiell ist das alles kein Problem. Banana Pi mit USB-RS485-Interface und ein paar Homematic wired Geräte ist alles was du brauchst. Geräte für Tastereingänge und Schaltaktoren gibt es natürlich auch fertig zu kaufen, aber das 1wire-Gerät musst Du wahrscheinlich selber löten, oder zumindest am Breadboard zusammen stecken (Homebrew = Eigenbau).

Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 04 April 2015, 23:37:26
Hallo,

ich habe heute mal das pm-File für den 4fach-Rolloaktor auf die neue HM485-lib von gevoo angepasst. Die Grundfunktionen laufen soweit - Level setzen, Laufzeiten schreiben. Es gibt aber auch noch ein paar Probleme, die ich gerne beheben würde, wo mir aber das Wissen zum original 1fach Aktor fehlt. Vielleicht hat ja jemand das Originalgerät und kann mir weiterhelfen.

Mit was für einem Befehl antwortet das Gerät auf ein Level_Set? Acknowledge oder Info? Geht die Antwort dann nur an die Zentrale zurück oder wird ein Info-Broadcast geschickt?

Befehle, die vom Aktor als Broadcast verschickt werden, sind in FHEM auch im Logfile zu sehen. "Info"-Antworten, die als Antwort auf "Set_level" nur an die Zentrale geschickt werden, sehe ich im Logfile nicht. Es scheint so, als würden diese Botschaften nicht ankommen oder nicht ausgewertet werden. Hat jemand vielleicht einen Auszug aus einem Logfile von dem 1fach Aktor?

Gibt es bei dem 1fach Aktor einen Toggle-Befehl? In FHEM ist so ein Toggle-Befehl implementiert, beim Aufrufen wird allerdings nur 0xC8 verschickt, was dem Zielwert 100 entspricht.

In der Datei 10_HM485.pm wird in Zeile 1667 nach der Bezeichnung "HMW_" geschaut:
$deviceName = ($model ne $modelType) ? $model . $deviceName : 'HMW_' . $model . $deviceName;
Mit der Bezeichnung HBW_LC_Bl4 habe ich dadurch immer Fehlermeldungen bekommen.
@Thorsten: hat das bei Dir mit dem 1-wire funktioniert? Ich habe gesehen, dass dort noch HBW_ in dem pm-File steht.

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 05 April 2015, 15:30:10
Hallo zusammen,

bin durch Zufall über den Thread gestolpert.

Die selbstgebauten Homematic Wired Devices sehen echt interessant aus. Vor allem Preislich im vergleich zu den Kaufbaren.

Hat eigentlich schon mal jemand ein Modul in ein Hutschienengehäuse eingebaut? Fände ich mal interessant wie so was aussehen könnte bin da immer wenig kreativ was Gehäuseeinbau betrifft.

Gruß
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 05 April 2015, 19:35:54
Zitat von: MarkusO am 04 April 2015, 23:37:26In der Datei 10_HM485.pm wird in Zeile 1667 nach der Bezeichnung "HMW_" geschaut:
$deviceName = ($model ne $modelType) ? $model . $deviceName : 'HMW_' . $model . $deviceName;
Mit der Bezeichnung HBW_LC_Bl4 habe ich dadurch immer Fehlermeldungen bekommen.
@Thorsten: hat das bei Dir mit dem 1-wire funktioniert? Ich habe gesehen, dass dort noch HBW_ in dem pm-File steht.
Seltsam. Bei mir hat das bisher immer funktioniert. Ich habe es jetzt aber auch für eine Weile nicht ausprobiert.
Was genau funktioniert denn nicht?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 07 April 2015, 11:39:00
Hallo Markus!!

Danke für Deine Antwort! Ich hatte die letzten Tage leider keine Zeit mich weiter mit dem HBW-LC-Bl4 und HBW-Sen-SC8 zu beschäftigen. Das mit der register.h gucke ich mir nochmal an... Ich habe einen Original-1fach-Rolladen-Aktor, ich gucke mal bei Gelegenheit was der antwortet bei Level_Set, wenn Dir das weiterhilft. Bei dem HBW-LC-Bl4 habe ich ja auch noch das Problem, daß nur der erste Kanal reagiert und die anderen nicht und daß die Level nicht korrekt angezeigt werden.
Wenn ich den HBW-Sen-SC8 und auch den HBW-LC-Sw8 erfolgreich in Betrieb nehmen kann und die zugehörigen XML-Files laufen, dann bin ich auch schon einmal sehr zufrieden. :-) Das löst ja schon einmal viele Grundaufgaben.

@ mago0211:
ZitatHat eigentlich schon mal jemand ein Modul in ein Hutschienengehäuse eingebaut? Fände ich mal interessant wie so was aussehen könnte bin da immer wenig kreativ was Gehäuseeinbau betrifft.

Also, ich bin was das betrifft auch gerade an diesem Thema dran. Habe da auch schon recht konkrete Vorstellungen und bin grade dabei etwas zu entwickeln. Ein Modul für UP- sowie Hutschienen-Montage. Etwas das quasi universell einsetzbar und frei programmierbar ist. Auf Arduinobasis. Und eben mit dem Hauptaugenmerk auf praktischen bzw. kompatiblen Einbau in Standardeinbauorten wie UP-Dosen und Hutschiene... Weiteres folgt in näherer Zukunft, wenn es etwas spruchreifer ist...  ;)

Viele Grüße
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 07 April 2015, 23:27:21
Hi Björn,

schau Dir mal die neue Version vom HBW-LC-Bl4 im Github an (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Bl4 (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Bl4)). Da ist das Problem, dass nur der erste Kanal funktioniert, gelöst. Wenn es damit noch immer Probleme gibt, kannst Du (und alle anderen natürlich auch) ein Issue im Github erstellen. Dann sind die Probleme gesammelt und können nicht im Forum irgendwie unter gehen.
Die anderen Modulen werde ich in den nächsten Tagen auch nochmal testen.

Mir ist auch aufgefallen, dass die Bezeichnung noch nicht so richtig gewählt ist. "SC" steht ja für Shutter contact, also einen Schließerkontakt bei Fenstern. Ich werde deshalb das Modul für die Taster in HBW-PB-12 umbenennen (und auf 12 Kanäle erweitern) und ein extra Modul für Fensterkontakte erstellen (HBW-Sen-SC12).

Wenn es da was neues gibt, stelle ich es direkt bei Github online.

ZitatHat eigentlich schon mal jemand ein Modul in ein Hutschienengehäuse eingebaut? Fände ich mal interessant wie so was aussehen könnte bin da immer wenig kreativ was Gehäuseeinbau betrifft.
Für die Aktoren werde ich solche Gehäuse verwenden:
http://www.reichelt.de/CB-HUTKIT-9/3/index.html?&ACTION=3&LA=446&ARTICLE=133941&artnr=CB+HUTKIT+9 (http://www.reichelt.de/CB-HUTKIT-9/3/index.html?&ACTION=3&LA=446&ARTICLE=133941&artnr=CB+HUTKIT+9)
Da passt dann ein 8-fach Relaisboard zusammen mit einem kleinen HBW-Modul rein.

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 08 April 2015, 01:47:54
Hi Markus!

Prima!! Danke! Ich werde es die Tage hoffentlich testen können... Ich gebe Dir Feedback!!
Freue mich auch auf die anderen überarbeiteten Module... Werde, so wie es mir die Zeit zulässt, dann auch hierfür die XMLs erstellen und testen.

Viele Grüße!!
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 08 April 2015, 22:29:53
Hallo Markus!

Kleines Feedback: Ich habe nun nochmal den 4-fach-Rolladenaktor mit Deinen neuen Dateien getestet. Nun, es reagieren nun alle 4 Kanäle (bzw. alle 8 Relais), aber nicht wie erwartet. Es scheint immer noch Probleme mit dem Level zu geben. Die Fahrzeiten werden zwar wie in der CCU/LXCCU unter Einstellungen eingetragen ins EEPROM übertragen, doch beim Ausführen eine AUF oder ZU werden diese Zeiten nicht eingehalten. Fahrzeit vorgegeben zB 200 Sekunden (testweise), Relais ziehen aber nur ca. 3 Sekunden an.

Hier einmal ein Mitschnitt aus dem Terminal:

State:al: 0
- Actual: 0
State: RELAY_OFF - Time: 10514760 - Target: 1 - Actual: 1
State: RELAY_OFF - Time: 10521171 - Target: 0 - Actual: 0
Huhu
Channel 0
TimeTopBottom: 2000
TimeBottomTop: 2000
TimeTurnAround: 15
Channel 1
TimeTopBottom: 1000
TimeBottomTop: 1000
TimeTurnAround: 15
Channel 2
TimeTopBottom: 2000
TimeBottomTop: 2000
TimeTurnAround: 15
Channel 3
TimeTopBottom: 2000
TimeBottomTop: 2000
TimeTurnAround: 15
Sending ACK or BroadcastF8
Sending
FF:FF:FF:FF:F8:00:06:5D:2C:12:41:00:82:00:03:06:48:42:57:30:34:31:37:30:36:38:82:C6:00:State: RELAY_OFF - Time: 1175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 1175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 1175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 1175 - Target: 0 - Actual: 0

Receiving
FD:00:06:5D:2C:18:00:00:00:01:05:78:00:02:BF:8C:parsing from loop...Requested Position: 1
Position unknown. Moving to reference position.

Sending
00:00:00:01:18:00:06:5D:2C:05:69:00:02:81:D2:00:
Receiving
FD:00:06:5D:2C:19:00:00:00:01:02:83:00:parsing from ackwait Received ACKState: WAIT - Time: 19038 - Target: 0 - Actual: 100
00:State: TURN_AROUND - Time: 19238 - Target: 0 - Actual: 100
State: MOVE - Time: 19239 - Target: 0 - Actual: 100
State: RELAY_OFF - Time: 21175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 21175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 21175 - Target: 0 - Actual: 0
Reference position reached. Actual position is known now
Sending ACK or BroadcastF8
Sending
FF:FF:FF:FF:F8:00:06:5D:2C:06:69:00:00:00:9A:0A:State: STOP - Time: 23631 - Target: 0 - Actual: 0
Reference position reached. Moving to target position now.
Requested Position: 1
00:State: WAIT - Time: 23740 - Target: 1 - Actual: 0
State: TURN_AROUND - Time: 23940 - Target: 1 - Actual: 0
State: MOVE - Time: 25440 - Target: 1 - Actual: 0
Sending ACK or BroadcastF8
Sending
FF:FF:FF:FF:F8:00:06:5D:2C:06:69:00:00:01:8A:08:State: STOP - Time: 27440 - Target: 1 - Actual: 1
00:State: RELAY_OFF - Time: 27640 - Target: 1 - Actual: 1

Receiving
FD:00:06:5D:2C:1A:00:00:00:01:05:78:00:02:33:B4:parsing from loop...Requested Position: 1

Sending
00:00:00:01:38:00:06:5D:2C:05:69:00:02:C2:42:00:
Receiving
FD:00:06:5D:2C:19:00:00:00:01:02:83:00:parsing from ackwait Received ACK00:
Receiving
FD:00:06:5D:2C:1C:00:00:00:01:05:78:00:00:97:FA:parsing from loop...Requested Position: 0

Sending
00:00:00:01:58:00:06:5D:2C:05:69:00:00:26:F6:00:
Receiving
FD:00:06:5D:2C:19:00:00:00:01:02:83:00:parsing from ackwait Received ACKState: WAIT - Time: 36945 - Target: 0 - Actual: 1
00:State: TURN_AROUND - Time: 37145 - Target: 0 - Actual: 1
State: MOVE - Time: 38645 - Target: 0 - Actual: 1
State: RELAY_OFF - Time: 41175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 41175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 41175 - Target: 0 - Actual: 0
Sending ACK or BroadcastF8
Sending
FF:FF:FF:FF:F8:00:06:5D:2C:06:69:00:00:00:9A:0A:State: STOP - Time: 41645 - Target: 0 - Actual: 0
00:State: RELAY_OFF - Time: 41845 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 61175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 61175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 61175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 61845 - Target: 0 - Actual: 0


Mit der Anzeige des Rollolevels in der CCU/LXCCU hakt es auch noch etwas. In der .pm-Datei habe ich unter Channel bei Conversion für Blind.level einen angegebenen Factor = 2 entdeckt und in der XML-Datei von ursprünglich 200 auf 2 angepasst.

<parameter id="LEVEL" operations="read,write,event" control="BLIND.LEVEL"><logical type="float" default="0.0" min="0.0" max="1.0" unit="100%"/><physical type="integer" interface="command" value_id="LEVEL"><set request="LEVEL_SET"/><get request="LEVEL_GET" response="INFO_LEVEL"/><event frame="INFO_LEVEL"/></physical><conversion type="float_integer_scale" factor="2"/></parameter>

Scheint aber nicht die Ursache für das Problem gewesen zu sein...  :-[

Was mir noch aufgefallen ist, ist daß es durch die verschiedenen Versionen der Libs für die Sketches der einzelnen Module zu Problemen innerhalb der Arduino IDE kommt. Sprich, eigentlich sollten ja HMWDebug.cpp/.h, HMWModule.cpp/.h und HMWRS485.cpp/.h für alle Sketches gleich sein, aber dies führt zu Problemen beim Kompilieren, da es hier scheinbar noch unterschiedliche Versionen gibt. Ebenfalls kann es hier dann auch zu Problemen mit der HMWRegister.h kommen. Daher verwalte ich nun also nur einen jeweiligen Homebrew-Aktor/Sensor einzeln in der Arduino IDE. Dann klappt es soweit. Nur zur Info, falls hiermit noch jemand Probleme haben sollte.

Gerne will ich auch noch den HBW-Sen-SC8 bzw. bald neu HBW-Sen-PB8/12 und HBW-LC-Sw8 ausprobieren, aber hierzu muß ich dann noch die XML bearbeiten bzw. erstellen.


Viele Grüße und einen schönen Abend!
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 09 April 2015, 00:11:49
Hallo Björn,

das Problem scheint relativ einfach zu sein. Zum besseren Verständnis, hier die Erklärung zur Debug-Ausgabe:
Requested Position: 1
Die Sollposition ist 1, wobei 1 nicht auf oder zu bedeutet, sondern 1%. Das erklärt auch schon, warum der Aktor nur so kurz fährt. Ich denke, man müsste das XML bzw. pm-File irgendwie so anpassen, dass bei "zu" 100 als Sollwert geschickt wird und nicht 1.

Trotzdem hier noch die Erklärung des weiteren Ablaufs:
State: WAIT - Time: 23740 - Target: 1 - Actual: 0
Das Relais für die Richtung wird geschaltet und 200ms gewartet, damit das Relais sicher geschaltet hat

State: TURN_AROUND - Time: 23940 - Target: 1 - Actual: 0
Das "Ein/Aus"-Relais wird geschaltet. Der Raffstore fängt an sich zu drehen...

State: MOVE - Time: 25440 - Target: 1 - Actual: 0
...und bewegt sich dann exakt 1500ms später in die entsprechende Richtung (1.5sek über das Webfrontend programmiert)

State: STOP - Time: 27440 - Target: 1 - Actual: 1
Das "Ein/Aus"-Relais schaltet 2000ms später wieder ab. Die 2sek für 1% passen zu den 200sek, die über das Webfrontend für den kompletten Fahrweg programmiert wurden.

State: RELAY_OFF - Time: 27640 - Target: 1 - Actual: 1
Damit das Richtungsrelais nicht permanent bestromt ist, wird es 200ms später abgeschaltet


Nach dem Einschalten des Moduls ist die Position des Rollos natürlich noch unbekannt. Bei der ersten Anforderung wird das Rollo daher für die maximale Fahrzeit angesteuert, um die Endlage sicher zu erreichen. Wenn die erste Sollposition nicht 0 oder 100 ist (wie in Deinem Fall), wird zunächst eine der Endlagen sicher angefahren, um eine Referenzposition zu haben und von dort aus dann erst die Zielposition angefahren. Also nicht irritieren lassen, das ist so gewollt  :D

Zitat
Was mir noch aufgefallen ist, ist daß es durch die verschiedenen Versionen der Libs für die Sketches der einzelnen Module zu Problemen innerhalb der Arduino IDE kommt. Sprich, eigentlich sollten ja HMWDebug.cpp/.h, HMWModule.cpp/.h und HMWRS485.cpp/.h für alle Sketches gleich sein, aber dies führt zu Problemen beim Kompilieren, da es hier scheinbar noch unterschiedliche Versionen gibt. Ebenfalls kann es hier dann auch zu Problemen mit der HMWRegister.h kommen. Daher verwalte ich nun also nur einen jeweiligen Homebrew-Aktor/Sensor einzeln in der Arduino IDE. Dann klappt es soweit. Nur zur Info, falls hiermit noch jemand Probleme haben sollte.
So mache ich das mittlerweile auch. Habe es auch nicht geschafft, die Lib komplett gleich zu halten...


Zitat
In der Datei 10_HM485.pm wird in Zeile 1667 nach der Bezeichnung "HMW_" geschaut:

Code: [Auswählen]

      $deviceName = ($model ne $modelType) ? $model . $deviceName : 'HMW_' . $model . $deviceName;

Mit der Bezeichnung HBW_LC_Bl4 habe ich dadurch immer Fehlermeldungen bekommen.
@Thorsten: hat das bei Dir mit dem 1-wire funktioniert? Ich habe gesehen, dass dort noch HBW_ in dem pm-File steht.
ZitatSeltsam. Bei mir hat das bisher immer funktioniert. Ich habe es jetzt aber auch für eine Weile nicht ausprobiert.
Was genau funktioniert denn nicht?

@Thorsten:
Der Name scheint tatsächlich nicht das Problem gewesen zu sein. Ich habe die folgende Fehlermeldung bekommen und daraus geschlossen, dass es mit den Namen zusammen hängt. Nach dem Ändern auf "HMW_" hat es keine Probleme mehr gegeben. Jetzt wollte ich den Fehler nochmal nachstellen, habe die Bezeichnung wieder zurück auf "HBW_" geändert aber die Fehlermeldung kommt nicht wieder... Seltsam, aber egal, Hauptsache es läuft jetzt.


Viele Grüße
Markus



Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 09 April 2015, 09:55:20
Zitat von: Bromm am 08 April 2015, 22:29:53
Was mir noch aufgefallen ist, ist daß es durch die verschiedenen Versionen der Libs für die Sketches der einzelnen Module zu Problemen innerhalb der Arduino IDE kommt.
Das war eigentlich nie für die Arduino-IDE gedacht. Ich habe das von Anfang an mit Eclipse gebaut. Die Arduino-IDE finde ich für sowas ziemlich grausam, da man nur eine Stufe von Abhängigkeiten hat und nicht einmal zur Definition einer Funktion/Methode springen kann. Erstaunlich, dass man das trotzdem mit der IDE hinbekommen kann.
ZitatSprich, eigentlich sollten ja HMWDebug.cpp/.h, HMWModule.cpp/.h und HMWRS485.cpp/.h für alle Sketches gleich sein, aber dies führt zu Problemen beim Kompilieren, da es hier scheinbar noch unterschiedliche Versionen gibt.
Da gibt es wahrscheinlich wirklich Unterschiede. Wenn ich wieder zuhause bin muss ich mich vielleicht mal dransetzen und das ganze analysieren. Vielleicht können wir die Versionen mal zusammenführen. Es kann dann aber gut sein, dass man alle Devices anpassen muss. Außerdem wird man die Callbacks entweder überladen müssen oder wir brauchen da etwas "generischere" Schnittstellen.
Zitat
Ebenfalls kann es hier dann auch zu Problemen mit der HMWRegister.h kommen.
Ja, das ist noch so ein Punkt, wo es mit der Arduino-IDE schwierig wird. Ich verwende allerdings die HMWRegister.h nicht wirklich. (Oder?)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 09 April 2015, 22:46:59
Hallo Markus und Thorsten!

Vielen Dank für Euer Feedback!! Die Aufschlüsselung des Debugs ist auch sehr gut!! Hatte schon eine etwaige Vorstellung, was die Statusmeldungen betrifft, aber so ist es noch mal schön klar! Prima, Danke dafür!! Auch bei der 1 als Level war ich etwas stutzig, denn tatsächlich sieht man ja bei der Initialfahrt auch eine 100 stehen... Vielleicht liegt doch in folgender Code-Zeile der Hund begraben (so momentan auf der CCU/LXCCU):

<code>
<parameter id="LEVEL" operations="read,write,event" control="BLIND.LEVEL"><logical type="float" default="0.0" min="0.0" max="1.0" unit="100%"/><physical type="integer" interface="command" value_id="LEVEL"><set request="LEVEL_SET"/><get request="LEVEL_GET" response="INFO_LEVEL"/><event frame="INFO_LEVEL"/></physical><conversion type="float_integer_scale" factor="2"/></parameter>
</code>

Hier ist als maximaler Wert 1.0 angegeben. Mal sehen was passiert wenn ich den auf 100 setze. Dachte, hier ist mit 1.0 gleich 100% definiert. Ich bin leider zur Zeit nicht zu Hause, kann es daher nicht gleich testen...

Hier mal im Original-Code beispielsweise auf 100.0 gesetzt...:
<code>
<paramset type="VALUES" id="hmw_blind_ch_values">
            <parameter id="LEVEL" operations="read,write,event" control="BLIND.LEVEL">
               <logical type="float" default="0.0" min="0.0" max="100.0" unit="100%"/>
               <physical type="integer" interface="command" value_id="LEVEL">
                  <set request="LEVEL_SET"/>
                  <get request="LEVEL_GET" response="INFO_LEVEL"/>
                  <event frame="INFO_LEVEL"/>
               </physical>
               <conversion type="float_integer_scale" factor="200"/>
            </parameter>
</code>

Es wundert mich allerdings nur, da im Original-HM-1fach-Akor hier eine 1.0 im XML-File steht. Und im .pm-File für den 4-fach-Aktor ja auch eine 1.0.
Allerdings gibt es Unterschiede im conversion-Part: Im Original-HM-XML-File ist hier ein Wert von "200" eingetragen, wie oben zu sehen (<conversion type="float_integer_scale" factor="200"/>). Ich hatte ihn auf dem .pm-File basierend auf 2 geändert, wie noch eins weiter oben im Code zu sehen... Bin mir nicht sicher in wie fern sich das auswirkt... Testen kann ich ja leider erst zu Hause, aber mit "200" hatte ich, glaube ich mich zu entsinnen, auch die oben beschriebenen kurzen Fahrzeiten und bin erst bei der Fehlersuche auf diesen Unterschied gestoßen, weshalb ich hier auf "2" setzte...
Ansonsten sehe ich im Moment keine Stellen im XML- oder pm-File wo der Fehler herrühren könnte. Außer, daß es eventuell eine Stelle im Sketch gibt wo der Wert anders als erwartet empfangen wird? Sollte ja aber nicht der Fall sein... Komisch...

Hmm... Mit der Arduino IDE komme ich soweit recht gut zurecht... :-) Aber Eclipse sieht auch interessant aus... ;-)

Viele Grüße!!
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 12 April 2015, 02:54:18
Hallo Jungs!

Bin man wieder nach Hause gekommen und habe getestet...

Ich habe
<logical type="float" default="0.0" min="0.0" max="1.0" unit="100%"/>
auf
<logical type="float" default="0.0" min="0.0" max="100.0" unit="100%"/>
geändert und den conversion factor wieder auf 200 gesetzt:
<conversion type="float_integer_scale" factor="200"/>

Nun werden die richtigen Prozente an den Aktor übermittelt und die Relais schalten wie gewünscht... Kleiner Ausschnitt:
Receiving
FD:00:06:5D:2C:1E:00:00:00:01:05:78:00:C8:5A:4A:parsing from loop...Requested Position: 100

Sending
00:00:00:01:78:00:06:5D:2C:05:69:00:C8:24:EE:00:
Receiving
FD:00:06:5D:2C:19:00:00:00:01:02:83:00:parsing from ackwait Received ACKState: WAIT - Time: 718921 - Target: 100 - Actual: 50
00:State: TURN_AROUND - Time: 719121 - Target: 100 - Actual: 50
State: MOVE - Time: 720621 - Target: 100 - Actual: 50
State: RELAY_OFF - Time: 721175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 721175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 721175 - Target: 0 - Actual: 0
Sending ACK or BroadcastF8
Sending
FF:FF:FF:FF:F8:00:06:5D:2C:06:69:00:00:64:BA:CE:State: STOP - Time: 731621 - Target: 100 - Actual: 100
00:State: RELAY_OFF - Time: 731821 - Target: 100 - Actual: 100
State: RELAY_OFF - Time: 741175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 741175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 741175 - Target: 0 - Actual: 0

Receiving
FD:00:06:5D:2C:18:00:00:00:01:05:78:00:96:6E:B6:parsing from loop...Requested Position: 75

Sending
00:00:00:01:18:00:06:5D:2C:05:69:00:96:50:E8:00:
Receiving
FD:00:06:5D:2C:19:00:00:00:01:02:83:00:parsing from ackwait Received ACKState: WAIT - Time: 751040 - Target: 75 - Actual: 100
00:State: TURN_AROUND - Time: 751240 - Target: 75 - Actual: 100
State: MOVE - Time: 752740 - Target: 75 - Actual: 100
Sending ACK or BroadcastF8
Sending
FF:FF:FF:FF:F8:00:06:5D:2C:06:69:00:00:4B:6A:94:State: STOP - Time: 757740 - Target: 75 - Actual: 75
00:State: RELAY_OFF - Time: 757940 - Target: 75 - Actual: 75


Aber leider werden die Level noch nicht korrekt zur Anzeige gebracht. Ändere ich den conversion factor zB auf "2" statt "200", dann werden zB 7500% statt 75% angezeigt. Aber das "Rollo" zeigt nicht den richtigen Stand an. Das ist quasi immer heruntergefahren und zeigt somit optisch 0% an. Woran das liegt? Eventuell liegt das irgendwie evtl am Sketch? Überträgt die CCU nicht normalerweise 1.0 für 100%? Was für Werte erwartet das Sketch? 100.0 für 100%? Irgendwo hier muß das Problem ja bestehen?
Auf jeden Fall lassen sich die Relais schon einmal wie gewünscht bedienen, aber es hapert nun noch an der korrekten Level-Anzeige in der CCU/LXCCU... Die kommende Woche werde ich leider zeitlich nicht zu weiterem kommen. Wollte das aber schon einmal als Feedback in den Raum werfen, vielleicht hat ja noch jemand eine Idee?

Viele Grüße!!
Björn


PS:
Nach Neustart erscheinen die aktuellen Level korrekt. Aber nach einer erneuten Bedienung ist immer 0% angezeigt und im Folgenden bleibt es dann auch bei der Anzeige von 0%. Auch wenn der Befehl mit dem entsprechenden Level korrekt am Aktor ausgeführt wird, so wird der rückgemeldete Level weiterhin bei 0% angezeigt...
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 12 April 2015, 11:01:41
Hi,
ich kann das momentan nicht mal schnell testen, aber ich glaube mich daran zu erinnern, dass die FHEM-Implementierung hier nicht kompatibel zu dem ist, was die CCU braucht.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 12 April 2015, 20:34:42
Hi,
ich versuche mal was zu den Conversion Factors etc. zu sagen. Was von der CCU bzw. dem Device in der Nachricht übertragen werden sollte ist ein Wert zwischen 0 und 200. Die CCU mach dann daraus 0% bis 100%. Das steht auch so im XML (das ist vom Original-Dimmer oder Rollo-Aktor):

   <frame id="LEVEL_SET" direction="to_device" type="#x" channel_field="10">
  <parameter type="integer" index="11.0" size="1.0" param="LEVEL"/>
</frame>
[...]
   <logical type="float" unit="100%" default="0.0" max="1.0" min="0.0"/>
[...]
   <conversion type="float_integer_scale" factor="200"/>

So funktioniert das auch bei meinen Experimenten.
Ich interpretiere das in etwa so: Der Befehl "LEVEL_SET" hat als Parameter einen integer-Wert der Größe 1. Anders gesagt 1 Byte. Was der Aktor dann wirklich daraus macht ist seine Sache. Weiter unten steht dann, dass der Wert als float aufgefasst wird mit der "Einheit" 100% (also nicht %, sondern 100%). Der Wert selbst bewegt sich zwischen 0 und 1, also mit Einheit zwischen 0% und 100%.
Die Konversion erfolgt per Multiplikation mit 200. Also 100% * 200 = 1.0 * 200 = 200.

Die FHEM-Implementierung scheint damit nicht so ganz umgehen zu können. Stattdessen braucht man im .pm-File so etwas:

"conversion" => {
"factor" => 2,
"type" => "float_integer_scale"
},
"logical" => {
"default" => 0,
        "max" => 100,
"min" => 0,
        "type" => "int",
"unit" => "%"
},

Mit float und der "Einheit" 100% funktioniert es in FHEM anscheinend nicht.
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: hglaser am 12 April 2015, 21:15:34
Hallo Thorsten , Hallo Björn

Leider hat gevoo in seiner Imlemetation sehr viele Gerätenamen "hardcodiert". Z.B. steht in der 00_HM485.pm in der sub HM485_Set:
} elsif ( $cmd eq 'level') {
if ( uc( $deviceKey) eq 'HMW_LC_BL1_DR' or uc( $deviceKey) eq 'HMW_LC_DIM1L_DR') {
$value = $value / 100;
HM485::Util::logger( 'HM485_Set', 3, 'set ' . $name . ' level ' . $value);
}

Somit können die Homebrew Geräte nicht richtig funktionieren, da hier nur der 'HMW_LC_BL1_DR und HMW_LC_DIM1L_DR breücksichtigt wird und nicht in die spezifischen Device.pms nachgesehen wird. Mir hat das auch schon einiges an Kopfzerbrechen bereitet und den ganzen Schmarrn neugeschrieben.

Grüße Harald
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 12 April 2015, 21:46:15
Zitat von: honk am 12 April 2015, 21:15:34
Leider hat gevoo in seiner Imlemetation sehr viele Gerätenamen "hardcodiert". Z.B. steht in der 00_HM485.pm in der sub HM485_Set:
Ok, dann ist etwas verständlicher, dass die CCU mit unseren Kreationen oft kein Problem hat, aber FHEM schon.
Das sollte sich ändern...
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 12 April 2015, 22:46:33
Hallo Zusammen!

Besten Dank für Eure Antworten!! Ich komme leider erst wohl übernächste Woche dazu hier aktiv weiter zu agieren... Aber das klingt zumindest als wäre es nicht unlösbar... ;-) Ich versuche es dann weiter den 4-fach-Aktor noch besser in die CCU/LXCCU zu integrieren bzw. das XML-File zu optimieren oder den Sketch vom Aktor anzupassen. Immerhin funktioniert der Aktor ja schon, wenn auch die Rückmeldung noch nicht korrekt in der CCU/LXCCU dargestellt wird.

Beste Grüße!!
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: T.ihmann am 13 April 2015, 16:59:24
Zitat von: Bromm am 07 April 2015, 11:39:00
Also, ich bin was das betrifft auch gerade an diesem Thema dran. Habe da auch schon recht konkrete Vorstellungen und bin grade dabei etwas zu entwickeln. Ein Modul für UP- sowie Hutschienen-Montage. Etwas das quasi universell einsetzbar und frei programmierbar ist. Auf Arduinobasis. Und eben mit dem Hauptaugenmerk auf praktischen bzw. kompatiblen Einbau in Standardeinbauorten wie UP-Dosen und Hutschiene... Weiteres folgt in näherer Zukunft, wenn es etwas spruchreifer ist...  ;)

Hallo Bromm,

das klingt ja interessant. Genau das, was ich fuer mein Neubauprojekt suche. Wenn Du naehere Infos hast, koenntest Du die hier posten. Wenn Du Unterstuetzung brauchst (Testen, etc.), kann ich gerne helfen. Arduino Vorkenntnisse sind vorhanden.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 15 April 2015, 16:47:50
Hallo T.ihmann!

Freue mich wenn es Interesse an dem Projekt gibt! :-) Sowie ich es in einen spruchreifen Zustand bekommen habe, werde ich es hier vorstellen. Bei Bedarf komme ich gerne auf das Angbot zurück. Es gibt noch eine weitere Entwicklung, eventuell könnten auch beide Projekte zusammengefasst werden. Aus zeitlichen Gründen geht es bei mir erst in ca 2 Wochen weiter. Dann will ich die Entwicklung aber fokussiert vorantreiben, da ich selbst auch bald die Module verbauen will. Sie sollen mit den hier vorhandenen Homebrew Devices kompatibel sein. Natürlich sind sie es auf Grund der Arduinobasis auch für jedwede andere Projekte und eigene Entwicklungen... ;-) Ziel ist Einbaufähigkeit in Standardumgebungen wie UP und Hutschiene. Dabei möglichst alle Funktionen abdeckend und günstig im Preis. Weitere Details werden folgen.

Beste Grüße
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: T.ihmann am 15 Juni 2015, 12:25:11
Hallo Björn,

gibt es bei Dir schon etwas Neues ?  Brauchst Du vielleicht Hilfe.

Lg Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 02 Juli 2015, 22:14:09
Zitat von: Bromm am 03 April 2015, 12:29:36
Gibt es denn bereits einen Homebrew IO-Aktor bzw. den HMW-IO-12-FM als funktionierende Version? Mag Markus das weiterentwickeln?
Was ist mit dem 8-Tasten-Sensor HBW-Sen-SC8? Funktioniert dieser bei Euch? Ich habe dieses Sketch ausprobiert und dazu die ClickButton.h aus dem Netz geladen, das Sketch spuckt aber Fehler aus...

Hallo Björn,

stehe vor einem ähnlichen Problem. Ich habe versucht die HBW-Sen-SC8.cpp/ino mit der Arduino IDE zu Kompilieren. Leider bekomme ich von der IDE einen Fehler.


HBW-Sen-SC8.ino:78:25: fatal error: ClickButton.h: No such file or directory
compilation terminated.
Fehler beim Kompilieren.


Wo finde ich die ClickButton.h ? Ich fühle mich blind   :(

Danke und Gruß
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 02 Juli 2015, 22:27:26
Zitat von: mago0211 am 02 Juli 2015, 22:14:09
Wo finde ich die ClickButton.h ? Ich fühle mich blind   :(
Hier vielleicht: https://code.google.com/p/clickbutton/ (https://code.google.com/p/clickbutton/)
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 04 Juli 2015, 09:47:25
Danke Thorsten für den Link  :D

Frage mich gerade warum ich zu blöd zum Googlen bin.  :-X

Dann werd ich mal weitermachen und versuchen das Ding an meinen Bus zu bekommen.  ::)

Gruß
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 04 Juli 2015, 15:30:22
Hallo nochmal.

Ich brauche leider noch mal Hilfe  :( .

Versuche gerade den hbw_sen_sc8 (8 Fach Tasterschnittstelle) nachzubauen.

Dazu habe ich meinen Arduino Nano per Arduino IDE mit der Version von Markus aus GitHub geflasht.
Das File hbw_sen_sc8.pm habe ich nach \FHEM\lib\HM485\Devices kopiert und Fhem neugestartet.

Dann habe ich den Arduino an mein vorhandenes Bussystem mit Original Homematic-Wired-Lan-Gateway angeschlossen.

PIN D1 (TX) an Eingang A des LAN-Gateways
PIN D0 (RX) an Eingang B des LAN-Gateways


Leider legt FHEM kein neues Device an. Wenn ich auf dem hbw_sen_sc8 einen Taster Drücke Masse mit PIN A1 geschlossen. Im FHEM log sehe ich mit Verbose 5 das auch Daten ankommen:
2015.07.04 15:08:44 5: HM485_LAN dispatch ��e�����B���K
2015.07.04 15:08:44 5: SW: fd0d5453c842ffffff1e0000000168
2015.07.04 15:08:44 3: HM485_LAN: TX: (84) I[3](0,F,B)(1E) 00000001 -> 42FFFFFF [3] 68(h)
2015.07.04 15:08:45 5: HM485_LAN dispatch ��e�����B���K
2015.07.04 15:08:45 5: SW: fd0d5553c842ffffff180000000168
2015.07.04 15:08:45 3: HM485_LAN: TX: (85) I[0](0,F,B)(18) 00000001 -> 42FFFFFF [3] 68(h)
2015.07.04 15:08:45 5: HM485_LAN dispatch ��e�����B���K
2015.07.04 15:08:45 5: SW: fd0d5653c842ffffff1a0000000168
2015.07.04 15:08:45 3: HM485_LAN: TX: (86) I[1](0,F,B)(1A) 00000001 -> 42FFFFFF [3] 68(h)


Leider verstehe ich nicht warum das Device nicht angelegt wird in FHEM. Habe ich was vergessen?
Die HM485 Version ist noch die alte von Dirk da ich mit der aktuellen von gevoo noch einige Probleme habe. Liegt es vielleicht daran?

Danke und Gruß
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 04 Juli 2015, 16:08:20
Zitat von: mago0211 am 04 Juli 2015, 15:30:22
PIN D1 (TX) an Eingang A des LAN-Gateways
PIN D0 (RX) an Eingang B des LAN-Gateways
Mach das lieber nicht, da könnte was kaputt gehen.
Es fehlt Dir irgendein RS485-Buskoppler, z.B. ein MAX487.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 04 Juli 2015, 16:34:07
Ah Ok,

Danke für deine Antwort.
Gibt es eigentlich irgendwo einen vollständigen Schaltplan? Oder Anleitung für die Module?
Im Moment muss man sich alles zusammensammeln um auf was zu kommen und man übersieht leicht was so wie ich mit dem MAX487 Baustein.

Gruß
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 04 Juli 2015, 18:30:07
Zitat von: mago0211 am 04 Juli 2015, 16:34:07Gibt es eigentlich irgendwo einen vollständigen Schaltplan? Oder Anleitung für die Module?
Im Moment muss man sich alles zusammensammeln um auf was zu kommen und man übersieht leicht was so wie ich mit dem MAX487 Baustein.
Tja, leider ist das alles noch in Entwicklung und es ist noch nicht alles beschrieben.
Ich denke aber, dass Du gerne das Wiki ergänzen kannst.
Die Pinbelegung hängt außerdem vom Device ab. Die für das HBW-LC-Sw8 kannst Du hier finden: https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Sw8 (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Sw8)
Ansonsten gibt's hier eine Liste: http://www.fhemwiki.de/wiki/HomeMatic_Wired (http://www.fhemwiki.de/wiki/HomeMatic_Wired) (nach unten scrollen). Die Liste hat ein paar Links, so dass man das, was da ist, zumindest finden kann.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 05 Juli 2015, 15:10:38
Zitat von: Thorsten Pferdekaemper am 04 Juli 2015, 18:30:07
Tja, leider ist das alles noch in Entwicklung und es ist noch nicht alles beschrieben.

Kein Problem, das ist nicht weiter schlimm es ist halt ein Bastelprojekt. Solange ich hier Hilfe bekomme wenn was nicht geht ist alles gut.

Zitat von: Thorsten Pferdekaemper am 04 Juli 2015, 18:30:07
Ich denke aber, dass Du gerne das Wiki ergänzen kannst.

Wenn ich es schaffe das Ding nachzubauen werde ich versuchen das Zeitlich hinzubekommen.

Danke und Gruß
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 05 Juli 2015, 19:09:05
Hi,
ich bin gerade selbst mal wieder am Basteln. Ich habe dabei fest gestellt, dass die DEBUG-Versionen der Homebrew-Geräte nicht mit dem neusten FHEM-Stand zusammenarbeiten. Ich glaube, dass das irgendwie am Timing liegt. Ich werde das auch mal im Wired-Thread besprechen.
Das ganze tritt dann auf, wenn RS485 über Hardware Serial (Pin 0/1) geht und der Debug-Stream per SoftwareSerial aufgemacht wird. Es kann sein, dass es auch nur bei 8MHz-Prozessoren Probleme macht.
Also, falls es Probleme gibt, dann sollte das im Sketch stehen:

#define DEBUG_VERSION DEBUG_NONE

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 08 Juli 2015, 13:01:31
Hallo,

ich möchte mit dem Arduino Nano auch versuchen ein Modul nachzubauen.
Ich möchte, aber anstatt RS485 das Modul über Ethernet an fhem anbinden.

Als Ethernet Modul habe ich an das "Mini W5100 LAN Ethernet Shield Network Modul" gedacht
http://www.ebay.de/itm/New-Mini-W5100-LAN-Ethernet-Shield-Network-Module-board-Fur-Arduino-DE-TE230-/261950470314?pt=LH_DefaultDomain_77&hash=item3cfd76f8aa

Hat sich schon mal jemand mit Ethernet beim Arduino befasst? Könnte das was ich vorhabe funktionieren?

In der DevIo.pm steht in der sub DevIo_OpenDev($$$) folgendes.
Ist dies eine normale TCP Verbindung?

my $timeout = $hash->{TIMEOUT} ? $hash->{TIMEOUT} : 3;
my $conn = IO::Socket::INET->new(PeerAddr => $dev, Timeout => $timeout);
if($conn) {
delete($hash->{NEXT_OPEN});
$conn->setsockopt(SOL_SOCKET, SO_KEEPALIVE, 1) if(defined($conn));
} else {



In https://www.arduino.cc/en/reference/ethernet habe ich unter "Server class" das folgende Beispiel gefunden:

#include <Ethernet.h>
#include <SPI.h>

// the media access control (ethernet hardware) address for the shield:
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED }; 
//the IP address for the shield:
byte ip[] = { 10, 0, 0, 177 };   
// the router's gateway address:
byte gateway[] = { 10, 0, 0, 1 };
// the subnet:
byte subnet[] = { 255, 255, 0, 0 };


// telnet defaults to port 23
EthernetServer server = EthernetServer(23);

void setup()
{
  // initialize the ethernet device
  Ethernet.begin(mac, ip, gateway, subnet);

  // start listening for clients
  server.begin();
}

void loop()
{
  // if an incoming client connects, there will be bytes available to read:
  EthernetClient client = server.available();
  if (client) {
    // read bytes from the incoming client and write them back
    // to any clients connected to the server:
    server.write(client.read());
  }
}


Hier wird ganz unten "client.read()" verwendet obwohl es unter der "Server class" kein read gibt.
Dies verstehe ich nicht.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 08 Juli 2015, 18:01:27
Zitat von: Ralf9 am 08 Juli 2015, 13:01:31
ich möchte mit dem Arduino Nano auch versuchen ein Modul nachzubauen.
Ich möchte, aber anstatt RS485 das Modul über Ethernet an fhem anbinden.
Hi,
dann bist Du aber hier im falschen Bereich des Forums. Wenn es per Ethernet geht, dann ist es nicht mehr Homematic.
Schau mal bei "Bastelecke" oder "Sonstiges". Interessante Stichworte für Dich sind "Firmata" und "HTTPMOD".
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 08 Juli 2015, 18:23:01
Zitat von: Thorsten Pferdekaemper am 08 Juli 2015, 18:01:27
Hi,
dann bist Du aber hier im falschen Bereich des Forums.

Ich möchte schon das Homematic wired Protokoll verwenden, nur nicht über den RS485 Bus.
Das Modul soll sich dann in fhem wie ein normales wired Modul verhalten.

Nachtrag:
Ich habe die Frage auch in der  Bastelecke gestellt.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 09 Juli 2015, 19:00:41
Zitat von: Ralf9 am 08 Juli 2015, 18:23:01
Ich möchte schon das Homematic wired Protokoll verwenden, nur nicht über den RS485 Bus.
Das Modul soll sich dann in fhem wie ein normales wired Modul verhalten.
Ok, vielleicht kann man da irgendwas am HM485-Daemon ändern, so dass der direkt das Device anspricht.
Meine Frage wäre aber: Wieso das denn??? Der meiste Kram im Wired-Protokoll wird nur gebraucht, weil man Kollisionen haben kann, die Bandbreite stark limitiert ist und man selbst ein Adressierungsschema braucht. Alles das kommt bei TCP/IP sowieso nicht vor. Außerdem hat man mit HTTPMOD oder auch Firmata schon relativ einfache Einbindungen in FHEM.
Ich selbst mache den ganzen HM485-Kram eigentlich ausschließlich um Ethernet zu vermeiden.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 09 Juli 2015, 20:26:48
Zitat von: Thorsten Pferdekaemper am 09 Juli 2015, 19:00:41
Ok, vielleicht kann man da irgendwas am HM485-Daemon ändern, so dass der direkt das Device anspricht.
Meine Frage wäre aber: Wieso das denn??? Der meiste Kram im Wired-Protokoll wird nur gebraucht, weil man Kollisionen haben kann, die Bandbreite stark limitiert ist und man selbst ein Adressierungsschema braucht. Alles das kommt bei TCP/IP sowieso nicht vor. Außerdem hat man mit HTTPMOD oder auch Firmata schon relativ einfache Einbindungen in FHEM.

Ich habe vor dies direkt ohne den HM485-Daemon zu machen. Also so wie von fhem zum orginal HMW-LAN-GW.
Es gibt Modul-Orte wo ein LAN schon vorhanden oder einfacher hinzulegen ist als RS485.
Ich möchte HM-wired benutzen, da ich mich dort schon recht weit eingelesen und eingearbeitet habe. Ich kann dort eigene Anpassungen und Änderungen vornehmen.
Bei Firmata oder HTTPMOD müsste ich mich erst noch einlesen und einarbeiten.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 10 Juli 2015, 10:16:42
Zitat von: Ralf9 am 09 Juli 2015, 20:26:48
Bei Firmata oder HTTPMOD müsste ich mich erst noch einlesen und einarbeiten.
Ich glaube, dass das weit weniger Aufwand wäre, als das HM485 irgendwie auf Ethernet zu bringen.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Hoschiq am 10 Juli 2015, 15:03:30
Hallo,

hier http://forum.fhem.de/index.php/topic,14096.msg88557.html#msg88557

hat Dirk  einen Rs485 auf Ethernet Modul gebaut. Den lokalen homematic wired deamon kann man meiner Meinung nach auch die Ethernet Schnittstelle als Gerät zuweisen.
Dann braucht jedes Gerät so einen Adapter um von Rs485 auf LAN umzuwandeln.



Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 10 Juli 2015, 16:20:05
Hallo Thorsten,

heute ist mein max487 gekommen.
Ist der Schaltplan unten so korrekt? Bevor ich wieder was falsch mache  ::)  8)

Danke und Gruß
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Hoschiq am 10 Juli 2015, 22:54:55
Hallo Markus,

schaue dir hier einmal den Schaltplan vom Universalsensor an https://github.com/kc-GitHub/HM485-Lib/raw/thorsten/Schematic/Schematic-WIRED.pdf.
Den Spannungsteiler beim RO dort brauchst du nicht, da du mit 5V arbeitest.

Bei deinem Schaltplan ist der Anschluss von Lesen und Schreiben aktivieren (DE und RE) nicht korrekt. Es ist bei dir immer beides aktiv oder beides deaktiv.

Schalte RE gegen Ground dann empfängst du immer.
Senden (DE) sollte aktiv an und ausschaltbar sein also an einen Pin vom Arduino. Außerdem solltest du den DE zusätzlich mit einem 10K Widerstand gegen Ground schalten um einen sauberen Zustand zu haben.

Der Rest sollte passen.

VG
Hoschiq
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 11 Juli 2015, 08:10:29
Hallo Hoschiq,

Danke für deine Erklärung.
Zu den A und B Ausgängen habe ich noch eine Frage  ::).

Ich habe jetzt verschieden Schaltpläne im Internet gefunden.
Bei der Zeichnung des Universalsensor werden zu den Augängen jeweils ein Kondensator nach GRD geschalten.
Habe aber auch schon gesehen das man einen 100k Wiederstand nach GRD schalten kann.
Oder brauch man keines von beiden?

Danke und Gruß
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 11 Juli 2015, 08:52:15
Zitat von: Hoschiq am 10 Juli 2015, 22:54:55Bei deinem Schaltplan ist der Anschluss von Lesen und Schreiben aktivieren (DE und RE) nicht korrekt. Es ist bei dir immer beides aktiv oder beides deaktiv.
Nein, das stimmt schon so. Einer der beiden Pins auf dem MAX487 ist invertiert. Ich schließe das auch immer so an. Es geht auch so wie auf Dirks Plan, aber dann empfängt das Gerät immer auch seine eigenen Nachrichten, was manchmal lästig ist.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 11 Juli 2015, 08:55:02
Zitat von: mago0211 am 11 Juli 2015, 08:10:29Bei der Zeichnung des Universalsensor werden zu den Augängen jeweils ein Kondensator nach GRD geschalten.
Habe aber auch schon gesehen das man einen 100k Wiederstand nach GRD schalten kann.
Oder brauch man keines von beiden?
Ich glaube nicht, dass man das braucht. Es kann aber wahrscheinlich auch nicht schaden.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: jwagner am 13 Juli 2015, 12:51:56
Hi,

ich hatte mich die Tage wieder etwas mit dem H(B)W 485 Protokoll beschäftigt, und 2 neue Dinge herausgefunden:


Befehls-Typ 'Q' (0x51) - Manuelles Anlernen direkter Peerings

Es gibt einen in Dirk's Protokoll-Doku nicht vorhandenen Befehls-Typ 'Q' (0x51). Dieser wird von einem Taster-Sensor an den Aktor gesendet, quasi als Abschluss für den 'q' (0x71) Anlern-Befehl vom Aktor an den Sensor.

Hintergrund ist m.E. folgendes:


Dieser zusätzliche Schritt (im Vergleich zu dem ursprünglichen HS 485 Protokoll) macht Sinn, denn es könnte sein, dass der Tast-Senor im Schritt 4 z.B. keinen freien Speicher-Slot mehr hat, und deswegen die Verknüpfung nicht speichern kann. Der Aktor 'weiss' ja bereits vorher, ob er selbst noch einen Speicher-Slot frei hat, d.h. Schritt 6 sollte immer erfolgreich sein.


Das LAN Gateway sendet selbst ACKs

Das HomeMatic LAN Gateway erzeugt selbst ACK Nachrichten, und verwendet dabei Addressen anderer Devices!

Beispiel:

Zentrale (oder ein anderes Device) sendet ein SetActor oder SetLevel Frame an einen Aktor.
Der Aktor quittiert das Kommando mit einem Info-Frame statt einem ACK.

Das LAN Gateway erzeugt nun selbständig eine ACK Nachricht an den Aktor, und verwendet dafür die from- und to-Adressen aus dem Info-Frame in umgekehrter Reihenfolge.

Hoffe das hilft jemandem!

Viele Grüsse,
- jens
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 13 Juli 2015, 20:53:37
Hallo zusammen,

nun habe ich es endlich geschafft meinen Homebrew zum laufen zu bekommen. Was nicht sofort funktionierte war die Erkennung in FHEM. Ich musste das Device manuell anlegen. Automatisch hat er es nicht erkannt, ich war mir auch nicht sicher ob dies überhaupt von Dirks letzter HM485 Version unterstützt wird für die Homebrew Geräte.

Ich habe das ganze mal in ein Hutschienengehäuse gepackt sieht eigentlich ganz nett aus (Bilder unten). Jetzt werde ich die nächsten Tage noch ausführlicher Testen und wenn ich Zeit habe einen Schaltplan erstellen und im Wiki dazu was schreiben.


Nochmals Danke für eure Hilfe!  ;D

Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 13 Juli 2015, 21:30:48
Zitat von: mago0211 am 13 Juli 2015, 20:53:37Was nicht sofort funktionierte war die Erkennung in FHEM. Ich musste das Device manuell anlegen. Automatisch hat er es nicht erkannt, ich war mir auch nicht sicher ob dies überhaupt von Dirks letzter HM485 Version unterstützt wird für die Homebrew Geräte.
Eigentlich sollte das schon gehen. Hast Du im Sketch am Ende von setup sowas ähnliches wie das hier?

hmwmodule->broadcastAnnounce(0);

Dann sollte FHEM das Teil bei einem Reset eigentlich erkennen.

ZitatIch habe das ganze mal in ein Hutschienengehäuse gepackt sieht eigentlich ganz nett aus (Bilder unten).
Sieht wirklich nett aus.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Hoschiq am 13 Juli 2015, 23:46:03
Hallo Jens,

danke für die zusätzliche Protokollinformation. Das hilft dabei das direkte Peering in der Homebrew Firmware abzubilden.

Ein paar Fragen habe ich noch zu deinen Erkenntnissen:

-mit welchen Geräten hast du das mit den Q Nachrichten ermittelt?
-wurde dabei der Sensor mit einem Aktor Kanal eines anderen Gerätes gepeert oder mit einem eigenen Aktor Kanal  (z.B. Rolladenaktor mit Ein- und Ausgängen)
-falls nein, könnstest du diesen Fall (Peering eines eigenen Aktor Kanals) einmal nachstellen?

-Kannst du das auch nochmal mit dem Löschen eines Peerings (am Aktor den Löschmodus aktivieren und dann Sensor betätigen) durchspielen und die dabei stattfindende Kommunikation mitteilen? Hier gibt es ja ein ähnliches Problem, wenn der Sensor den Löschbefehl nicht durchführte aber der Aktor das Peering löschen möchte.

Das Problem mit dem automatischen Erkennen in FHEM von Homebrew Geräten habe ich auch ab und zu.

VG
Hoschiq
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: jwagner am 14 Juli 2015, 11:14:05
Zitat
-mit welchen Geräten hast du das mit den Q Nachrichten ermittelt?

Mit einem HMW-LC-Sw2-DR (HomeMatic Wired RS485-Schaltaktor). Kann das Teil erfolgreich mit meinem PC oder einem Arduino peeren, ohne Zentrale.

Zitat
-wurde dabei der Sensor mit einem Aktor Kanal eines anderen Gerätes gepeert oder mit einem eigenen Aktor Kanal  (z.B. Rolladenaktor mit Ein- und Ausgängen)

Sowohl als auch. Allerdings gehen bei einer 'internen Direktverknüpfung' keine q oder Q Meldungen nach aussen, man sieht nur den Key-Broadcast.

Zitat
-falls nein, könnstest du diesen Fall (Peering eines eigenen Aktor Kanals) einmal nachstellen?

S.o., ausser dem K-Broadcast geht nichts nach aussen (wäre auch sinnlos).

Zitat
-Kannst du das auch nochmal mit dem Löschen eines Peerings (am Aktor den Löschmodus aktivieren und dann Sensor betätigen) durchspielen und die dabei stattfindende Kommunikation mitteilen? Hier gibt es ja ein ähnliches Problem, wenn der Sensor den Löschbefehl nicht durchführte aber der Aktor das Peering löschen möchte.

Das Problem kann hier logischerweise nicht auftreten, Verknüpfungen können immer gelöscht werden. Der c-Request funktioniert noch wie im HS486 Protokoll beschrieben.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 Juli 2015, 11:44:10
Zitat von: jwagner am 13 Juli 2015, 12:51:56Das LAN Gateway sendet selbst ACKs
Das klingt für mich nach einen Bug im Gateway, außer für ganz spezielle Szenarien.

Zitat
Zentrale (oder ein anderes Device) sendet ein SetActor oder SetLevel Frame an einen Aktor.
Der Aktor quittiert das Kommando mit einem Info-Frame statt einem ACK.
Das LAN Gateway erzeugt nun selbständig eine ACK Nachricht an den Aktor, und verwendet dafür die from- und to-Adressen aus dem Info-Frame in umgekehrter Reihenfolge.
Dass da zum Schluss noch mal ein ACK kommen muss ist klar. Der Info-Frame ist nicht nur ein ACK, also würde er wiederholt werden, wenn kein ACK kommt. Allerdings würde ich sagen, dass dieses ACK nur dann vom Gateway kommen darf, wenn das Info-Frame an die Zentrale geschickt wird. Ansonsten müsste ja das Device, an das die Info-Message gerichtet ist, das ACK senden.
Andererseits kann es sein, dass dieses spezielle Info-Frame immer an die Zentrale geschickt wird. Es sendet ansonsten ja kein Device einen Set-Befehl.
Naja, es klingt aber trotzdem irgendwie seltsam.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 14 Juli 2015, 19:31:50
Zitat von: Thorsten Pferdekaemper am 13 Juli 2015, 21:30:48
Eigentlich sollte das schon gehen. Hast Du im Sketch am Ende von setup sowas ähnliches wie das hier?

hmwmodule->broadcastAnnounce(0);


Ja der Eintrag ist vorhanden und müsste soweit ich cpp verstehe funktionieren. Leider komme ich eher aus der Python Welt deshalb tu ich mich etwas schwer den Code zu interpretieren aber probieren geht über studieren  8)

Ich muss mir nur endlich für Eclipse das Arduino Plugin installieren. Die Arduino IDE ist ja ne Zumutung.

Gruß
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 15 Juli 2015, 00:29:47
Zitat von: mago0211 am 14 Juli 2015, 19:31:50
Ja der Eintrag ist vorhanden und müsste soweit ich cpp verstehe funktionieren.
Welche FHEM-HM485-Version hast Du? Im Zweifelsfall hol Dir mal die neuste von https://github.com/kc-GitHub/FHEM-HM485 (https://github.com/kc-GitHub/FHEM-HM485).
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 15 Juli 2015, 08:35:23
Ich habe noch die letzte Version von Dirk.
Mit den gevoo Versionen hatte ich bisher immer irgendwelche Probleme, hatte aber nie Zeit es genauer zu verfolgen deshalb bin ich wieder auf die alte Version umgestiegen.

Gruß
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 15 Juli 2015, 09:24:28
Zitat von: mago0211 am 15 Juli 2015, 08:35:23
Ich habe noch die letzte Version von Dirk.
Mit den gevoo Versionen hatte ich bisher immer irgendwelche Probleme, hatte aber nie Zeit es genauer zu verfolgen deshalb bin ich wieder auf die alte Version umgestiegen.
Tja, Dirk's Version ist halt schon ein bisschen alt. Da hat sich inzwischen einiges getan.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 15 Juli 2015, 09:42:21
Zitat von: Thorsten Pferdekaemper am 15 Juli 2015, 09:24:28
Tja, Dirk's Version ist halt schon ein bisschen alt. Da hat sich inzwischen einiges getan.

Ja ich weiß,  :-\ Aber da ich HM-Wired produktiv einsetzte brauche ich eine einigermaßen Stabile Version was mir bisher mit gevoos Versionen noch nicht gelungen ist leider  :( .

Vielleicht starte ich mal wieder einen Versuch.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 15 Juli 2015, 10:23:46
Zitat von: mago0211 am 15 Juli 2015, 09:42:21
Ja ich weiß,  :-\ Aber da ich HM-Wired produktiv einsetzte brauche ich eine einigermaßen Stabile Version was mir bisher mit gevoos Versionen noch nicht gelungen ist leider  :( .
Ja, ich habe da zurzeit auch so meine Problemchen. Es scheint aber auch mit dem LAN-Adapter zusammenzuhängen. Etwas wenig beruhigend ist auch, dass sich gevoo das letzte Mal am 21. Juni gemeldet hat (http://forum.fhem.de/index.php/topic,10607.msg305791.html#msg305791 (http://forum.fhem.de/index.php/topic,10607.msg305791.html#msg305791)). Vielleicht ist er auch nur im Urlaub.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 15 Juli 2015, 11:11:57
Zitat von: Thorsten Pferdekaemper am 15 Juli 2015, 10:23:46
Ja, ich habe da zurzeit auch so meine Problemchen. Es scheint aber auch mit dem LAN-Adapter zusammenzuhängen.

Hast Du schon versucht fhem auf eine Version vor dem 14.05.2015 downzugraden um auszuschließen, daß die Änderungen an der DevIo.pm die Ursache sind?
http://forum.fhem.de/index.php/topic,10607.msg309106.html#msg309106

Ab der Version 138 kann es bei gevoos Version zu Problemen kommen, wenn die Verbindung zwischen fhem und den HM-wired Modulen nicht stabil läuft.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 15 Juli 2015, 11:23:41
Zitat von: Ralf9 am 15 Juli 2015, 11:11:57
Hast Du schon versucht fhem auf eine Version vor dem 14.05.2015 downzugraden um auszuschließen, daß die Änderungen an der DevIo.pm die Ursache sind?
Nein, das hatte ich noch nicht versucht. Bei mir bricht nur manchmal der Daemon ab und das auch nur auf meinem Testsystem. Einmal den Daemon über die FHEM-Oberfläche neu gestartet und es geht wieder. (Sollte das nicht automatisch passieren?)
Außerdem will ich sowieso komplett vom LAN-Adapter weg. Ich habe mir noch einen dieser USB-Adapter bestellt und werde dann damit weitermachen. Wenn die Probleme dann immer noch auftreten, wird weiter geforscht.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 15 Juli 2015, 12:37:00
Zitat von: Thorsten Pferdekaemper am 15 Juli 2015, 11:23:41
Außerdem will ich sowieso komplett vom LAN-Adapter weg. Ich habe mir noch einen dieser USB-Adapter bestellt und werde dann damit weitermachen. Wenn die Probleme dann immer noch auftreten, wird weiter geforscht.

Durch die Änderungen  an der DevIo.pm kann es sein, daß bei einem disconnect der reconnect nicht funktioniert.
Diese Probleme kannst Du auch beim USB-Adapter bekommen, wenn die USB-Verbindung nicht stabil läuft.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 15 Juli 2015, 12:45:40
Zitat von: Ralf9 am 15 Juli 2015, 12:37:00
Durch die Änderungen  an der DevIo.pm kann es sein, daß bei einem disconnect der reconnect nicht funktioniert.
Diese Probleme kannst Du auch beim USB-Adapter bekommen, wenn die USB-Verbindung nicht stabil läuft.
Ist irgendwas geplant, um das Problem zu lösen? Z.B. eine eigene DevIO.pm für HM485 oder die Änderung rückgängig machen? Es ist ja schon etwas blöd, wenn man eine alte DevIO.pm benutzen muss. Womöglich funktioniert das dann mit irgendwelchen anderen Geräten nicht mehr.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 15 Juli 2015, 14:00:47
Hallo Thorsten,

Zitat von: Thorsten Pferdekaemper am 15 Juli 2015, 12:45:40
Ist irgendwas geplant, um das Problem zu lösen? Z.B. eine eigene DevIO.pm für HM485 oder die Änderung rückgängig machen? Es ist ja schon etwas blöd, wenn man eine alte DevIO.pm benutzen muss. Womöglich funktioniert das dann mit irgendwelchen anderen Geräten nicht mehr.

Ja leider hört man von gevoo aktuell nichts. Aber auch ich kann bestätigen, dass der USB Adapter mit dem DevIO Workaround wieder komplett stabil läuft. Habe sogar wieder nen USB-Hub dazwischen.

Jetzt kann ich mich mal ans Homebrew wagen und so meine 1W Sensoren und die Zähler im Haus einfangen und auf FHEM migrieren.
Wenn das einzeln läuft, will ich OneWire und S0 auf einen Baustein bringen.

Viele Grüße
Stephan


Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 15 Juli 2015, 20:31:37
Zitat von: Thorsten Pferdekaemper am 15 Juli 2015, 12:45:40
Ist irgendwas geplant, um das Problem zu lösen? Z.B. eine eigene DevIO.pm für HM485 oder die Änderung rückgängig machen? Es ist ja schon etwas blöd, wenn man eine alte DevIO.pm benutzen muss. Womöglich funktioniert das dann mit irgendwelchen anderen Geräten nicht mehr.

Für den DevIO Workaround mußt Du die "DevIo485.pm" von der Anlage ins FHEM Verzeichnis kopieren.

Du mußt dann bei der ServerTools.pm bei der Zeile 64 bei  "require $pathFHEM . 'DevIo.pm';"   das DevIo.pm in DevIo485.pm ändern.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 15 Juli 2015, 21:14:04
Hallo,

ich komme mit meinem Homebrew Modul mit Ethernet Anbindung monentan nicht so richtig weiter.
Ich verwende dazu das "MEGA 2560 R3 ATMEGA Board" und das "Ethernet Shield w5100  für Arduino Mega 2560 / Uno AR02003 H33"
Die Ethernet Routinen funktionieren soweit und in fhem geht das HM485_LAN in den state opened.

Nun habe ich das Problem, das ich nicht weiß wie ich von der  HMWRS485.cpp  die Ethernetroutinen im Hauptmodul "HMW-ethernet.ino" aufrufen kann.

in der HMW-ethernet.ino steht u.a.

#include <Ethernet.h>
#include <SPI.h>

EthernetServer server = EthernetServer(1000);      // telnet to port 1000
EthernetServer serverDebug = EthernetServer(23);
EthernetClient client;
EthernetClient clientDebug;

void setup()
{
  // initialize the ethernet device
  Ethernet.begin(mac, ip, gateway, subnet);
  // start listening for clients
  server.begin();

}


in der HMWRS485.cpp steht u.a.

void HMWRS485::receive(){

  byte rxByte;
  boolean receiveflag true;
 
while(receiveflag) {
  client = server.available();
  if (client) {
    rxByte = client.read();

    if(rxByte == FRAME_START_LONG){  // Startzeichen empfangen



Wie kann ich in der HMWRS485.cpp die folgenden Routinen aufrufen?

client = server.available();      //-> Client ist ein object

  if (client) {
    rxByte = client.read();

server.write(sendByte);



Nachtrag:
Kann es etwa so funktionieren?

In die HMW-ethernet.ino kommt:

HMWRS485 hmwrs485(&server, &serverDebug, &client);


Und in die HMWRS485.cpp kommt dann:

HMWRS485::HMWRS485(_server, _serverDebug, _client) {
server = _server;
       serverDebug = _serverDebug;
       client = _client
}

HMWRS485::~HMWRS485() {
}



Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 15 Juli 2015, 23:12:33
Zitat von: Ralf9 am 15 Juli 2015, 20:31:37
Für den DevIO Workaround mußt Du die "DevIo485.pm" von der Anlage ins FHEM Verzeichnis kopieren.
Du mußt dann bei der ServerTools.pm bei der Zeile 64 bei  "require $pathFHEM . 'DevIo.pm';"   das DevIo.pm in DevIo485.pm ändern.
Ah, ok. Das bedeutet, dass der Workaround nur HM485-Sachen betrifft. Dann werde ich das mal einbauen.

EDIT: Oh, anscheinend doch nicht. ServerTools.pm scheint zwar in der HM485-"Auslieferung" zu sein, aber auch im "normalen" FHEM. Da müsste sich mal jemand kümmern...
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 16 Juli 2015, 11:10:16
Zitat von: Ralf9 am 15 Juli 2015, 21:14:04
Nun habe ich das Problem, das ich nicht weiß wie ich von der  HMWRS485.cpp  die Ethernetroutinen im Hauptmodul "HMW-ethernet.ino" aufrufen kann.

Kann ich dies auch mit einer Funktion mit externer Bindung lösen?

Kann es so funktionieren?

In die HMW-ethernet.ino kommt u.a.:

#include <Ethernet.h>
#include <SPI.h>

EthernetServer server = EthernetServer(1000);      // telnet to port 1000

void lanWrite(byte var) {
  server.write(var);
}



in die HMWRS485.cpp kommt u.a.

extern void lanWrite(byte)

void HMWRS485::sendbyte(byte txByte){
  lanWrite(txByte)
}



Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 16 Juli 2015, 11:31:49
Zitat von: Ralf9 am 16 Juli 2015, 11:10:16
Kann ich dies auch mit einer Funktion mit externer Bindung lösen?

Kann es so funktionieren?

In die HMW-ethernet.ino kommt u.a.:
Hi Ralf,
könntest Du dafür einen neuen Thread aufmachen? Ich denke, das wird etwas komplexer. Außerdem hat es nicht so ganz direkt etwas mit HMW-Homebrew zu tun.

Zum Thema: Was ist genau das Problem? Du musst Dir doch sowieso eine eigene Kopie von HMWRS485.h/cpp machen. Schreib den ganzen Ethernet-Kram doch direkt dort rein. Falls Du das nicht willst, und Du die Ethernet-Geschichten im Hauptsketch behalten willst, dann mach die Methode sendbyte virtual (oder sogar pure virtual) und leite im Hauptsketch von der HMWRS485-Klasse ab. Die abgeleitete Klasse definiert dann sendbyte neu, indem sie lanWrite aufruft.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 16 Juli 2015, 12:36:06
Zitat von: Thorsten Pferdekaemper am 16 Juli 2015, 11:31:49
Zum Thema: Was ist genau das Problem? Du musst Dir doch sowieso eine eigene Kopie von HMWRS485.h/cpp machen. Schreib den ganzen Ethernet-Kram doch direkt dort rein.
Ich wusste nicht ob ich den ganzen Ethernet-Kram in die HMWRS485.h/cpp reinschreiben darf.
Ich habe es schon versucht die Ethernetdefinition in die HMWRS485.cpp reinzuschreiben, ich bekomme aber die Fehlermeldung, daß die Datei Ethernet.h nicht gefunden wird. Im Hauptsketch funktioniert es aber ohne Probleme.
Ich habe die Ethernet library in das entsprechende Verzeichnis /usr/share/Anduino.. kopiert.

in der HMWRS485.cpp steht u.a.

#include "HMWRS485.h"
#include <Ethernet.h>
#include <SPI.h>


Zitat von: Thorsten Pferdekaemper am 16 Juli 2015, 11:31:49
Falls Du das nicht willst, und Du die Ethernet-Geschichten im Hauptsketch behalten willst, dann mach die Methode sendbyte virtual (oder sogar pure virtual) und leite im Hauptsketch von der HMWRS485-Klasse ab. Die abgeleitete Klasse definiert dann sendbyte neu, indem sie lanWrite aufruft.

Das bekomme ich alleine nicht hin, so tief bin ich in c++ nicht drin. Referenzen, virtual und abgeleitete Klassen sind mir zu komplex.
Ich habe zwar ein c++ Buch, aber das geht nicht so sehr in die Tiefe.
Falls dies gegenüber dem Hauptsketch keine Nachteile hat, werde ich es erstmal versuchen ob ich den Ethernet-Kram in der HMWRS485.h zum laufen bekomme.

Ich denke es hat schon recht viel mit HMW-Homebrew zu tun. Das Ethernet Homebrew Modul verhält sich gegenüber fhem wie ein normales HMW-Homebrew Modul, es wird aber kein HM485d Dämon benötigt.
Falls die Ethernetroutinen in der HMWRS485.cpp nicht funktionieren oder es notwendig wird, daß die Ethernetroutinen in den Hauptsketch müssen, werde ich ein neues Thema aufmachen.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 16 Juli 2015, 13:46:47
Zitat von: Ralf9 am 16 Juli 2015, 12:36:06
Ich wusste nicht ob ich den ganzen Ethernet-Kram in die HMWRS485.h/cpp reinschreiben darf.
Da kannst Du machen was Du willst, so lange das nicht in den "offiziellen" Branch ins Git kommt.

Zitat
Ich habe es schon versucht die Ethernetdefinition in die HMWRS485.cpp reinzuschreiben, ich bekomme aber die Fehlermeldung, daß die Datei Ethernet.h nicht gefunden wird. Im Hauptsketch funktioniert es aber ohne Probleme.
Ich habe die Ethernet library in das entsprechende Verzeichnis /usr/share/Anduino.. kopiert.
Verwendest Du die Arduino-IDE? Wenn ja: versuch mal eine richtige IDE zu finden. Mit der Arduino-IDE muss jedes #include auch im Hauptsketch stehen, auch wenn die Deklarationen daraus nur in anderen Libs verwendet werden.

Zitat
Falls dies gegenüber dem Hauptsketch keine Nachteile hat, werde ich es erstmal versuchen ob ich den Ethernet-Kram in der HMWRS485.h zum laufen bekomme.
Es gibt dann bei Dir eben zwei Versionen von HMWRS485: Die normale und die per Ethernet.

Zitat
Das Ethernet Homebrew Modul verhält sich gegenüber fhem wie ein normales HMW-Homebrew Modul, es wird aber kein HM485d Dämon benötigt.
Ich bin immer noch gespannt, ob Du das tatsächlich so hinbekommst.

Zitat
Falls die Ethernetroutinen in der HMWRS485.cpp nicht funktionieren oder es notwendig wird, daß die Ethernetroutinen in den Hauptsketch müssen, werde ich ein neues Thema aufmachen.
Ich verstehe die Abhängigkeit nicht...
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Bromm am 17 Juli 2015, 11:16:08
Hallo Thomas, Markus, Thorsten und natürlich alle anderen zusammen!

Nun, nach doch ein paar verstrichenen Wochen, möchte ich doch einmal wieder ein Lebenszeichen senden... ;-) Die liebe Zeit fehlte mir in den letzten Wochen leider etwas um aktiver in der Entwicklung und auf der "Bildfläche" zu sein. Trotzdem hat sich, immer Stück für Stück, das angekündigte Board welches ich als universelles Modul für UP und DIN-Hutschiene entwerfe, gut weiterentwickelt. Also im Computer ist das Teil schon quasi fertig. Nur noch ein paar Überprüfungen bzw. eventuelle Korrekturen. Der nächste Schritt wären dann zwei, drei Prototypen. Auf Grund meiner beruflichen Arbeit kann ich zur Zeit leider noch keine konkreten Angaben zum zeitlichen Fortschritt machen. Nur, es geht vorwärts und ist schon sehr vielversprechend...

Viele Grüße
Björn
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 17 Juli 2015, 12:48:22
Zitat von: Thorsten Pferdekaemper am 16 Juli 2015, 13:46:47
Verwendest Du die Arduino-IDE? Wenn ja: versuch mal eine richtige IDE zu finden. Mit der Arduino-IDE muss jedes #include auch im Hauptsketch stehen, auch wenn die Deklarationen daraus nur in anderen Libs verwendet werden.
Ich verwende die Arduino-IDE. Danke für diesen Hinweis.

Zitat
Ich bin immer noch gespannt, ob Du das tatsächlich so hinbekommst.
Ich habe nun die Ethernetroutinen in der HMWRS485.cpp zum Laufen bekommen. Es funktioniert bis jetzt alles wie gewünscht. Die debug Ausgabe mache ich über eine zusätzliche Telnet session.
Das Modul verhält sich gegenüber fhem wie ein LAN Gateway. Die Routinen in der HMWRS485.cpp sind fast fertig. Das empfangen von Frames und das senden von Keepalive- und Response Frames funktioniert auch schon.

Jetzt kommt noch die Einbindung der HMWModule.cpp. In der HMWModule.cpp werde ich auch noch einige änderungen vornehmen müssen. Bei einigen Befehlen, wo ich nicht nachvollziehen konnte ob das was zurückgesendet wird so passt, werde ich etwas umbauen.

Gruß Ralf

Nachtrag:
Ich sehe gerade, daß ich bei den Response Nachrichten einen Denkfehler hatte, ich dachte daß bei diesen die Daten immer mit einem 0x69 anfangen. Dies ist aber anscheinend nicht so.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 19 Juli 2015, 16:41:44
Hallo Ihr,

ich habe jetzt mal mein erstes selbstgebackenes Modul zusammengestellt.

Es ist ein HBW-1W-T10 geworden, (nachdem ich Arduino IDE aktualisiert habe und wirklich alle Sources zusammenkopiert habe) :-D

Das Gerät ansich existiert. Auf der Debug Console kann ich sehen, das die Sensoren erkannt werden.
Es werden in FHEM leider keine Kanäle angelegt. Wie kann ich die manuell anlegen?

EDITH: Trotz kopiertem devicefile (hbw_1w_t10.pm) bekomme ich folgende Meldung:
2015.07.19 16:43:54 3: HM485: Initialisierungsfehler 42FFFFFF ModelName noch nicht vorhanden
2015.07.19 16:43:54 3: HM485: Initialisierung von Modul 42FFFFFF


Jetzt noch ein paar Detailfragen:

Wo wird die Seriennummer der Bausteine erzeugt?
Ich benötige zwei OneWire Module, wodurch ich erstmal befürchte, die gleiche Seriennummer zu bekommen.
Da müsste ich manuell eingreifen.
Seriennummer: HBW4073471 DEF: 42FFFFFF

Wenn ich einen Arduino benutze, ist der HW UART immer mit dem USB-RS232 Wandler verdrahtet.
Kommt sich da ein angeschlossener MAX485 mit ins Gehege?


Viele Grüße
Stephan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 19 Juli 2015, 17:17:53
Hallo Stephan,

sieht nach einem ähnlichen Problem aus wie bei mir

http://forum.fhem.de/index.php/topic,39281.0.html (http://forum.fhem.de/index.php/topic,39281.0.html)

Scheinbar werden die HBW Device Files nicht richtig geladen. Habe aber bisher noch nicht herausgefunden warum.

Zitat von: stephan-221 am 19 Juli 2015, 16:41:44
Es werden in FHEM leider keine Kanäle angelegt. Wie kann ich die manuell anlegen?

Ich glaube mit
define HBM_01 HM485 42FFFFFF_01

Gruß
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 Juli 2015, 18:06:17
Zitat von: stephan-221 am 19 Juli 2015, 16:41:44
Es ist ein HBW-1W-T10 geworden, (nachdem ich Arduino IDE aktualisiert habe und wirklich alle Sources zusammenkopiert habe) :-D

[Probleme...]


Hi Stephan,
ich schau mir das mal genauer an. Auch das mit der Seriennummer werde ich erklären...
Ich denke, da komme ich heute noch dazu.

Zitat
Es werden in FHEM leider keine Kanäle angelegt. Wie kann ich die manuell anlegen?
Das könnte zwar gehen, würde aber wahrscheinlich nicht viel nutzen.

Zitat
Wenn ich einen Arduino benutze, ist der HW UART immer mit dem USB-RS232 Wandler verdrahtet.
Kommt sich da ein angeschlossener MAX485 mit ins Gehege?
Bei Arduinos habe ich normalerweise MAX485 über SoftwareSerial an anderen Pins. Wir brauchen ja nur 19200 Baud.
...aber wenn es Probleme macht, dann wären die Symptome anders.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 19 Juli 2015, 18:42:34
Hallo Thorsten,

Zitat von: Thorsten Pferdekaemper am 19 Juli 2015, 18:06:17
Hi Stephan,
ich schau mir das mal genauer an. Auch das mit der Seriennummer werde ich erklären...
Ich denke, da komme ich heute noch dazu.

Das wäre klasse.

Zitat von: Thorsten Pferdekaemper
Bei Arduinos habe ich normalerweise MAX485 über SoftwareSerial an anderen Pins. Wir brauchen ja nur 19200 Baud.
...aber wenn es Probleme macht, dann wären die Symptome anders.

Daran wirds auch nicht liegen. Das ist nur jetzt die Überlegung von Steckbrett auf Lochraster.
Ich habe den ersten Entwurf auch mit SoftSerial für RS485.

Das Problem liegt ja irgendwie daran, dass die Files nicht eingelesen werden.

Viele Grüße
Stephan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 19 Juli 2015, 18:52:08
Habt ihr im Hauptsketch den Modultyp eingetragen?

hmwmodule = new HMWModule(&hmwdevice, &hmwrs485, 0x19);


Zitat von: mago0211 am 15 Juli 2015, 08:35:23
Ich habe noch die letzte Version von Dirk.
Mit einer alten Version wird nur der HMW_SEN_SC_12_DR und evtl der HMW-LC-Sw2-DR  funktionieren. Für die anderen Homebrew Module benötigt ihr die aktuelle Version von gevoo oder die Version von honk.

Das automatische generieren der Seriennr hat bei mir funktioniert.
Ich habe den HMW_SEN_SC_12_DR nachgebaut, er wurde in fhem komplett erkannt und es funktionieren bis jetzt die ersten beiden Kanäle.

Damit die anderen Kanäle auf funktionieren muß ich sie erst im Hauptsketch und in der HMWRegister.h definieren.
Kann ich dies so im Hauptsketch so machen oder geht es einfacher oder eleganter?

#define Sensor[12] = {22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33}
#define CHANNEL_IO_COUNT 12
#define CHANNEL_IO_BYTES 2
#define CHANNEL_PORTS byte channelPorts[CHANNEL_IO_COUNT] = {Sensor[0], Sensor[1], Sensor[2], Sensor[3],Sensor[4], Sensor[5], Sensor[6], Sensor[7], Sensor[8], Sensor[9], Sensor[10], Sensor[11]};
byte portStatus[CHANNEL_IO_BYTES];


und in der HMWRegister.h steht bis jetzt folgendes. Als Vorlage habe ich das HMW-LC-Sw2-DR genommen. Ich möchte die keys und switche beibehalten und es sollen auch noch Analogeingänge dazukommen.
Was muß ich in der "struct hmw_config_sensor" eintragen damit die 12 Kanäle in 2 Byte kommen?

#define HMW_CONFIG_NUM_KEYS 2        // Anzahl Tastereingaenge
#define HMW_CONFIG_NUM_SENSORS 2     // Anzahl Sensoreingaenge
#define HMW_CONFIG_NUM_SWITCHES 2    // Schalter (Aktoren)

// Sensor
struct hmw_config_sensor {
byte input_locked          :1;   // 0x07:1    0=LOCKED, 1=UNLOCKED
byte                       :7;   // 0x07:2-7
};

// Taster
struct hmw_config_key {
byte input_type            :1;   // 0x07:0    0=SWITCH, 1=PUSHBUTTON
byte input_locked          :1;   // 0x07:1    0=LOCKED, 1=UNLOCKED
byte                       :6;   // 0x07:2-7
byte long_press_time;            // 0x08
};

struct hmw_config_switch {
byte logging:1;    // 0x0B:0     0=OFF, 1=ON
byte        :7;    // 0x0B:1-7
byte        :8;    // 0x0C      // dummy     //TODO: Optimize (?)
};

struct hmw_config {
byte logging_time;     // 0x01
long central_address;  // 0x02 - 0x05
byte direct_link_deactivate:1;   // 0x06:0
byte                       :7;   // 0x06:1-7
    hmw_config_sensor sensors[HMW_CONFIG_NUM_SENSORS];
    hmw_config_key keys[HMW_CONFIG_NUM_KEYS];  // 0x07 - 0x0A
    hmw_config_switch switches[HMW_CONFIG_NUM_SWITCHES];  // 0x0B - 0x0E
};



Nachtrag:
Hat sich inzwischen erledigt. Ich habe es anders gelöst.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 19 Juli 2015, 19:52:22
Hallo Ralf,

ich nutze ja bisher gevoos letzte Version. Daher ist zumindest die Unterstützung da.

Jetzt hilf mal einem newbie für Arduino... WTF ist der Hauptsketch? quasi die .ino Datei?
In meinem Fall dann die umbenannte HBW-1W-T10.ino?

Ich habe in dieser Datei jetzt hmwmodule = new HMWModule(&hmwdevice, &hmwrs485, 0x81);
eingetragen. Bringt aber bisher folgende Fehlermeldung:
HBW-1W-T10:26: error: 'hmwmodule' does not name a type
'hmwmodule' does not name a type


eine HMWRegister.h kenne ich nicht.
Ich habe gerade gesehen, dass je nach HxW Baustein eine HMWRegister.h existiert oder auch nicht.
Für den 1W-T10 bisher nicht.


Viele Grüße
Stephan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: mago0211 am 19 Juli 2015, 19:56:18
Hallo Ralf

Zitat von: Ralf9 am 19 Juli 2015, 18:52:08
Habt ihr im Hauptsketch den Modultyp eingetragen?

hmwmodule = new HMWModule(&hmwdevice, &hmwrs485, 0x19);


ich habe das bereits vorhanden Homebrew Device HBW-Sen-SC8 nachgebaut. Da habe ich an dem sketch nichts geändert.

Zitat von: Ralf9 am 19 Juli 2015, 18:52:08
Mit einer alten Version wird nur der HMW_SEN_SC_12_DR und evtl der HMW-LC-Sw2-DR  funktionieren. Für die anderen Homebrew Module benötigt ihr die aktuelle Version von gevoo oder die Version von honk.

Auf dem Testsystem habe ich die aktuelle Version von gevoo aus dem Git geladen.

Wo finde ich die Version von honk?
Ist diese aus dem Thema die richtige?
http://forum.fhem.de/index.php/topic,30804.30.html (http://forum.fhem.de/index.php/topic,30804.30.html)

Oder gibt es irgendwo ein Git?


Habe übrigens noch mal versucht an meinem Hauptsystem auf dem noch Dirks Version mit einem Original HM-Lan-Gateway läuft, das selbstgebaute HBW-Sen-SC8 zu koppeln. Dies funktionierte auch wunderbar. Er wurde zwar nicht automatisch erkannt aber nach der manuellen Definition hat er ihn einwandfrei und richtig erkannt.

Gruß
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 Juli 2015, 20:31:43
Zitat von: stephan-221 am 19 Juli 2015, 16:41:44
ich habe jetzt mal mein erstes selbstgebackenes Modul zusammengestellt.
Es ist ein HBW-1W-T10 geworden,
Das freut mich.

Zitat
Das Gerät ansich existiert. Auf der Debug Console kann ich sehen, das die Sensoren erkannt werden.
Es werden in FHEM leider keine Kanäle angelegt. Wie kann ich die manuell anlegen?
Also ich habe gerade auf einem Arduino Uno den Kram draufgepackt und es hat bei meinem Test-FHEM auf Anhieb funktioniert.
Beim automatischen Anlegen der Kanäle gibt es noch Probleme in der FHEM-Integration. Du musst einmal "get <device> config all" machen und dann ein paar Sekunden warten. Dann ein Refresh auf die FHEM-Oberfläche und die Kanäle müssten erscheinen.

Ach ja: Hast Du das Gerät in FHEM manuell angelegt? Es sollte eigentlich per Autocreate gehen.
Außerdem: Neuste HM485-Version in FHEM? Hol Dir mal im Zweifelsfall den Kram von hier: https://github.com/kc-GitHub/FHEM-HM485/archive/master.zip (https://github.com/kc-GitHub/FHEM-HM485/archive/master.zip)

Zitat
EDITH: Trotz kopiertem devicefile (hbw_1w_t10.pm) bekomme ich folgende Meldung:
2015.07.19 16:43:54 3: HM485: Initialisierungsfehler 42FFFFFF ModelName noch nicht vorhanden
2015.07.19 16:43:54 3: HM485: Initialisierung von Modul 42FFFFFF
Ok, da war die Vermutung, dass das Device File nicht richtig gelesen wurde. Das glaube ich allerdings nicht so ganz. Man weiß aber nie. Im Logfile müsstest Du eigentlich sowas sehen:

2015.07.19 19:49:49 3: HM485: HM485: Loading available device files
2015.07.19 19:49:49 3: HM485: =====================================
2015.07.19 19:49:49 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hbw_1w_t10.pm
2015.07.19 19:49:49 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_central.pm
2015.07.19 19:49:49 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_generic.pm
2015.07.19 19:49:49 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw14_dr.pm
2015.07.19 19:49:49 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr.pm
2015.07.19 19:49:50 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr_V3_02.pm
2015.07.19 19:49:50 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_12_fm.pm
2015.07.19 19:49:50 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm.pm

Das ist vom FHEM-Start. Könntest Du mal nachschauen, ob da was faul ist? hbw_1w_t10.pm sollte zu finden sein.

Vielleicht ist auch was an der Kommunikation faul. Hast Du das SoftwareSerial.cpp von https://github.com/kc-GitHub/HM485-Lib/tree/thorsten (https://github.com/kc-GitHub/HM485-Lib/tree/thorsten) oder das Standard-Arduino-SoftwareSerial.cpp?

Ansonsten: Übersetze den Sketch mal mit #define DEBUG_VERSION DEBUG_UNO und RS485 an Pins 5/6 (siehe Arduino Coding). Dann Serial Monitor einschalten. Lösche das Device aus FHEM und drücke danach reset auf dem Arduino. Könntest Du mir mal schicken, was der Serial Monitor dann anzeigt?

ZitatWo wird die Seriennummer der Bausteine erzeugt?
Bei "meinen" Modulen steht die im EEPROM in den letzten 4 Bytes. Bei einem jungfräulichen Arduino steht da 0xFFFFFFFF. In den Fall wird 0x42FFFFFF als Adresse genommen.
Die Seriennummer ist dann "HBW" gefolgt von den letzten 7 Stellen der Addresse in Dezimalnotation.

Zitat
Ich benötige zwei OneWire Module, wodurch ich erstmal befürchte, die gleiche Seriennummer zu bekommen.
Da müsste ich manuell eingreifen.
Seriennummer: HBW4073471 DEF: 42FFFFFF
Du kannst bei den HBW-Modulen die Adresse und damit auch die Seriennummer ändern. Dafür gibt es den Spezialbefehl "@a" (0x4061).
Sobald Du das Device mit 42FFFFFF in FHEM siehst, dann das hier eingeben:

set hm485 RAW 42FFFFFF 1A 00000001 406142000014

Die letzten 4 Bytes (also 8 Zeichen) sind die neue Adresse, im obigen Fall also 42000014.
Danach wird das Device in FHEM neu angelegt. Du solltest das Device 42FFFFFF vorher löschen, sonst kann es momentan noch Probleme geben. (Ich arbeite daran...) FHEM stürzt beim Löschen vielleicht ab, dann einfach neu starten.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 19 Juli 2015, 20:56:44
Zitat von: stephan-221 am 19 Juli 2015, 19:52:22
Jetzt hilf mal einem newbie für Arduino... WTF ist der Hauptsketch? quasi die .ino Datei?
In meinem Fall dann die umbenannte HBW-1W-T10.ino?
Ich bin genauso wie ihr ein newbie für Arduino. Ein Homebrew Modul mit den Dateien vom Git nachzubauen ist sehr mühsam.
Ja die .ino Datei ist der Hauptsketch.

Zitat
Ich habe in dieser Datei jetzt hmwmodule = new HMWModule(&hmwdevice, &hmwrs485, 0x81);
eingetragen.
Diese Zeile müsste eigentlich schon in der ino Datei bei void setup() drinstehen
https://github.com/kc-GitHub/HM485-Lib/blob/thorsten/HBW-1W-T10/HBW-1W-T10.cpp

Normalerweise wird ein Modul automatisch angelegt.
Wenn fhem einen Tastendruck erkennt, wird das Autocreate gestartet und mit dem Befehl "h" (0x68) der Modultyp abgefragt.
Das Autocreate funktioniert nur wenn das Modul auf den h-Befehl mit dem korrektem Modultyp antwortet. Dies müsstest Du in der Debug Ausgabe verfolgen können.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 19 Juli 2015, 21:01:27
Zitat von: mago0211 am 19 Juli 2015, 19:56:18
Wo finde ich die Version von honk?
hier ist das Git von honk. Der peering branch ist der aktuelle.
https://github.com/hresalg/FHEM-HM485

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 Juli 2015, 21:46:40
Zitat von: stephan-221 am 19 Juli 2015, 19:52:22Jetzt hilf mal einem newbie für Arduino... WTF ist der Hauptsketch? quasi die .ino Datei?
In meinem Fall dann die umbenannte HBW-1W-T10.ino?

Ich habe in dieser Datei jetzt hmwmodule = new HMWModule(&hmwdevice, &hmwrs485, 0x81);
eingetragen. Bringt aber bisher folgende Fehlermeldung:
HBW-1W-T10:26: error: 'hmwmodule' does not name a type
'hmwmodule' does not name a type


eine HMWRegister.h kenne ich nicht.
Hi,
was Ralf9 sagt gilt für den HBW-1W-T10 nicht. Ich habe das Teil geschrieben und auch so ziemlich den Rest vom HM-Wired-Arduino-Kram.
Könntest Du mal meinen Post betrachten?
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 Juli 2015, 21:48:42
Zitat von: mago0211 am 19 Juli 2015, 19:56:18Auf dem Testsystem habe ich die aktuelle Version von gevoo aus dem Git geladen.
Mit der funktioniert es auch, inklusive autocreate. Das Problem muss woanders liegen.
Gehe mal meinen langen Post von vorher durch.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 19 Juli 2015, 22:23:27
Hallo Thorsten,


Zitat von: Thorsten Pferdekaemper am 19 Juli 2015, 20:31:43
Das freut mich.
Also ich habe gerade auf einem Arduino Uno den Kram draufgepackt und es hat bei meinem Test-FHEM auf Anhieb funktioniert.
Beim automatischen Anlegen der Kanäle gibt es noch Probleme in der FHEM-Integration. Du musst einmal "get <device> config all" machen und dann ein paar Sekunden warten. Dann ein Refresh auf die FHEM-Oberfläche und die Kanäle müssten erscheinen.

Zweiter Schritt. Es liegt ja erstmal an dem Device File

Zitat
Ach ja: Hast Du das Gerät in FHEM manuell angelegt? Es sollte eigentlich per Autocreate gehen.
Außerdem: Neuste HM485-Version in FHEM? Hol Dir mal im Zweifelsfall den Kram von hier: https://github.com/kc-GitHub/FHEM-HM485/archive/master.zip (https://github.com/kc-GitHub/FHEM-HM485/archive/master.zip)

Neueste Version von gevoo (141)


Zitat
Ok, da war die Vermutung, dass das Device File nicht richtig gelesen wurde. Das glaube ich allerdings nicht so ganz. Man weiß aber nie.
Das ist vom FHEM-Start. Könntest Du mal nachschauen, ob da was faul ist? hbw_1w_t10.pm sollte zu finden sein.

Ja ist zu sehen. Und laut Code sollte da auch Fehlermeldungen erscheinen, wenn die Files korrupt sind.

2015.07.19 20:25:03 3: HM485: HM485: Loading available device files
2015.07.19 20:25:03 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hbw_1w_t10.pm
2015.07.19 20:25:03 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hbw_sen_ep.pm
2015.07.19 20:25:04 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw-sen-sc-12.pm
2015.07.19 20:25:04 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_central.pm
2015.07.19 20:25:04 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_generic.pm
2015.07.19 20:25:04 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_fm.pm
2015.07.19 20:25:04 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw14_dr.pm
2015.07.19 20:25:04 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr.pm
2015.07.19 20:25:04 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr_V3_02.pm
2015.07.19 20:25:04 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_12_fm.pm
2015.07.19 20:25:04 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm.pm
2015.07.19 20:25:04 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm_V3_02.pm
2015.07.19 20:25:04 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_sr_fm.pm
2015.07.19 20:25:04 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr.pm
2015.07.19 20:25:05 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr_V3_02.pm
2015.07.19 20:25:05 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_dim1l_dr.pm
2015.07.19 20:25:05 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr.pm
2015.07.19 20:25:05 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr_V3_02.pm
2015.07.19 20:25:05 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_sen_sc_12_dr.pm
2015.07.19 20:25:05 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_virtual.pm


Und unter FHEM sehe ich auch bei model, dass ich HBW-xxx nicht auswählen kann. Wie oben von Markus erwähnt.
Es sollte also noch irgendwas in FHEM nicht stimmen.

ZitatVielleicht ist auch was an der Kommunikation faul. Hast Du das SoftwareSerial.cpp von https://github.com/kc-GitHub/HM485-Lib/tree/thorsten (https://github.com/kc-GitHub/HM485-Lib/tree/thorsten) oder das Standard-Arduino-SoftwareSerial.cpp?

Ich habe die SoftSerial aus dem github zip file in Arduino kopiert und das Original so ersetzt. Ohne hagelt es glaube ich Fehlermeldungen.


ZitatAnsonsten: Übersetze den Sketch mal mit #define DEBUG_VERSION DEBUG_UNO und RS485 an Pins 5/6 (siehe Arduino Coding). Dann Serial Monitor einschalten. Lösche das Device aus FHEM und drücke danach reset auf dem Arduino. Könntest Du mir mal schicken, was der Serial Monitor dann anzeigt?

Task für morgen ;-)

Das mit der Seriennummer gucke ich mir danach an.
Erstmal einen Baustein ans Laufen bringen.

Viele Grüße
Stephan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 19 Juli 2015, 22:26:33
Zitat von: Ralf9 am 19 Juli 2015, 20:56:44
Ich bin genauso wie ihr ein newbie für Arduino. Ein Homebrew Modul mit den Dateien vom Git nachzubauen ist sehr mühsam.
Ja die .ino Datei ist der Hauptsketch.
Na da bin ich ja froh :-)   Habe unter Arduino bisher erst die Qlockthree gebaut. Ansonsten vorher mit WinAVR bzw. Bascom gespielt.

Zitat
Diese Zeile müsste eigentlich schon in der ino Datei bei void setup() drinstehen
https://github.com/kc-GitHub/HM485-Lib/blob/thorsten/HBW-1W-T10/HBW-1W-T10.cpp
Ist sie auch, wenn man mal richtig danach sucht :-)

ZitatNormalerweise wird ein Modul automatisch angelegt.
Wenn fhem einen Tastendruck erkennt, wird das Autocreate gestartet und mit dem Befehl "h" (0x68) der Modultyp abgefragt.
Das Autocreate funktioniert nur wenn das Modul auf den h-Befehl mit dem korrektem Modultyp antwortet. Dies müsstest Du in der Debug Ausgabe verfolgen können.
Das schien auch zu klappen. Allerdings fehlen ja die Definitionen.
2015.07.19 22:03:52 3: HM485: Initialisierungsfehler 42FFFFFF ModelName noch nicht vorhanden
2015.07.19 22:03:52 3: HM485: Initialisierung von Modul 42FFFFFF


Viele Grüße
Stephan

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 Juli 2015, 22:52:13
Zitat von: stephan-221 am 19 Juli 2015, 22:23:27Zweiter Schritt. Es liegt ja erstmal an dem Device File

Neueste Version von gevoo (141)

D.h. Du hast fast mein Setup und bei mir geht es, aber bei Dir nicht.
Kannst Du mal das hier dranhängende Device-File nehmen? Vielleicht hast Du irgendwoher was Faules.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 19 Juli 2015, 23:13:44
Hallo Thorsten,

Volltreffer.

Die Dateien waren schon unterschiedlich groß.
Device wurde nach Neustart schon besser erkannt. Da es halb drin war, hab ich es gelöscht und siehe da. Automatisch angelegt und die Channels kamen auch nach ner Minute.

Ich habe die ganze Sammlung der HBWs hier runtergeladen. Da war auch das Devicefile enthalten:

https://github.com/kc-GitHub/HM485-Lib/tree/thorsten/HBW-1W-T10


Dann kann ich mich morgen an den Rest machen und das Thema Seriennummer betrachten :-)


Viele Grüße
Stephan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 Juli 2015, 23:45:50
Zitat von: stephan-221 am 19 Juli 2015, 23:13:44
Ich habe die ganze Sammlung der HBWs hier runtergeladen. Da war auch das Devicefile enthalten:

https://github.com/kc-GitHub/HM485-Lib/tree/thorsten/HBW-1W-T10
Seltsam, genau das habe ich Dir auch gerade geschickt...
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 20 Juli 2015, 07:12:27
Hallo Thorsten,

sehr verwirrend.

Also wenn ich das komplette Zip von dir ziehe, dann habe ich da eine .pm drin mit ~ 7kb:
https://github.com/kc-GitHub/HM485-Lib/archive/thorsten.zip

Wenn ich das Zip von Markus nehme, habe ich die Datei, mit der es funktioniert mit ~ 5kb:
https://github.com/kc-GitHub/HM485-Lib/archive/markus.zip

Mir sind die unterschiedlichen Branches erst gar nicht aufgefallen.

Muss ich mir im Detail anschauen ;-)

Viele Grüße
Stephan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 20 Juli 2015, 09:56:10
Zitat von: stephan-221 am 20 Juli 2015, 07:12:27Also wenn ich das komplette Zip von dir ziehe, dann habe ich da eine .pm drin mit ~ 7kb:
https://github.com/kc-GitHub/HM485-Lib/archive/thorsten.zip

Wenn ich das Zip von Markus nehme, habe ich die Datei, mit der es funktioniert mit ~ 5kb:
https://github.com/kc-GitHub/HM485-Lib/archive/markus.zip
Ich kann nicht wirklich glauben, dass es mit der Version von Markus funktioniert. Das, was da drin steht, ist definitiv falsch. Das aus "meinem" zip ist die richtige Version.
Mit den verschiedenen Branches ist es tatsächlich etwas blöd. Ich habe das mal hier aufgelistet: http://www.fhemwiki.de/wiki/HomeMatic_Wired (http://www.fhemwiki.de/wiki/HomeMatic_Wired) (ganz nach unten scrollen). Unter "Firmware" findest Du den hoffentlich richtigen Ort für das jeweilige Device. Auch wenn es im entsprechenden Branch so aussieht, als ob da auch andere Devices wären, dann muss das nicht unbedingt funktionieren.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 20 Juli 2015, 10:52:23
ZitatIch kann nicht wirklich glauben, dass es mit der Version von Markus funktioniert. Das, was da drin steht, ist definitiv falsch. Das aus "meinem" zip ist die richtige Version.

Hallo Thorsten,

wird wahrscheinlich so sein. Ich prüfe das heute Abend in Ruhe.
EDIT: Es ist genauso! Mit deinem File gehts!

Ich habe die Downloads auch via  http://www.fhemwiki.de/wiki/HomeMatic_Wired gemacht. Allerdings habe ich an zwei verschiedenen Rechnern gearbeitet. Und da ich auch den HBW-Sen-EP Nachbauen will, habe ich auf einem der Rechner wohl Markus Version runtergeladen.

Der Fehler sitzt also wohl vorm Bildschirm ;-)

Viele Grüße
Stephan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 24 Juli 2015, 00:31:25
Ich habe jetzt auch mal die 10_HM485.pm von Thorsten mit einem Homebrew Modul mit Tastereingängen getestet.
Dabei ist mir aufgefallen, das in der Kanalübersicht im subType key beim drücken einer Taste der state nicht angezeigt wird. Ist dies bei euch auch so?
Wenn ich in der "10_HM485.pm" in der "sub HM485_ChannelDoUpdate" die folgende Zeile auskommentiere, funktioniert es.

# if ( defined( $chHash->{STATE}) && $chHash->{STATE}) {


Ich habe auch mal die aktuelle Version von honk getestet, dort funktioniert es. Mir ist aufgefallen das dort
"press_short 33" anstatt "press_short_press_short 33" angezeigt wird.

@honk wo hast Du das geändert, ich finde das so schöner.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 24 Juli 2015, 09:39:34
Zitat von: Ralf9 am 24 Juli 2015, 00:31:25
Ich habe jetzt auch mal die 10_HM485.pm von Thorsten mit einem Homebrew Modul mit Tastereingängen getestet.

Hi,
ich denke, dass ist jetzt etwas off-Topic, aber dennoch wichtig. Ich habe es daher in einen neuen Thread verlagert:
http://forum.fhem.de/index.php/topic,39397.0.html (http://forum.fhem.de/index.php/topic,39397.0.html)
Könnten wir das dort diskutieren?
Danke&Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 28 Juli 2015, 11:57:50
Hi,
ich (nicht nur ich) hatte das Problem, dass die HBW-Devices sich auf dem Bus nicht gerade "nett" verhalten. D.h. sie senden auch, wenn eigentlich auf dem Bus schon was los ist. Ich habe das jetzt in der Lib geändert, so dass beim "selbst-initiierten" Senden der Bus 210 bis 310 MS frei gewesen sein muss, bevor losgelegt wird. Die neue Version ist wie immer in https://github.com/kc-GitHub/HM485-Lib/tree/thorsten (https://github.com/kc-GitHub/HM485-Lib/tree/thorsten).
Es sind auch noch ein paar andere Kleinigkeiten drin, und nicht alles ist 100% abwärtskompatibel. Sorry for that...
Ich weiß nicht so recht, ob die Lösung ganz perfekt ist. Es kann vorkommen, dass Tastendrücke etwas verzögert gesendet werden, aber ich weiß momentan auch nichts besseres. Vorher war es so, dass das ganze System fast zwangsläufig in Response Timeouts gerannt ist.
Die Devices HBW-1W-T10 und HBW-Sen-EP sind an die Änderungen angepasst, wobei ich nur HBW-1W-T10 getestet habe.
Ich rate aber dringend, andere Devices auch anzupassen, da es wie gesagt zu Fehlern kommt.
Gruß,
   Thorsten


Hier sind die Änderungen im Detail:
HBW-1W-T10:
1. DEBUG_VERSION ist per Default jetzt DEBUG_NONE
2. Anpassung auf Änderungen in HMWModule (siehe unten)
3. Announce Message am Anfang wird erst nach 1 Sekunde gesendet und
"wartet" bis der Bus frei ist
4. Beim Senden der Temperaturen wird gewartet, bis der Bus frei ist
5. Drei verschiedene hex-Files zur Verfügung gestellt

HBW-Sen-EP:
1. DEBUG_VERSION ist per Default jetzt DEBUG_NONE
2. Anpassung auf Änderungen in HMWModule (siehe unten)
3. Announce Message am Anfang wird erst nach 1 Sekunde gesendet und
"wartet" bis der Bus frei ist
4. Beim Senden der Zählerstände wird gewartet, bis der Bus frei ist

HMWModule:
1. Im getLevel-Callback wird jetzt das Kommando, welches zum getLevel
geführt hat, mitgeschickt. D.h. normalerweise 0x53 oder 0x78.
2. Es gibt jetzt ein zweites setLevel-Callback, das nicht nur unsigned
int kann. Beide callbacks werden momentan aufgerufen.
3. broadcastAnnounce, broadcastKeyEvent und sendInfoMessage senden nur
noch, wenn der Bus frei ist (seit random(210,310) ms). Diese Methoden
haben jetzt auch einen Rückgabewert (0: ok, gesendet; 1: Bus busy; 2:
Sendefehler)

HMWRS485:
1. SendFrame hat einen neuen Parameter (optional). Wenn gesetzt, dann
sendet es nur noch, wenn der Bus frei ist. Außerdem gibt es einen
Rückgabeparameter, siehe oben.
2. Attribut txSenderAddress umbenannt in ownAddress und private gemacht.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: BrainHunter am 28 Juli 2015, 20:00:12
Hallo Thorsten,

jetzt melde ich mich auch mal wieder zu Wort ;-)
Sehr cool das du die neuen Funktionen in die HMW Lib eingebaut hast! Ich habe den Branch gleich mal ausgecheckt und in meinen RGB Controller mit eingebaut. Dabei ist mir beim Mergen etwas aufgefallen:

Code (HMWModule.cpp) Auswählen

hmwrs485->txFrameData[2] = info / 0x100;
hmwrs485->txFrameData[3] = info & 0xFF;

sollte das nicht eher andersrum sein? also:
Code (Vorschlag) Auswählen

hmwrs485->txFrameData[2] = info & 0xFF;
hmwrs485->txFrameData[3] = info / 0x100;

so wegen Big endianes... Fällt das gerade nur mir auf die Füße oder warum ist das so?

Dann noch ein etwas anderes Thema:
Ich verwende ja einen 32biter für den Controller. Da ist ein int nun mal 32bit breit und nicht wie beim avrgcc 16bit.
In der ganzen HMW-Lib wird durchgängig mit int, unsigned int, long... gearbeitet. Ich habe das ganze mal umgeschrieben auf (u)int16_t, (u)int32_t... Gerade bei Protokollen ist es oft wichtig das auch wirklich die richtige Breite des Datentyps verwendet wird. Ich würde dir das ganze als Pull Request zurückspielen wenn du nichts dagegen hast das mit einzupflegen.
Mir ist das ganze bei der CRC routine aufgefallen, weil die mit einem 32bit int nicht mehr richtig rechnet ;-)

grüße Nico
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 29 Juli 2015, 06:46:09
Hallo Thorsten,

Ich bin aktuell gerade unterwegs, so dass ich erst am Wochenende dazu komme
beide Modul Typen zu aktualisieren.

Von meinen zwei 1W-T10 Modulen habe ich das Response Timeout Problem immer bei ein und dem selbem Modul.
Obwohl beide identisch sind. Mal sehen wie sich das danach entwickelt.


Viele Grüße
Stephan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 30 Juli 2015, 21:33:35
Hi,
es gibt jetzt wieder mal eine neue Version der Lib. Siehe wie üblich hier: https://github.com/kc-GitHub/HM485-Lib/tree/thorsten (https://github.com/kc-GitHub/HM485-Lib/tree/thorsten).
Nachdem wir festgestellt hatten, dass alle Original-HMW-Module auf ein 0x73 mit einem 0x69 antworten habe ich das auch so implementiert. D.h. es gibt jetzt keinen Unterschied mehr zwischen einem Set mit "s" (0x73) oder "x" (0x78).
Die hex-Files habe ich nicht neu erzeugt, da die Änderung zumindest mit der aktuellen FHEM-Integration nicht wirklich etwas ändert.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 30 Juli 2015, 21:49:33
Zitat von: BrainHunter am 28 Juli 2015, 20:00:12
Code (HMWModule.cpp) Auswählen

hmwrs485->txFrameData[2] = info / 0x100;
hmwrs485->txFrameData[3] = info & 0xFF;

sollte das nicht eher andersrum sein? also:
Code (Vorschlag) Auswählen

hmwrs485->txFrameData[2] = info & 0xFF;
hmwrs485->txFrameData[3] = info / 0x100;

so wegen Big endianes... Fällt das gerade nur mir auf die Füße oder warum ist das so?
Mir fällt gerade kein richtiger Grund ein, warum das so ist. Eigentlich habe ich gar kein Device, das einen echten 16-Bit int liefert. Der HMW-LC-Sw2-DR, mit dem ich angefangen habe, liefert zuerst den Status eines Kanals und dann ein paar Bit Statusinformation (die anscheinend immer 0 sind). Irgendwie musste ich das dann in eine Variable packen. Ob jetzt big oder small endian war dann eher Zufall.
Wahrscheinlich mache ich das mal etwas flexibler, so dass das einfach ein Byte-Array wird.

Zitat
Ich verwende ja einen 32biter für den Controller. Da ist ein int nun mal 32bit breit und nicht wie beim avrgcc 16bit.
In der ganzen HMW-Lib wird durchgängig mit int, unsigned int, long... gearbeitet. Ich habe das ganze mal umgeschrieben auf (u)int16_t, (u)int32_t... Gerade bei Protokollen ist es oft wichtig das auch wirklich die richtige Breite des Datentyps verwendet wird. Ich würde dir das ganze als Pull Request zurückspielen wenn du nichts dagegen hast das mit einzupflegen.
Ja, schick mir den Request, dann baue ich das ein.

Gruß,
   Thorsten

EDIT: Jetzt fällt's mir wieder ein, warum das mit dem Level so ist. Für den HBW-1W-T10 habe ich mit einer CCU experimentiert. Das hat erst funktioniert, als ich die Temperaturen genau so geschickt habe. Deshalb ist es so. Anscheinend ist der Default bei HMW also Little Endian. 
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 31 Juli 2015, 21:28:52
Zitat von: BrainHunter am 28 Juli 2015, 20:00:12Ich verwende ja einen 32biter für den Controller. Da ist ein int nun mal 32bit breit und nicht wie beim avrgcc 16bit.
In der ganzen HMW-Lib wird durchgängig mit int, unsigned int, long... gearbeitet. Ich habe das ganze mal umgeschrieben auf (u)int16_t, (u)int32_t... Gerade bei Protokollen ist es oft wichtig das auch wirklich die richtige Breite des Datentyps verwendet wird. Ich würde dir das ganze als Pull Request zurückspielen wenn du nichts dagegen hast das mit einzupflegen.
Dein Pull Request ist drin. Ich habe auch mal zwei Module damit compiliert und es gab keine Probleme. Zumindest auf 16-Bit Arduinos sind die Datentypen kompatibel.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: BrainHunter am 01 August 2015, 12:11:06
Zitat von: Thorsten Pferdekaemper am 31 Juli 2015, 21:28:52
Ich habe auch mal zwei Module damit compiliert und es gab keine Probleme. Zumindest auf 16-Bit Arduinos sind die Datentypen kompatibel.
Sehr gut! ich habe extra darauf geachtet die Datentypen so zu ändern, dass sie in der breite dem entsprechen was der avrgcc gemacht hat.

grüße Nico
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 01 August 2015, 15:12:17
Hallo Thorsten,

ich habe seit gestern drei HBW Module aktualisiert.
1 * HBW-Sen-EP
2 * HBW-1W-T10

Insgesamt hängen noch 5 reguläre HMW Module am Bus.

Ich habe keine Response Timeouts mehr. Und die Konfig kann auch immer ausgelesen werden und geht auf "OK".

Viele Grüße
Stephan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 01 August 2015, 15:53:07
Zitat von: stephan-221 am 01 August 2015, 15:12:17
Ich habe keine Response Timeouts mehr. Und die Konfig kann auch immer ausgelesen werden und geht auf "OK".
Das klingt ja sehr gut. Danke für die Rückmeldung!
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 02 August 2015, 11:54:34
Hi,
ich habe begonnen, die Versionen "honk" und "gevoo/thorsten" der FHEM-Integration zusammenzuführen. Das wichtigste dazu: Bitte die "dev"-Version nicht mehr produktiv einsetzen, aber ich hoffe auf viele Tester.
Für manche Homebrew-Devices müssen vielleicht die <device>.pm-Dateien geändert werden, falls sie "option" Elemente enthalten.
Details dazu hier:
http://forum.fhem.de/index.php/topic,39643.0.html (http://forum.fhem.de/index.php/topic,39643.0.html)
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Maxl am 17 August 2015, 14:45:54
Hallo,

nur eine kurze Frage für Anfänger. Wenn ich mir das Repository vom Github herunterlade und die Library unter Arduiono einbinde, welches File soll ich dann zum kompilieren öffnen, da ich keine ino-Datei finde oder kompiliert man das ganze mit einen anderen Kompiler?

Gruß
Mario
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 17 August 2015, 14:52:13
Zitat von: Maxl am 17 August 2015, 14:45:54
nur eine kurze Frage für Anfänger. Wenn ich mir das Repository vom Github herunterlade und die Library unter Arduiono einbinde, welches File soll ich dann zum kompilieren öffnen, da ich keine ino-Datei finde oder kompiliert man das ganze mit einen anderen Kompiler?
Hi,
ich mache das immer mit Eclipse, aber es haben wohl auch schon welche mit der Arduino IDE geschafft.
Die Haupt-Datei ist normalerweise eine mit Endung cpp und dem Device-Type als Name, also z.B. "HBW-1W-T10.cpp". Es kommt dabei halt darauf an, welches Device Du nachbauen willst.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Maxl am 17 August 2015, 15:45:17
Hallo Thorsten,

Eclipse ist auch kein Problem, ist das dann Eclipse mit WinAVR?
Hätte das ganze Zeugs unter dem AVR Studio versucht zu kompilieren, dies beschwert sich aber immer das es einiges nicht findet.
Könntest du mir einmal ein Beispiel-Projekt zukommen lassen welches man unter Eclipse kompilieren kann.

Gruß
Mario

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 17 August 2015, 17:27:45
Zitat von: Maxl am 17 August 2015, 15:45:17
Eclipse ist auch kein Problem, ist das dann Eclipse mit WinAVR?
Ich glaube nicht. Help-> About sagt bei mir:
  Arduino eclipse extensions   2.2.0.1   it.baeyens.arduino.feature.feature.group   jan Baeyens
Das holt sich manche Sachen aus der Arduino-IDE und ich bin mir nicht ganz sicher, ob das mit der aktuellen IDE funktioniert. Zur Not musst Du Dir halt eine ältere Installieren.

Zitat
Könntest du mir einmal ein Beispiel-Projekt zukommen lassen welches man unter Eclipse kompilieren kann.
Siehe Anhang.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Maxl am 21 Dezember 2015, 20:54:04
Hallo Thorsten,

nach langem habe ich wieder Zeit. Habe nun die EclipseArduino IDE installiert mit dem it.baeyens 2.4 plugin. Wenn ich nun das damalige Beispielprojekt von dir importieren möchte, was soll ich wählen  C/C++; Arduino; ... nachher bekomme ich nur laufend Fehlermeldungen ...not valid for this board.

Könntest du mir genauer erklären welche IDE, welche Version von Arduino usw. ich installieren soll.



Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 Dezember 2015, 17:35:43
Zitat von: Maxl am 21 Dezember 2015, 20:54:04nach langem habe ich wieder Zeit. Habe nun die EclipseArduino IDE installiert mit dem it.baeyens 2.4 plugin. Wenn ich nun das damalige Beispielprojekt von dir importieren möchte, was soll ich wählen  C/C++; Arduino; ... nachher bekomme ich nur laufend Fehlermeldungen ...not valid for this board.

Könntest du mir genauer erklären welche IDE, welche Version von Arduino usw. ich installieren soll.
Also der baeyens-Kram hat bei mir 2.2.0.1. Meine Arduino-IDE ist 1.5.6-r2. Ich weiß aber nicht, ob Deine Probleme tatsächlich daher kommen.
Wie man Projekte in Eclipse importiert weiß ich auch nicht. Ich mache mir immer ein neues und packe dann die Dateien entsprechend rein. Im Zweifelsfall würde ich aber "Arduino" wählen.
Dann ist es ganz wichtig, dass Du unter Properties-> Arduino das richtige Board etc. wählst.
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Maxl am 23 Dezember 2015, 08:14:03
Hallo,

nur noch eine Frage, unter welchen Betriebssystem läuft das Ganze bei dir.

Danke
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 23 Dezember 2015, 10:25:05
Zitat von: Maxl am 23 Dezember 2015, 08:14:03nur noch eine Frage, unter welchen Betriebssystem läuft das Ganze bei dir.
Windows 7 Professional 64 Bit
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: StefanGa am 10 Februar 2016, 17:42:13
Hallo Homematic Homebrewers,

ich habe gerade den 1 Wire Sensor aufgebaut und zum Laufen gebracht.
Danke für Eure Arbeit!

Was ich aber wirklich brauche ist der 4-fach Rolladenaktor (gerne auch ein 8-fach).
Gibt es eine funktionierende XML Datei dafür? (HBW_lc_bl4.xml ??)

Oder steht irgendwo beschrieben, wie man aus der pm eine XML machen kann?

Danke Euch
Stefan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 10 Februar 2016, 21:54:31
Zitat von: StefanGa am 10 Februar 2016, 17:42:13
Was ich aber wirklich brauche ist der 4-fach Rolladenaktor (gerne auch ein 8-fach).
Gibt es eine funktionierende XML Datei dafür? (HBW_lc_bl4.xml ??)
Wozu? Für FHEM braucht man das nicht...
Ansonsten versuch's mal mit dem XML vom Standard-Rollladenaktor und mach aus dem einen Kanal einfach 4.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: StefanGa am 11 Februar 2016, 18:04:51
Zitat von: Thorsten Pferdekaemper am 10 Februar 2016, 21:54:31
Wozu? Für FHEM braucht man das nicht...
Ansonsten versuch's mal mit dem XML vom Standard-Rollladenaktor und mach aus dem einen Kanal einfach 4.
Gruß,
   Thorsten
Hallo,
noch nutze ich die CCU und dazu brauche ich die xml- Datei.
In diesem Thread hatte ich etwas von der Datei gelesen, sie aber nirgends gefunden.
Wenn es die irgendwo gibt, wäre es super wenn ich die kriegen kann.
Beste Grüße
Stefan

Gesendet von meinem GT-I9300 mit Tapatalk

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Maxl am 11 Februar 2016, 21:25:43
Hallo Stefan,

Zitatich habe gerade den 1 Wire Sensor aufgebaut und zum Laufen gebracht.

mit welcher Version von Arduino und Eclipse hast du das zum Laufen gebracht,
bei mir kommen immer noch eine Menge Fehler und weiß nicht wie ich die weg bekomme.

Gruß
Mario
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: StefanGa am 11 Februar 2016, 21:50:14
Ich habe es mit der Arduino IDE hinbekommen. Dazu muss man die Dateien HMWDebug, HMWModule und HMWRS485 (cpp und h) in einen Ordner kopieren und diesen als Library dem Sketch hinzufügen.
Dann sollten alle Fehler weg sein.
Grüße
Stefan

Gesendet von meinem GT-I9300 mit Tapatalk

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Maxl am 12 Februar 2016, 09:20:08
Noch was,

welche Dateien verwendest du, die aus
https://github.com/kc-GitHub/HM485-Lib/tree/thorsten
oder andere?
Könntest du mir deine HMW-Lib gepackt  einmal zusenden?

Danke
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: StefanGa am 12 Februar 2016, 12:53:51
Hallo,

das hat bei mir auch nicht auf Anhieb geklappt.
War ein bisschen Frickelei.
UND: die Pinbelegung, die im Header der Datei steht, stimmt zum Teil nicht.
Da muss man im Code nachschauen (z.B. für den Taster).

Viel Spaß damit und Dank an die Autoren!

Stefan

Edit:
ACHTUNG in die library muss noch die Softserial.cpp und Softserial.h aus Thorstens library damit es auch am Bus funktioniert.
So, wie es hier ist, lässt es sich zwar kompilieren. In dem Monitor bekommt man aber Fehlermeldungen wie packet size to big.
Dann die Softserial-Dateiuen reinkopiert und dann hat es bei mir funktioniert.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Regmus am 06 Mai 2016, 12:49:40
Hallo zusammen,

ich habe mich in den letzten Wochen auch mit den Homebrew-Devices beschäftigt.
Nach ein paar Anfangsschwierigkeiten mit der Arduino-IDE Version (mit der neusten Version 1.6.8 schlug die Kompilierung schon fehl) habe ich nun den HBW-Sen-SC8 zum laufen gebracht.
Den "HBW-LC-Bl4" oder den "HBW-LC-Sw8" jedoch leider nicht. Kann zwar den Arduino mit dem Programm bespielen - FHEM erkennt jedoch das Gerät nicht richtig. Es wird zwar etwas am Bus erkannt, aber nicht wie beim HBW-Sen-SC als Gerät mit dem richtigen Namen. Ein autocreate der Kanäle wird dann auch nicht ausgeführt.
Die .pm-Datei habe ich, wie beim HBW-Sen-SC8 auch, in das entsprechende Verzeichnis gelegt. Daran sollte es also eigentlich nicht liegen dürfen...

Hat jemand eine Idee woran das Ganze bei mir scheitern könnte? Gibt es evtl. bekannte Probleme bei der aktuellsten FHEM Version oder ähnliches?
Laufen diese Versionen überhaupt bei jemandem?

Viele Grüße
Michael
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 06 Mai 2016, 19:05:03
Zitat von: Regmus am 06 Mai 2016, 12:49:40
Den "HBW-LC-Bl4" oder den "HBW-LC-Sw8" jedoch leider nicht. Kann zwar den Arduino mit dem Programm bespielen - FHEM erkennt jedoch das Gerät nicht richtig. Es wird zwar etwas am Bus erkannt, aber nicht wie beim HBW-Sen-SC als Gerät mit dem richtigen Namen. Ein autocreate der Kanäle wird dann auch nicht ausgeführt.
Die .pm-Datei habe ich, wie beim HBW-Sen-SC8 auch, in das entsprechende Verzeichnis gelegt. Daran sollte es also eigentlich nicht liegen dürfen...

Hat jemand eine Idee woran das Ganze bei mir scheitern könnte? Gibt es evtl. bekannte Probleme bei der aktuellsten FHEM Version oder ähnliches?
Laufen diese Versionen überhaupt bei jemandem?

Ja, das ist mir auch schon aufgefallen, daß nicht mehr alle Homebrew-Devices  funktionieren.
Dies dürfte damit zusammenhängen:
<device>.pm geändert: Options sind jetzt Arrays. ...und einiges mehr
committed on 2 Aug 2015

https://github.com/kc-GitHub/FHEM-HM485/commit/7251e5a97888e2026db9ec94a9d1c983d8d7af82 (https://github.com/kc-GitHub/FHEM-HM485/commit/7251e5a97888e2026db9ec94a9d1c983d8d7af82)

Es wird wahrscheinlich die Homebrew-Devices betreffen, deren <device>.pm option-Felder enthalten. Diese <device>.pm files müssten angepasst werden, damit es wieder funktioniert.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 06 Mai 2016, 20:46:21
Hi,
im Prinzip ist es so gedacht, dass man sich die XML-Dateien zusammenbastelt und dann per Programm in die pm-Dateien umwandelt.
Ich schau mir das mal für die zwei Devices genauer an und melde mich wieder.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 06 Mai 2016, 22:46:47
Hi,
hier angehängt ist die XML- und pm-Datei für den HBW-LC-Bl4. Das sieht zumindest in FHEM ganz vernünftig aus, ich habe allerdings nicht ausprobiert, ob das Device auch tatsächlich korrekt funktioniert.
Die XML-Datei müsste eigentlich stabil bleiben. Die pm-Datei kann man nachgenerieren. In einer typischen RasPi-FHEM-Installation geht das so:

cd /opt/fhem/FHEM/lib/HM485/helper
./xmlHelper.pl -inputFile ../Devices/xml/hbw_lc_bl4.xml -outputPath ../Devices

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 07 Mai 2016, 22:06:01
Hallo zusammen,

dass die pm-Files nicht mehr mit der neusten FHEM-Version laufen, hatte ich vor einiger Zeit auch schon festgestellt. Für die meisten HBW-Module habe ich mittlerweile neue pm-Files erstellt und auch noch ein paar Kleinigkeiten geändert. Wegen dem Stress beim Hausbau bin ich bisher allerdings noch nicht dazu gekommen, alles zu dokumentieren und bei Github online zu stellen. Dafür sind die Module jetzt einigermaßen getestet.

Die Bezeichnung für das Modul mit den Tastereingängen habe ich übrigens geändert, hier nochmal die Übersicht, welches Modul was macht:
HBW-LC-Bl4 (Bl=Blind) - Rollo-Steuerung
HBW-LC-Sw8 (Sw=Switch) - Schaltausgang, z.B. zur Relais-Ansteuerung
HBW-PB-12 (PB=Pushbutton) - Tastereingänge (vorher HBW-Sen-SC8)
HBW-Sen-SC12 (SC=Shutter Contact) - Fensterkontakte (neu)
HBW-Sen-EP (EP=Electric Pulse) - Impulse, z.B. vom Windmesser


Bei der Inbetriebnahme der Raffstores bin ich jetzt noch auf ein Problem gestoßen. Die Module verstehen den Toggle-Befehl 0xFF. Mit einer älteren Version von FHEM war es möglich, den Toggle-Befehl in FHEM zu konfigurieren:
attr R_Wohnzimmer eventMap /level 0:auf/level 100:ab/level 127.5:toggle/
Mit der Version 5.7 funktioniert das nicht mehr (vielleicht weil der Bereich "Level" nur 0 bis 100 annehmen kann?).

Kennt jemand eine Möglichkeit, solche Befehle in FHEM zu konfigurieren? Notlösung wäre ein RAW-Command über das Bus-Interface - ist aber keine besonders schöne Lösung...

Viele Grüße
Markus

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 09 Mai 2016, 16:48:42
Zitat von: MarkusO am 07 Mai 2016, 22:06:01
Bei der Inbetriebnahme der Raffstores bin ich jetzt noch auf ein Problem gestoßen. Die Module verstehen den Toggle-Befehl 0xFF. Mit einer älteren Version von FHEM war es möglich, den Toggle-Befehl in FHEM zu konfigurieren:
attr R_Wohnzimmer eventMap /level 0:auf/level 100:ab/level 127.5:toggle/
Mit der Version 5.7 funktioniert das nicht mehr (vielleicht weil der Bereich "Level" nur 0 bis 100 annehmen kann?).

Kennt jemand eine Möglichkeit, solche Befehle in FHEM zu konfigurieren? Notlösung wäre ein RAW-Command über das Bus-Interface - ist aber keine besonders schöne Lösung...
Hi,
"toggle" sollte man im XML-File definieren. (Bzw. im zugehoerigen .pm.) Schau Dir das mal z.B. im XML-File (oder .pm-File) zum HMW-LC-Sw2-DR an. Ich wollte das hier mit reinhaengen, habe aber meinen Laptop nicht dabei und habe keinen Zugriff auf den Kram. Wenn das Toggle entsprechend definiert ist (halt mit 255 statt 201), dann sollte es in FHEM direkt die Moeglichkeit geben, ein "set <channel> toggle" zu machen.
Gruss,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 09 Mai 2016, 22:53:20
Hi,
danke für den Hinweis. Das mit der Anpassung im pm-File hatte ich auch schon probiert - hat aber zunächst nicht funktioniert. Jetzt habe ich rausgefunden warum nicht:
- die Funktion darf nicht "toggle" heißen. In der Datei 10_HM485.pm wird darauf abgefragt.
} elsif ($cmd eq 'toggle') {
# toggle is a bit special
$msg = HM485_SetToggle($hash);


- die Funktion muss in der Datei Device.pm als mögliches Argument auftauchen:
my %cmdArgs = (
'none' => "noArg",
    'blind.level' => "slider,0,1,100 on:noArg off:noArg up:noArg down:noArg",
    'blind.stop' => "noArg",
                #neue Funktion:
'blind.updown' => "noArg",
    #
                'dimmer.level' => "slider,0,1,100 on:noArg off:noArg",
    'valve.level' => "slider,0,1,100 on:noArg off:noArg",
    'button.long' => "noArg",
    'button.short' => "noArg",
    'digital_analog_output.frequency' => "slider,0,1,50000",
);


Damit funktioniert die Toggle-Funktion und die Raffstores können mit nur einem Tastendruck rauf und runter bewegt werden. Dass man dafür auf die Device.pm anpassen muss, finde ich zwar nicht besonders elegant, aber immerhin läuft es damit.

Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 10 Mai 2016, 11:46:49
Hi,

das muss ich mir mal genauer anschauen, was leider diese Woche nicht moeglich ist. Es sollte eigentlich so sein, dass was auch immer im XML/pm-File definiert ist auch in FHEM funktionieren sollte. "Historisch bedingt" gibt es leider noch ein paar hart-codierte Sachen, die ich aber loswerden will. Ich habe mir fest vorgenommen, mich bald darum zu kuemmern, kann aber gerade nichts versprechen.

Ich habe zum "toggle" bei Rolloaktoren allerdings noch eine Frage: Was genau tut das eigentlich? Bei einem Schaltaktor ist es klar, da es nur zwei Zustaende gibt. Bei einem Rolloaktor (oder Dimmer) gibt es aber auch etwas wie z.B. "50%". Was macht das "toggle" in dem Fall?

Gruss,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 10 Mai 2016, 22:55:45
Hi,

die "Toggle"-Funktion ermöglicht es, den Rollo-Aktor mit nur einer Taste zu steuern. Jedes mal wenn als Level 0xFF empfangen wird, ändert sich der Zustand: hoch - stop - runter - stop - hoch - stop - runter ...
Oder anders gesagt, falls das Rollo gerade in Bewegung ist, bewirkt ein Tastendruck einen Stopp. Und falls das Rollo gerade steht, fährt es bei einem Tastendruck in die entgegengesetzte Richtung als beim letzten mal. Vielleicht ist die Bezeichnung "Toggle" nicht ganz glücklich gewählt...

Ich finde das ganz praktisch, weil man zuhause ein paar Tasten sparen kann und auf dem Smartphone nur ein Button pro Rollo notwendig ist und man nicht so schnell daneben drücken kann.

Ich habe übrigens noch einen Bug in der Rollo-Steuerung festgestellt: aktuell werden nur Fahrzeiten bis 65 Sekunden korrekt umgesetzt (wegen dem Datentyp int für die Zeiten = 65535ms). Werde ich demnächst beheben und zusätzlich noch die Funktion "auf Schlitz fahren" (für Raffstores) umsetzen.


Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: StefanGa am 12 Mai 2016, 10:26:52
Hallo,
da ich noch die CCU nutze, habe ich mal probiert den BL4 Aktor dort anzulernen.
UND es funktioniert. (mit Hilfe der XML-Datei)

Es gibt aber Fehler bei der Übertragung der Position.
Die CCU zeigt mir ein Bug-Symbol an oder die angezeigte Position springt nach einer Weile auf einen anderen Wert.
Habt Ihr mal das Protokoll von einem Originalaktor abgelauscht?
Irgendetwas scheint mit der Positionsübertragung nicht richtig zu funktionieren.

UND Wie funktioniert die Referenzfahrt nach Reset des Aktors?
Was muss ich dafür machen?

Danke
Stefan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Regmus am 12 Mai 2016, 16:02:34
Ihr seid wirklich der hammer!
Allerdings bekomme ich es leider trotzdem nicht zum laufen.
Habe es jetzt nochmal mit allen 5 neuen Modulen von Markus versucht, aber ich bekomme Sie nicht von FHEM erkannt.
Sind denn die Module alle mit dem Arduino Uno kompatibel? Habe aktuell nur diesen im Einsatz. Habe es direkt mit der HEX und auch mit den source-Dateien versucht.
Bekomme im HM_LAN.log immer crc-Fehler...


2016.05.12 13:41:18.197 3: HM485d: Rx: data -> crc error I[0](1,Y,F)(B0)  -> 33 [2] {3979}
2016.05.12 13:41:19.023 3: HM485d: Rx: data -> crc error I[3](0,Y,F)(96)  -> 59 [49] 21(!) ABDBC829AAC83B3838A0FFFF276B6F4EE152B53EF9F701773C3976E94EDBFF5D71BA7BB3E20530B47B9A2F91BD20 {E436}
2016.05.12 13:41:19.348 3: HM485d: Rx: data -> crc errorACK(0,B)(19)  -> A2 [26] 24($) BCA57D2E6A3F21BABABAB9F130D8A238F5356175B82918 {34EE}
2016.05.12 13:41:19.489 3: HM485d: Rx: data -> crc errorDISCOVERY(8) 00000000 -> A8
2016.05.12 13:41:19.627 3: HM485d: Rx: data -> crc error(2)(C5)  -> B0 [8] B8(�) 39A8F3733A {E9B3}
2016.05.12 13:41:19.777 3: HM485d: Rx: data -> crc error I[0](1)(20)  -> 65 [51] 33(3) 61546548002AC8B1B190E0131AFFE2F230A82D13184FED2C0D58DEC9310A2761FF606456B9A52F30A330AA21CC0AAEAD {8860}
2016.05.12 13:41:19.870 3: HM485d: Rx: data -> crc errorDISCOVERY(9) 00000000 -> 66
2016.05.12 13:41:19.923 3: HM485d: Rx: data -> crc error(1)(37)  -> E8 [41] 77(w) 27F62DC301BA60BDABE820B8AB6EFFEC293B31E8B3723728F3AC6F186C7ADA75FFF4A0EFC133 {38B9}
2016.05.12 13:41:21.115 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 0008353B -> FFFFFFFF [18] 41(A) 008200030648425730353337393135 {2582}
2016.05.12 13:41:21.116 4: HM485d: Tx: FD1B0065FFFFFFFFF80008353B41008200030648425730353337393135


Kann mir da vielleicht noch jemand helfen? Haben die crc-Fehler überhaupt etwas mit der Erkennung eines neuen Gerätes zu tun? Muss ich den FHEM irgendwie auf eine bestimmte Art und Weise neu starten wenn ich ein neues Modul am Bus angeschlossen habe?
Bin mit meinem "Anfänger-Latein" am Ende... :-/
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusO am 12 Mai 2016, 22:03:54
Hallo,

Es gibt aber Fehler bei der Übertragung der Position.
Die CCU zeigt mir ein Bug-Symbol an oder die angezeigte Position springt nach einer Weile auf einen anderen Wert.

Ich habe leider keine CCU und kann daher das Problem nicht komplett nachvollziehen. Bei meiner FHEM-Zentrale wird die Position allerdings auch nicht immer korrekt angezeigt. Ein Auslesen mit "Get Level" liefert zwar immer korrekte Werte, aber irgendwie werden die Werte, die der Aktor von selbst verschickt (also nicht auf eine Anfrage der Zentrale antwortet), nicht immer als Ist-Werte übernommen.

Habt Ihr mal das Protokoll von einem Originalaktor abgelauscht?
Nicht direkt - ich selbst habe keinen Originalaktor. Habe nur mal ein paar Ausschnitte aus der Kommunikation im Forum gesehen. Falls jemand ein paar gute Logs vom Originalaktor hat, wäre ich aber auch daran interessiert.


UND Wie funktioniert die Referenzfahrt nach Reset des Aktors?
Was muss ich dafür machen?

Die Referenzfahrt wird automatisch bei der ersten Fahrt nach einem Reset ausgeführt - man muss nichts manuell triggern.
Bei der ersten Fahrt nach einem Reset (d.h. wenn die Ist-Position unbekannt ist) steuert der Aktor das Rollo immer für die gesamte programmierte Fahrzeit an, um sicherzustellen, dass wirklich die Endlage erreicht wird. Falls eine Zwischenposition angefordert wird (also nicht 0 oder 100), fährt der Aktor auch erst komplett nach oben und von dort aus in die Zielposition. Falls das Rollo schon in der "oben" Position ist, kann das dazu führen, dass sich das Rollo zunächst nicht bewegt, da der Aktor erst noch die "Oben"-Richtung ansteuert und erst nach dieser Referenzfahrt auf die Zielposition fährt. Also nicht gleich in Panik verfallen, falls der sich das Rollo bei der ersten Ansteuerung nicht sofort bewegt.


Sind denn die Module alle mit dem Arduino Uno kompatibel? Habe aktuell nur diesen im Einsatz. Habe es direkt mit der HEX und auch mit den source-Dateien versucht.

Ja, die Module laufen definitiv auf dem ATMega328P Controller. Für meine Module habe ich eigene Platinen gelötet, nutze aber auch immer wieder Arduino Uno oder Nano zum testen.


Bekomme im HM_LAN.log immer crc-Fehler...
Mit CRC hatte ich noch nie Probleme. Ich würde davon ausgehen, dass die SW korrekt läuft und das Problem irgendwo bei der Busanbindung liegt. Ist der Arduino richtig mit dem RS485-Treiber verbunden? Sind die RS485-Leitungen vielleicht vertauscht? https://arduino-info.wikispaces.com/RS485-Modules (https://arduino-info.wikispaces.com/RS485-Modules)

Für die Inbetriebnahme von neuen Modulen nehme ich immer einen weiteren Arduino, der auch ein RS485-Interface hat und einfach nur den Bus mitliest und über die RS232/USB-Schnittstelle ausgibt. Damit kann man dann die Rohdaten auf dem Bus lesen und solche Probleme analysieren. Den Sketch für ein solches Interface hänge ich einfach mal an.


Viele Grüße
Markus
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Regmus am 13 Mai 2016, 17:56:20
Danke für die Tipps Markus - habs jetzt hinbekommen!  :)
Es hilft doch sehr wenn man den "Transmit-Enable"  auch wirklich auf den 4er Pin anschließt... ::)

EDIT: Jetzt weiß ich auch wo meine Verwirrung her kommt... in den Readme-Dateien ist das"RS485 Enable" noch dem Pin 2 zugeordnet. Entscheidend ist aber natürlich das, was im Programm einprogrammiert ist. Das gleiche gilt auch für die restliche Belegung der Kanäle...
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: StefanGa am 15 Mai 2016, 22:55:19
Hallo Markus,

wenn Du die Position *512 nimmst, wird sie richtig angezeigt. Zumindest von der CCU.

Beste Grüße

Stefan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: maiknms am 16 Mai 2016, 08:34:39
Zitat von: MarkusO am 20 Januar 2015, 22:17:19
Hallo zusammen,

ich habe mich in letzter Zeit mal wieder mit den Homebrew-Devices beschäftigt und ein paar neue Module zusammen gebaut.

HBW-LC-Sw8: 8fach Relaismodul. Damit können mit einem Arduino und einem einfachen Relaismodul für ca. 6€ acht 230V Kanäle geschaltet werden https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Sw8 (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Sw8)

HBW-Sen-SC8: 8fach Tastermodul. Ließt acht Eingänge ein. Neben den langen und kurzen Tastendrücke werden auch Doppelklicks erkannt und ein Event geschickt, wenn ein langer Tastendruck wieder losgelassen wird. Hilfreich, wenn z.B. ein Rollo nur so lange fahren soll, wie eine Taste gedrückt ist. https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-SC8 (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-SC8)

HBW-Sen-KEY: Ließt mit einem RFID-Modul Transponder aus und schickt die ID an die Zentrale. Könnte man z.B. für die Türöffnung verwenden (wenn man der Sicherheit der RFID-Karten vertraut) https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-KEY (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-KEY)

HBW-Sen-EP: Wertet die S0-Schnittstelle aus, wie sie z.B. von Strom-, Gas-, Wasserzählern verwendet wird. Die gezählten Impulse werden an die Zentrale geschickt. https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-EP (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-EP)


Was mir jetzt noch fehlt ist ein 230V Mehrfachdimmer (Phasenanschnittsteuerung). Hierfür gibt es im Netz auch einige ganz gute Vorlagen, z.B. hier: http://www.instructables.com/id/Arduino-controlled-light-dimmer-The-circuit/?lang=de (http://www.instructables.com/id/Arduino-controlled-light-dimmer-The-circuit/?lang=de)
Allerdings würde ich mir gerne den Aufwand sparen, den Dimmer selbst zu entwerfen und würde lieber einen vorhandenen Dimmer über den Arduino an den HM485-Bus anbinden.

Kennst jemand günstige Dimmermodule, die z.B. über DMX oder andere kabelgebundene Protokolle gesteuert werden können?


Viele Grüße
Markus


Hallo Markus,
hast Du die Dimmer schon gesehen?
http://stores.ebay.de/KRIDA-Electronics/AC-Dimmers-/_i.html?_fsub=14851800011
Gruß
Maik
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Treibhaus am 19 Mai 2016, 01:11:07
Moin,

da ich nun einige Zeit hatte mich mit den unterschiedliche Arduino's zu beschäftigen und ein paar Geräte zum Testen nachgebaut habe, ist mir aufgefallen, das die pm-Dateien zu den Geräten im Git-Hub unterschiedlich sind.

z.B funktionieren die von Thorsten. 
Bsp: hbw_sen_sc8.pm    (github - kc-GitHub/HM485-Lib - Branch:Thorsten)

Hingegen funktioniert die hbw_lc_sw8.pm   (github - kc-GitHub/HM485-Lib - Branch:Markus)  bei mir nicht. (diese erreicht man über die Wiki-page.)

Das bedeutet in meinem Fall, daß das neue Gerät nach einem Reset in FHEM erkannt und angelegt wird, ich es aber unter Model nicht auswählen kann - da nicht vorhanden.
Die Ansteuerung per RAW-Befehl funktioniert!
Ich würde mir gerne eine Passende *.pm für ein 8-fach-Relais schreiben/erzeugen. Könnte jemand so freundlich sein und mir erklären wie das am Einfachsten möglich ist ?



PS: flashen von hex-files per Linux (raspberry)
#sudo apt-get install avrdude
Ard. Nano:
#avrdude -v -p atmega328p -c arduino -P /dev/ttyUSB0 -b 57600 -D -U flash:w:file.hex:i
Ard. Uno:
#avrdude -v -p atmega328p -c arduino -P /dev/ttyUSB0 -D -U flash:w:HBW-LC-Sw8.hex:i
(die Endziffer am USB-Device "ttyUSBx" muss ggf. angepasst werden)

Gruß Jörg

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 19 Mai 2016, 09:56:10
Hi,
Zitat von: Treibhaus am 19 Mai 2016, 01:11:07Ich würde mir gerne eine Passende *.pm für ein 8-fach-Relais schreiben/erzeugen. Könnte jemand so freundlich sein und mir erklären wie das am Einfachsten möglich ist ?
Ein paar Beiträge vorher hat Markus ein paar .zip-Files hier eingestellt. Da müssten funktionierende .pm-Files dabei sein.
Gruß,
   Thorsten

EDIT: Hier ist der Link https://forum.fhem.de/index.php/topic,22952.msg448374.html#msg448374 (https://forum.fhem.de/index.php/topic,22952.msg448374.html#msg448374)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Treibhaus am 19 Mai 2016, 16:28:42
Hallo Thorsten,

eigentlich hatte ich gedacht das Forum ordentlich gelesen zu haben.
Habe es wohl eher ordentlich überlesen. ::)

Vielen Dank für den Hinweis. Teste ich später.  :D

Gruß Jörg
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Funsailor am 12 Juli 2016, 15:42:13
Hallo,
da sich an der HomBrew Front nun viel getan hat und ich im Moment wieder etwas mehr Zeit zum "Spielen" habe, wollte ich den Dino (V1 mit enc28j60) Testweise als HM485_LAN Adapter einsetzen.

Allerdings ist mir nicht ganz klar welchen Sketch ich dazu nehmen muss.
Ich habe da verschiedene Beispiele getestet aber erfolgreich war ich noch nicht. :-\

Kann mir da jemand den richtigen Link nennen? Ich suche schon mehrere Tage im Netz und bin immer noch nicht zu einem Ergebnis gekommen.

Danke
Michael
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 13 Juli 2016, 09:33:29
Zitat von: Funsailor am 12 Juli 2016, 15:42:13wollte ich den Dino (V1 mit enc28j60) Testweise als HM485_LAN Adapter einsetzen.
Allerdings ist mir nicht ganz klar welchen Sketch ich dazu nehmen muss.
Die ganzen Homebrew-Sketches sind für HMW-"End"geräte. Ein LAN-Aadapter ist nicht dabei. Ich glaube nicht, dass das schon einmal jemand gebaut hat. Möglicherweise hat Dirk da schonmal was herumexperimentiert. Schau Dir mal diesen Thread an: https://forum.fhem.de/index.php/topic,14096.0.html
Möglicherweise kannst Du Dich da mal reinhängen.
Ich kann mir vorstellen, dass es gar nicht sooo schwierig ist, das hinzubekommen. Die WIZ...-Module machen glaube ich nichts anderes, als die Bytes 1:1 weiterzugeben. Die Kür wäre dann natürlich, die ganze Logik des HM485d auf dem Arduino laufen zu lassen...
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Funsailor am 26 Juli 2016, 00:03:42
Hallo Thorsten,
da nicht mehr an den DINO rankomme, habe ich mir nun aus einem Arduino und einem ENC28J60 Modul die LAN / Ether Schnittstelle "nachgebaut" und diesen Sketch geladen:
"http://kmtronic.com/kmtronic-dino-udp-to-rs485-example.html"
(IP Adresse, serielle Init etc angepasst)
Wenn ich mich nun über einen FTDI seriell an die Arduino Schnittstelle hänge, kann ich mit diesem Programm
"KMTronic DINo 4 Relay UDP Test Software.zip"
eine Message im HTERM (oder anderem seriellem Monitor) sehen.
Also UDP geht schon mal...

Versuche ich etwas über FHEM abzusetzen (Discovery oder RAW) kommen keine Daten an.

List
list HM485_LAN:
Internals:
   DEF        localhost:2000
   DeviceName localhost:2000
   FD         113
   HM485d_CommandLine ./FHEM/lib/HM485/HM485d/HM485d.pl --serialNumber SGW0123456 --device 192.168.178.77:80 --localPort 2000
   HM485d_PID   511
   HM485d_STATE started
   InterfaceType HMW-SOFT-GW
   Last_Sent_RAW_CMD FFFFFFFF 98 00000001 5A
   NAME       HM485_LAN
   NR         282
   PARTIAL
   ProtokolVersion 01
   STATE      opened
   SerialNumber SGW0123456
   TYPE       HM485_LAN
   Version    0.2.2
   currentQueueId 0
   discoveryRunning 0
   hmwId      00000001
   msgCounter 87
   queueId    16
   queueRunning 0
   Readings:
     2016-07-25 23:37:31   state           opened
   Ctrl:
     FFFFFFFF   98
   Keepalive:
     ok         1
     retry      0
   Sendqueue:
Attributes:
   HM485d_bind 1
   HM485d_device 192.168.178.77:80
   hmwId      00000001
   room       HM485
   verbose    3


So weit so gut, siehst du den Fehler?
Liegt es am UDP Protolkoll?

Ping geht natürlich.

LG
Michael
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Funsailor am 29 Juli 2016, 01:29:00
Bin nun ein Stück weiter mit dem Seriell-Ethernet Adapter.

UDP kann da nicht genommen werden, das funktioniert nicht.
Da muss man schon TCP bemühen um an die Daten heran zu kommen.

Ich habe mir den Datenverkehr auf meinem Banana mit tcdump angeschaut, da ist mir etwas nicht ganz klar.
Der RAW Befehl Set RAW FFFFFFFF 98 00000001 ff löst folgende Sendung aus:

        0x0000:  6255 5810 0025 6cfa a71f 4462 0800 4500
        0x0010:  0036 a4b8 4000 4006 afd8 c0a8 b292 c0a8
        0x0020:  b24d 8fe6 0050 616b 4376 0000 1701 5018
        0x0030:  3908 866a 0000 fdff ffff ff98 0000 0001
        0x0040:  03ff bc68

Einmal ist da eine 3 drin die nicht in der Eingabezeile drin ist und nach dem letztem ff kommen noch 2 weitere Bytes (bc und 68)
Kann mir das jemand erklären?
Danke und gute Nacht

Michael


Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 29 Juli 2016, 08:43:51
Hi,
sorry, dass ich hier nicht zum Antworten komme. Mein kleiner 4 Tage alter Sohn hat gerade eine recht hohe Priorität...
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Funsailor am 29 Juli 2016, 09:48:12
Hallo Thorsten,
herzlichen Glückwunsch zu eurem Nachwuchs. ;D

Da sind die Prioritäten ja klar gesetzt, mein Nachwuchs promoviert (27) bzw. studiert (25) und die beiden sind aus dem gröbsten  ;) raus.

Aber es muss sich hier keiner für seine "Auszeiten" entschuldigen, ich finde es immer wieder toll, wieviel Freizeit für FHEM (und andere Projekte) verwendet wird.

-- Nachtrag: Dabei beziehe ich mich auf meine Daten aus dem tcpdump von heute morgen

In der HM485_Protocol.pm finde ich das da:

=head2 NAME
Title: sendRawQueue
Function: Queue a HMW message and start queue if it not running
Returns: nothing
Args: named arguments:
-argument1 => string: $targetAddr 8 hex chars
-argument1 => int: $ctrl ctrl byte
-argument1 => string: $senderAddr 8 hex chars
-argument1 => string: $data n hex chars
=cut
sub sendRawQueue($$$$;$) {
my ($self, $targetAddr, $ctrl, $senderAddr, $data, $msgId) = @_;

# Todo: for check frame must acked?

my $queueId = $self->getQueueId();
my $cmd = substr($data, 0,1);

$self->{sendQueue}{$queueId}{TARGET}     = $targetAddr;
$self->{sendQueue}{$queueId}{CTRL}       = $ctrl;
$self->{sendQueue}{$queueId}{SENDER}     = $senderAddr;
$self->{sendQueue}{$queueId}{DATA}       = $data;
$self->{sendQueue}{$queueId}{MSG_ID}     = $msgId;
$self->{sendQueue}{$queueId}{SEND_COUNT} = 0;

# Messages to broadcast, messages with z or Z command must not acked
if ( (uc( unpack ('H*', $targetAddr)) eq 'FFFFFFFF') || $cmd eq 'z' || $cmd eq 'Z') {
$self->{sendQueue}{$queueId}{STATE} = STATE_IDLE;

} else {
if (grep $_ eq $cmd, @validRequestTypes) {
$self->{sendQueue}{$queueId}{STATE} = STATE_WAIT_RESPONSE;
} else {
$self->{sendQueue}{$queueId}{STATE} = STATE_WAIT_ACK;
}
}

if (!$queueRunning) {
$queueRunning = 1;
$self->sendQueueNextItem();
}
}


bc 68 könnte die msgId sein...

Aber die 03 finde ich nicht.

Wenn ich mir aber die Erklärung von parseCommand anschaue:


# Daten senden
# Startzeichen FD (hab noch kein FE gesehen)
# |  Länge der Nachricht inkl. MessageCounter
# |  |  MessageCounter, wird mit jedem KeepAlive oder anderer Message hochgezählt, Overflow bei 0xFF --> 0x01, startet nach Transparenzbefehl mit 01
# |  |  |  Befehl (S steht für Senden)
# |  |  |  |  ???
# |  |  |  |  |  ab hier kommen die Nutzdaten
# |  |  |  |  |  ---------------------------------------
# |  |  |  |  |  Zieladresse
# |  |  |  |  |  |           CTRL-Byte
# |  |  |  |  |  |           |  Absenderadresse
# |  |  |  |  |  |           |  |           Nutzdaten, könnte das der Jalousie-Aktor-Status sein?
# |  |  |  |  |  |           |  |           |
# -- -- -- -- ----------- -- -- ----------- -----------
# FD 0F 13 53 C8 00 00 59 ED 1A 00 00 00 01 78 0C 00


finde ich zwar die "FD" in meiner tcpdump Aufzeichnung aber alle anderen beschriebenen Daten nicht:
Es fehlen:
"Länge der Nachricht inkl. MessageCounter"
" MessageCounter, wird mit jedem KeepAlive"
"Befehl (S steht für Senden)"
"? ? ?"

Die Nutzdaten sind zu sehen.
Bis auf die verflixte 03.

LG
Michael

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 29 Juli 2016, 10:44:00
Zitat von: Funsailor am 29 Juli 2016, 01:29:00
Einmal ist da eine 3 drin die nicht in der Eingabezeile drin ist und nach dem letztem ff kommen noch 2 weitere Bytes (bc und 68)
Kann mir das jemand erklären?

Die 03 ist die Framelänge und die bc 68 ist die Checksumme.
Das ganze ist in der HMW-Protokoll-Doku beschrieben:
http://forum.fhem.de/index.php?action=dlattach;topic=10027.0;attach=2441

Mir ist noch nicht so richtig klar was Du vor hast.
Möchstest Du das LAN Gateway nachbauen und dann auch noch die Module selberbauen?
Oder hast Du schon fertige wired Module.

Damit benötigst Du nur ein transparentes Ethernet zu RS485 Modul 
define HM485_LAN HM485_LAN localhost:2000
attr HM485_LAN HM485d_device 192.168.178.15:5000
attr HM485_LAN hmwId 00000001
attr HM485_LAN HM485d_bind 1


Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Florian E. am 14 September 2016, 19:49:02
Moin,

ich habe eine Frage zu dem HBW-Sen-KEY. (Und durch vieles Suchen jedoch noch keine Antwort gefunden)
Derzeit versucht ich diesen aufzubauen, bin leider noch nicht all zuweit gekommen.

Ich habe mir einen Arduino Uno und ein MAX485 besorgt. Angefangen habe ich mit der Software, wo ich aktuell leider auch hänge.
Die Bibliotheken von GitHub habe ich mir heruntergeladen und in die Software von Ardunio geladen. Jedoch fehlt mit Schlichtweg die RFID.h
https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-Sen-KEY

Kann mir jemand aushelfen?
Zum Schluss vielleicht noch eine weitere Frage: Besteht denn derzeit die Möglichkeit den HBW-Sen-Key so zu bauen wie er hier und bei GetHub beschrieben ist? Nicht das es eventuell Kompatibilitätsproblem mit einer eventuell neuen FHEM Software oder Ähnliches gibt worauf ich noch stoßen könnte?

Danke im Voraus für eure Antwort!

EDIT:

Ich hab nun einfach das HEX File auf den Arduino gebracht und es läuft es. Halbwegs...
Es ist wohl genau das, was ich bereits schon von ein paar Seiten zuvor gelesen habe. Das die PM Datei nicht mehr zu der FHEM Version passt.
Gibt es für dieses Homebrew Device vielleicht auch schon eine neue? Ich habe mir einmal die "neue" und die "alte" PM Datei von einem anderen Device angesehen und bin der Meinung, dass bekomme ich nicht so ohne weiteres selbst hin...  :o

Hier noch ein paar Auszüge aus meinem Log-File weshalb ich auf meine Vermutung komme:


HM485: Unknown device type 133. Setting model to Generic
2016.09.14 20:55:04 3: HMW_Generic_HBW4073471: Request config for device 42FFFFFF
2016.09.14 20:55:04 3: HMW_Generic_HBW4073471: Lese Eeprom 42FFFFFF
2016.09.14 20:55:04 1: PERL WARNING: Use of uninitialized value $chType in string eq at FHEM/lib/HM485/ConfigurationManager.pm line 258.
2016.09.14 20:55:04 1: PERL WARNING: Use of uninitialized value $chType in concatenation (.) or string at FHEM/lib/HM485/Device.pm line 206.
2016.09.14 20:55:04 1: PERL WARNING: Use of uninitialized value $chType in concatenation (.) or string at FHEM/lib/HM485/ConfigurationManager.pm line 268.
2016.09.14 20:55:04 1: PERL WARNING: Use of uninitialized value $central_address in sprintf at ./FHEM/10_HM485.pm line 766.
2016.09.14 20:55:04 1: PERL WARNING: Use of uninitialized value in string eq at FHEM/lib/HM485/ConfigurationManager.pm line 225.
2016.09.14 20:55:04 1: PERL WARNING: Use of uninitialized value in string eq at FHEM/lib/HM485/ConfigurationManager.pm line 227.
2016.09.14 20:55:04 1: PERL WARNING: Use of uninitialized value $chType in concatenation (.) or string at FHEM/lib/HM485/Device.pm line 618.
2016.09.14 20:55:04 1: PERL WARNING: Use of uninitialized value in subtraction (-) at FHEM/lib/HM485/Device.pm line 622.
2016.09.14 20:55:04 3: HMW_Generic_HBW4073471: Set config HMW_Generic_HBW4073471: central_address=1


Separates Thema: https://forum.fhem.de/index.php/topic,57773.msg491747.html#msg491747 (https://forum.fhem.de/index.php/topic,57773.msg491747.html#msg491747)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 15 September 2016, 18:08:19
Hi,
ja, da hat sich vor einer Weile ein bisschen das Konzept geändert. Eigentlich sollten XML-Dateien angeboten werden, die dann automatisch in die PM-Teile umgewandelt werden. Ich habe momentan nicht wirklich viel Zeit, aber ich werde mir's mal zwischendurch anschauen. Es kann aber etwas dauern.
Könntest Du dafür einen neuen Thread aufmachen? Da ich selbst keinen HBW-Sen-KEY habe, und mir momentan auch keinen bauen will, wird das ein klein wenig hin und her geben.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 30 November 2016, 21:31:01
Hi,
interessiert sich wirklich niemand dafür:
https://forum.fhem.de/index.php/topic,61661.msg530850.html#msg530850
...oder habt Ihr's nur nicht gesehen?
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Matthi140 am 04 Dezember 2016, 21:09:13
Hallo, ich bin neu hier und finde es höcht interessant das sich jemand dran wagt und Neue Module zu entwickeln, bzw. bestehende Module nach zu bauen, die letztenendes auch in der CCU funktionieren. Nun ist es ja so, das das HMW-IO-12-FM Modul nicht mehr hergestellt wird. In eurer Liste auf der WIKI-Seite (http://www.fhemwiki.de/wiki/HomeMatic_Wired (http://www.fhemwiki.de/wiki/HomeMatic_Wired)) ist es aufgeführt, aber Funktioniert wohl weder in FHEM noch in der CCU. Ich hätte für Diese Module noch so einige Verwendungsmöglichkeiten bei mir und würde mich freuen, wenn das mal irgendwann funktionieren würde. Ich würde dazu meine mithilfe anbieten, ich habe noch genau 2 solcher Module originalverpackt hier bei mir, weil ich die mal irgendwann einbauen wollte. Wenn Diese Teile jemand zu versuchszwecken gebrauchen könnte um die Kommunikation zu sniffen, dann wäre ich bereit die Teile mal für eine Weile aus zu borgen oder unter Anleitung eben selber die Daten zu sniffen. Ich habe eine CCU für Produktiveinsatz und auch ein RPi mit FHEM derzeit zum rum spielen, da ich überlege das ganze auf FHEM um zu rüsten.

Also bei Interesse bitte bei mir melden.

MfG Matthi140
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 04 Dezember 2016, 22:40:26
Hi,
die Originalteile sollten schon sowohl in der CCU als auch in FHEM funktionieren. Es gibt nur bisher keinen funktionierenden Nachbau. Das sollte sich aber auch demnächst ändern.
Danke für Dein Angebot, aber im Prinzip dürfte ziemlich klar sein, wie die Dinger funktionieren. Wenn es Probleme gibt, dann komme ich gern darauf zurück.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Funsailor am 02 Januar 2017, 19:18:08
Da ich Zuhause viele andere wichtige Dinge erledigen muss, habe ich mir auf meinen Laptop Perl + FHEM installiert und wollte das Thema "Ethernet-Seriell_RS485" unterwegs bearbeiten.
Fhem läuft auf dem Lapi, allerdings will der HM485d.pl nicht starten.
Die HM485d_PID bleibt auf 0, der HM485d_STATE auch.
Beißt sich da localhost:2000 mit der Installation von FHEM auf dem gleichen System?


Internals:
   DEF        localhost:2000
   HM485d_CommandLine ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000001 --serialNumber SGW0123456 --device 192.168.178.77:80 --localPort 2000
   HM485d_PID 0
   Last_Sent_RAW_CMD FFFFFFFF 98 00000001 ff
   Last_Sent_RAW_CMD_State NACK
   NAME       HM485_MyLAN
   NR         20
   STATE
   TYPE       HM485_LAN
   currentQueueId 0
   discoveryRunning 0
   hmwId      00000001
   msgCounter 14
   queueId    14
   queueRunning 0
   Ctrl:
     FFFFFFFF   98
   Sendqueue:
Attributes:
   HM485d_bind 1
   HM485d_device 192.168.178.77:80
   HM485d_startTimeout 5
   hmwId      00000001
   room       HM_LAN
   verbose    4

Im Notfall muss ich mir einen Raspi 1 besorgen und den auch noch auf Reisen mitnehmen... 8)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 02 Januar 2017, 20:01:53
Hi,
der ganze Kram läuft auf Windows nicht so richtig. Wie man es hinbekommen kann, ist hier beschrieben:
https://forum.fhem.de/index.php/topic,61780.msg532064.html#msg532064
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Funsailor am 02 Januar 2017, 22:13:10
Hallo Thomas,
danke, damit funktioniert das Teil wie am Raspi daheim ;)
Morgen komme ich dann hoffentlich mal wieder zun Kern der Sache.
LG
Michael
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 02 Januar 2017, 22:14:05
Zitat von: Funsailor am 02 Januar 2017, 22:13:10
Hallo Thomas,
danke, damit funktioniert das Teil wie am Raspi daheim ;)
Freut mich, nur wer ist Thomas?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Funsailor am 02 Januar 2017, 22:16:34
Sorry da warst du gemeint. :-[ :-[

Danke Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: pula am 07 Januar 2017, 22:23:40
Hallo,

ich frag mal hier, weil ich sonst nichts finde und Thorstens Tutorial-Threads nicht missbrauchen möchte.
Ich habe schon einiges mit Arduino gemacht und auch selber entwickelt, allerdings bisher nur "normale" Sketches (.ino) mit der Arduino-IDE.
Die Projekte auf github haben allerdings in der Regel nur .h und .cpp Files.
Kann mir bitte jemand auf die Sprünge helfen wie/mit welcher Toolchain ihr diese Dinger baut und auf den Arduino übertragt?
Steh anscheinend grad mächtig auf dem Schlauch :-(

Danke im voraus und cheers,

Pula
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Funsailor am 07 Januar 2017, 22:31:25
Hallo Pula,
es gibt immer eine CPP Datei die den Namen des Moduls trägt.
Wenn du die öffnest findest du dort den "Setup" und "Loop" - Einsprunglabel für die Arduino IDE.
Diese Datei in *.INO umbenenne.
Ich kopiere die Originaldatei (die *.cpp) immer und verlege diese dann in ein Verzeichniss darunter.

LG
Michael
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: pula am 07 Januar 2017, 22:34:32
Hi Michael,

super, vielen Dank für diese Turbo-Antwort :-)

Cheers,

Pula
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 07 Januar 2017, 22:45:20
Zitat von: pula am 07 Januar 2017, 22:23:40Ich habe schon einiges mit Arduino gemacht und auch selber entwickelt, allerdings bisher nur "normale" Sketches (.ino) mit der Arduino-IDE.
Die Projekte auf github haben allerdings in der Regel nur .h und .cpp Files.
Kann mir bitte jemand auf die Sprünge helfen wie/mit welcher Toolchain ihr diese Dinger baut und auf den Arduino übertragt?
Ich glaube, die meisten sind mit Eclipse gebaut. Die Labraries waren bisher nicht wirklich Arduino-IDE geeignet. (Ok, man kann es hinbekommen, siehe Michael.)
Wenn Bedarf besteht, dann würde ich vielleicht die vorhandenen Devices auf die neuen Libraries umstellen und auch dafür sorgen, dass sie tatsächlich in FHEM funktionieren. Bitte dafür pro "gewünschtem" Gerätetyp einen neuen Thread aufmachen, sonst könnte das sehr unübersichtlich werden.
Gruß,
    Thorsten

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: pula am 12 Januar 2017, 18:35:04
Hi Thorsten,

super Angebot, vielen Dank!

Würde mich über den Gerätetyp HBW-Sen-SC8 (Taster-Schnittstelle) sehr freuen. Soll ich einen Thread öffnen oder machst Du das?

Cheers,

Pula
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 12 Januar 2017, 18:36:43
Zitat von: pula am 12 Januar 2017, 18:35:04Würde mich über den Gerätetyp HBW-Sen-SC8 (Taster-Schnittstelle) sehr freuen. Soll ich einen Thread öffnen oder machst Du das?
Mach Du das mal.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: pula am 12 Januar 2017, 18:51:42
Bitte, danke im Voraus:
https://forum.fhem.de/index.php/topic,64700.0.html (https://forum.fhem.de/index.php/topic,64700.0.html)

Cheers,

Pula
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 14 März 2017, 14:26:59
Hallo Ihr,

ich habe jetzt noch einen alten µC in den Ruhestand geschickt und wollte den 8 Kanal Homebrew Aktor HBW_LC_Sw8 einsetzen.
Bei der Integration in FHEM wird das Gerät nur als generic erkannt. Das pm File ist vorhanden und wird laut logfile auch geladen. Die Rechte sind genauso gesetzt, wie bei meinen anderne Homebrew Elementen.:

2017.03.14 14:12:32 3: HM485: HM485: Loading available device files
2017.03.14 14:12:32 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hbw_1w_t10.pm
2017.03.14 14:12:32 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hbw_lc_sw8.pm
2017.03.14 14:12:32 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hbw_sen_ep.pm



2017.03.14 14:12:49 3: HBW_LC_Sw8_HBW7349712: Set config HBW_LC_Sw8_HBW7349712: central_address=1
2017.03.14 14:14:09 3: HBW_LC_Sw8_HBW7349712: Request config for device 4200D0D0
2017.03.14 14:14:09 3: HBW_LC_Sw8_HBW7349712: Lese Eeprom 4200D0D0
2017.03.14 14:14:09 3: HBW_LC_Sw8_HBW7349712: Set config HBW_LC_Sw8_HBW7349712: central_address=1
2017.03.14 14:15:13 1: HM485: Unknown device type 131. Setting model to Generic


Durch manuelles define ist das Gerät zumindest angelegt und ich bekomme ACK. Allerdings
wird das model weiterhin auf Generic gesetzt. Dadurch sind die Kanäle auch nicht sichtbar.

Genutzt habe ich die Codes von Markus:
https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Sw8

Über USB am HBW selbst sehe ich ordentlich sending und receiving Nachrichten. Also grundsätzlich funktioniert die Kommunikation auch.
Bei einem Discovery sehe ich das Gerät nicht jedes mal.

Viele Grüße
Stephan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 März 2017, 14:53:57
Hi,
tja, da müsste halt jemand mal ein XML dazu machen. Die alten .pm-Dateien wurden anscheinend einmal angelegt und dann nie wieder angepasst. In der nächsten Version der HM485-Anbindung wird es sogar eine automatische Umwandlung der XMLs in die .pm-Dateien geben.
D.h. jemand müsste man eine XML-Datei dazu machen. Ich selbst weiß nicht, ob ich dazu komme, aber das ganze ist ja im Homebrew-Tutorial beschrieben.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 14 März 2017, 16:36:39
Hallo Thorsten,

Irritierend ist leider, dass auf der HMW Wiki Seite fhem support yes steht. Da fehlt der Hinweis bei einigen HBWs, dass diese veraltet sind, und aktuell nicht kompatibel mit FHEM laufen. Dein Tutorial ist echt klasse. Ich habe es gerade mal angefangen zu lesen. Ich schaue mal, wie weit ich komme.

Viele Grüße
Stephan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 März 2017, 16:47:43
Zitat von: stephan-221 am 14 März 2017, 16:36:39Da fehlt der Hinweis bei einigen HBWs, dass diese veraltet sind, und aktuell nicht kompatibel mit FHEM laufen.
Das ändert sich doch aber jetzt, wenn Du ein XML dafür bastelst  :P
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 14 März 2017, 21:07:43
Wie recht du hast ;-)

Ich habe beim googlen sogar meine eigenen Beiträge gefunden. :-D

Mit deinem Tutorial und den Vergleich mit dem alten PM File habe ich es hinbekommen.
Mit dem Logiktester konnte ich direkt die Ausgänge auf Funktion prüfen.
Morgen gehts dann an den Einbau ;-)

Anliegend habe ich jetzt das xml und konvertierte pm für das HBW-LC-Sw8 angefügt.
Würdest du das zumindest ins github einstellen?

Viele Grüße
Stephan
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 März 2017, 22:49:19
Hi,
danke!
Ich habe das nicht ins Git aufgenommen, da ich nicht in einen fremden Branch schreiben kann/will. ...und das ganze zu mir kopieren wollte ich auch nicht. Ich bezweifle auch den Erfolg eines Pull-Requests. Statt dessen habe ich einen Link auf Dein Post mit den neuen Dateien im Wiki gesetzt.
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stephan-221 am 15 März 2017, 20:41:34
Danke :-)
So passts auch.

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Skywalker007 am 21 März 2017, 12:07:37
Hallo zusammen,

auf der Suche nach einem vernünftigen HM Rolladenaktor bin ich hier über HM-Wired Homebrew gestolpert. Es scheint ja da einen 4-Fach Aktor zu geben.
Lässt sich der auch ohne allzu großen Aufwand auf mehr Rolladen erweitern?
Im Moment bräuchte ich 10-Fach. Ziel wäre es aber in späterer Ausbaustufe ca 30 Rolladen zu steuern. 3 x 10-Fach Aktor schwebt mir da so vor.
Hat sich da jemand schon mal Gedanken zu gemacht?

danke, Till
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 21 März 2017, 12:22:12
Zitat von: Skywalker007 am 21 März 2017, 12:07:37auf der Suche nach einem vernünftigen HM Rolladenaktor bin ich hier über HM-Wired Homebrew gestolpert. Es scheint ja da einen 4-Fach Aktor zu geben.
Geben tut's den irgendwo, aber ob der auch ohne Gebastel momentan läuft ist eine andere Frage.

ZitatLässt sich der auch ohne allzu großen Aufwand auf mehr Rolladen erweitern?
Im Moment bräuchte ich 10-Fach. Ziel wäre es aber in späterer Ausbaustufe ca 30 Rolladen zu steuern. 3 x 10-Fach Aktor schwebt mir da so vor.
Irgendwann wird es halt eng mit Output Pins. Man braucht pro Rollladen zwei, also bei 10 sind das schon 20. Außerdem braucht man noch ein paar Pins für die Kommunikation. Da must Du jetzt halt mal zählen...
Es könnte auch etwas fummelig im Schaltschrank werden. Wenn das normale 230V-Motoren sind, dann hast Du 10 Kabel mit je 4 Adern zu verlegen. Davon müssen je mindestens zwei an den Aktor gehen, also 20 Kabel mit 1,5mm Querschnitt und eigentlich sogar noch doppelt isoliert. Na viel Spaß...
Ach ja, die 20 Relais in einem Gehäuse könnten auch noch ein bisschen unhandlich werden. Wenn man dann noch ordentliche Abstände von wegen 230V einhält, dann wird das ein ganz schönes Monster.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Skywalker007 am 22 März 2017, 08:44:57
Hallo Thorsten,

danke für deine schnelle Antwort.
Es gibt 8 und 10-Fach Aktoren mit KNX. Ob ich allerdings nur für die Rolladen jetzt mir noch KNX zulegen will ist eine andere Frage.
Hatte gehofft der Homebrew Aktor liesse sich irgendwie simpel erweitern ;-).

Grüße! Till
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 März 2017, 10:12:52
Zitat von: Skywalker007 am 22 März 2017, 08:44:57Hatte gehofft der Homebrew Aktor liesse sich irgendwie simpel erweitern ;-).
Du kannst es ja mal versuchen. Dabei könntest Du das Teil auch gleich auf die neue Library umschreiben, siehe Homebrew-Wired Tutorial.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: markusstar am 03 August 2017, 08:38:52
Hallo,

ich fange mich mit Homematic Wired zu beschäftigen. Ich habe jetzt einiges zu den Homebrew Devices gelesen.
Ich möchte ein Probeaufbau auf einen Brett zusammenstellen. Wo bekomme ich die Universalsensor-Platine? Am besten mit Spannungsversorgung und RS485-Tranceiver.

Kann mir da jemand ein Tipp geben?
Danke
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 03 August 2017, 09:26:48
Zitat von: markusstar am 03 August 2017, 08:38:52ich fange mich mit Homematic Wired zu beschäftigen. Ich habe jetzt einiges zu den Homebrew Devices gelesen.
Ich möchte ein Probeaufbau auf einen Brett zusammenstellen. Wo bekomme ich die Universalsensor-Platine? Am besten mit Spannungsversorgung und RS485-Tranceiver.
Hi,
an Deiner Stelle würde ich erst einmal mit einem stinknormalen Arduino (oder Arduino Nano) anfangen wie hier beschrieben:
https://forum.fhem.de/index.php/topic,61780.msg532033.html
Wenn es denn wirklich die Universalsensor-Platine sein soll, dann schick mal Forumsuser "Dirk" eine Nachricht.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 21 November 2017, 14:21:04
Hallo Zusammen,

danke erstmal für die ganzen Infos, die hier in Forum freigegeben wurden. Ich habe folgendes Problem:

ich möchte HBW-LC-Sw8 auf Arduino Nano zum laufen zu bringen.
dafür habe ich "HM485-Lib-markus\HM485-Lib-markus\HBW-LC-Sw8\HBW-LC-Sw8.hex" genommen.
soweit funktioniert alles, wird auch von FHEM anerkannt und kann geschaltet werden.
mein Problem ist, dass das Relais 1 von anfang geschaltet ist und wenn ich in FHEM anschalte, geht er aus bzw. beim ausschalten geht er an.
kennt jemand das Problem?
gibt es zu HBW-LC-Sw8.hex ein .ino Datei für Arduino?

Gruß
Arthur
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 21 November 2017, 16:43:26
Hi,
...und noch ein Liebhaber der riesigen Threads. Warum nicht für ein neues Problem auch einen neuen Thread aufmachen?
Jetzt aber zum Thema: Die meisten Relais-Boards scheinen Low-aktiv zu sein. D.h. wenn die Pins gegen Masse gezogen werden, dann schalten die Relais. Das ist wohl auch deswegen so, damit ein offener Eingang nicht schaltet, da Pull-Ups verbreiteter sind als Pull-Downs.
Ansonsten sind die Sourcen im Git im Unterverzeichnis "source".
Was mich wundert: Funktioniert das wirklich? Wo ist die XML-Datei her?
Gruß,
   Thorsten 
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 22 November 2017, 13:44:59
Hallo Thorsten,
danke für deine Antwort. Ja das funktioniert ganz gut mit XML von "stephan-221".
Das Problem ist, dass nur das ersrte Relais so reagiert, die anderen 7 funktioniern ganz normal.

Gru0
Arthur
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 November 2017, 14:34:44
Zitat von: aperoap am 22 November 2017, 13:44:59danke für deine Antwort. Ja das funktioniert ganz gut mit XML von "stephan-221".
Kannst Du mal einen Link hier posten, wo Du genau das ganze Zeugs her hast?

Zitat
Das Problem ist, dass nur das ersrte Relais so reagiert, die anderen 7 funktioniern ganz normal.
Das ist in der Tat etwas seltsam. Hast Du mal in die Sourcen geschaut?

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 23 November 2017, 09:19:06
Hallo Thorsten,

ich habe an einem anderen Arduino ausprobiert es lag an Arduino :)
läuft bei mir perfekt auf Arduino mini pro und ardino nano.

Hex Datei: https://github.com/kc-GitHub/HM485-Lib/tree/markus
XML Datei habe ich: https://forum.fhem.de/index.php/topic,22952.msg605163.html#msg605163

FHEM Version:

File    Rev   Last Change

fhem.pl 15112 2017-09-21 07:22:33Z rudolfkoenig

fhemweb.js                 14906 2017-08-15 20:06:05Z rudolfkoenig
fhemweb_colorpicker.js     13580 2017-03-02 13:03:29Z justme1968
fhemweb_fbcalllist.js      13629 2017-03-06 20:50:43Z markusbloch
fhemweb_readingsGroup.js   13580 2017-03-02 13:03:29Z justme1968
fhemweb_readingsHistory.js 13580 2017-03-02 13:03:29Z justme1968
fhemweb_sortable.js        13629 2017-03-06 20:50:43Z markusbloch
fhemweb_uzsu.js            13580 2017-03-02 13:03:29Z justme1968

Zurzeit läuft alles perfekt!

Gruß
Arthur
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 23 November 2017, 09:59:06
Zitat von: aperoap am 23 November 2017, 09:19:06
ich habe an einem anderen Arduino ausprobiert es lag an Arduino :)
läuft bei mir perfekt auf Arduino mini pro und ardino nano.
Freut mich, dass es jetzt geht.

Zitat
Hex Datei: https://github.com/kc-GitHub/HM485-Lib/tree/markus
XML Datei habe ich: https://forum.fhem.de/index.php/topic,22952.msg605163.html#msg605163
Ah, offensichtlich habe ich selbst den Link ins Wiki gehängt. Vielleicht sollte ich das doch mal komplett in mein Git umziehen und auf die neuen Libraries umstellen. Es fehlt offenbar auch das direkte Peering...
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: sentinel1 am 23 November 2017, 20:39:07
Hallo Thorsten,


gehen beim HMW-LC-Bl1-DR Direktverknüpfungen(Peering)?

Gruß,
Claudiu
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 23 November 2017, 20:44:26
Zitat von: sentinel1 am 23 November 2017, 20:39:07gehen beim HMW-LC-Bl1-DR Direktverknüpfungen(Peering)?
Ja.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: sentinel1 am 24 November 2017, 17:38:02
Hallo Thorsten,

mit dieser Firmware von hier https://github.com/kc-GitHub/HM485-Lib/tree/markus/HMW-LC-Bl1-DR (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HMW-LC-Bl1-DR) oder brauche ich eine andere? da steht in der Readme Datei das es nur über notify geht.

Gruß,
Claudiu
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 24 November 2017, 19:13:54
Achso, Du meinst den Homebrew... Nein, da gibt es wahrscheinlich kein direktes Peering. Das müsste mal jemand bauen.
...allerdings wäre das eher überflüssig, da man sich einfach einen kaufen kann. Das ist billiger, selbst bei kalkulatorischem Mindestlohn.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 25 November 2017, 08:38:40
Hallo Thorsten,
bei HBW-LC-Sw8 funktioniert  das direkte Peering tatsächlich nicht. Wenn das noch funktionieren würde, wäre das ein Traum :-)
Gruß
Arthur
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 25 November 2017, 10:44:32
Zitat von: aperoap am 25 November 2017, 08:38:40
bei HBW-LC-Sw8 funktioniert  das direkte Peering tatsächlich nicht. Wenn das noch funktionieren würde, wäre das ein Traum :-)
Tja, da ist es genauso wie bei der Homebrew-Version des HMW-LC-Bl1-DR. Man müsste die Firmware komplett neu schreiben, ansonsten ist es noch mehr Aufwand die Peerings reinzufrickeln. Momentan habe ich aber ein paar andere Projekte und es kann noch eine ganze Weile dauern, bis wieder eine Runde "Homebrew" kommt. Vielleicht schaust Du Dir mal das Tutorial an und versuchst Dich selbst daran?
Ansonsten könnte der HMW-IO-12-Sw7-DR ungefähr das bieten, was Du brauchst.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 07 Dezember 2017, 21:24:36
Hallo Zusammen,
kennt jemand das Problem bei HMW_LC_Bl1_DR dass level_0 immer auf 0 Bleibt?
gibt es ein funktionierendes HMW_LC_Bl1_DR ?
Gruß
Arthur
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 07 Dezember 2017, 21:50:12
Zitat von: aperoap am 07 Dezember 2017, 21:24:36
gibt es ein funktionierendes HMW_LC_Bl1_DR ?
Ich habe zwei Originalteile von eq3, die funktionieren wunderbar.
Ansonsten wäre es vielleicht keine schlechte Idee, für die einzelnen Devices eigene Threads aufzumachen. ...und dann versuchen, den Original-Autor drauf zu stoßen.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 03 Januar 2018, 23:22:39
Hallo,

es wäre wohl besser, wie Thorsten geschrieben hat, die Software auf die neue HBWired Library umzustellen... aber auf die Schnelle habe ich zumindest für HBW-LC-Bl4 und HBW-LC-Sw8 die Änderungen aus dem Thread zusammengetragen (neue XML + Anpassungen v2, etc.) und in Github geladen. (inkl. Pull request für den branch/tree von Markus... keine Ahnung ob da noch jemand nach schaut...)
https://github.com/loetmeister/HM485-Lib/tree/markus

Update:
Basierend auf "HBW-Sen-Key-12" habe ich mal HBW-LC-Sw-8 nachgebaut. Ist noch nicht ganz Fertig.... Pairing muss ich noch testen Direktes Peering funtioniert
https://github.com/loetmeister/HBWired/tree/master/HBW-LC-Sw-8
HBWired
forked from ThorstenPferdekaemper/HBWired


Update2,5:
Habe nun auch HBW-LC-BL-4 nachgebaut. Läuft soweit, direktes Peering muss ich noch einbauen. ;-)
https://github.com/loetmeister/HBWired/tree/master/HBW-LC-BL-4

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 24 Januar 2018, 21:50:46
Hallo,

Direktes Peering funktioniert nun auch für HBW-LC-BL-4. Mögliche Befehle: open (100%), close (0%), toggle & stop, für lange oder kurze Tastendrücke.
Die lib "HBWLinkBlindSimple" liegt erst mal noch nicht im richtigen "libraries" Verzeichnis... ich muss noch schauen ob mir die so gefällt  ;)

Beide "Nachbauten" in GitHub:
HBW-LC-Sw-8
https://github.com/loetmeister/HBWired/tree/master/HBW-LC-Sw-8
HBW-LC-BL-4
https://github.com/loetmeister/HBWired/tree/master/HBW-LC-BL-4

Der Rest (Sw-12 und BL-8) ist noch nicht fertig....
--> ein paar weitere Updates sind in GitHub hochgeladen. Finale Tests aber erst wenn die Hardware Fertig ist ;)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 06 März 2018, 23:37:12
Hallo,

hatte die Tage noch ein paar kleine Änderungen für HBW-LC-Sw-8 ins Git gepusht.

Peering für lange Tastendrücke ging nicht und die Pin Init Funktion (initConfigPins()) wollte nicht so recht...
Ich hatte sie in der selben Schleife in der auch das HBWSwitch/Channel Objekt/Array befüllt wird... aber der Funktionsaufruf klappte aber nicht.


HBWSwitch* switches[NUM_CHANNELS];
...
void setup()...
  for(uint8_t i = 0; i < NUM_CHANNELS; i++){
     switches[i] = new HBWSwitch(pins[i], &(hbwconfig.switchcfg[i]));

//--> geht nicht?!
     switches[i]->initConfigPins();
  };



Für die geänderte HBWSwitch muss nun (ähnlich zu "device->setConfigPins();") jeder Kanal mit initConfigPins(); initialisiert werden. Das setzt dann die Ausgangspins passenden zum im EEPROM gespeicherten Wert (inverted: ja/nein).
Nach dem Erzeugen des "HBSwDevice" klappt auch der initConfigPins() Aufruf....  ???


  for(uint8_t i = 0; i < NUM_CHANNELS; i++){
     switches[i]->initConfigPins();
  };


https://github.com/loetmeister/HBWired/tree/master/HBW-LC-Sw-8

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 07 März 2018, 22:44:47
Hi,
ich habe mal angefangen mir Deinen Pull-Request zu betrachten. Du hast da ja ganz schön viel gebastelt. Es wäre einfacher, das in kleinen Stückchen zu integrieren, aber sehen wir mal. Mir wäre es lieber, das hier zu diskutieren statt im Git, da es hier für mich einfacher ist. Ich denke auch, dass wir das Stück für Stück machen.
Als erstes zu den initConfigPins. Das ist kein Wunder, dass es nicht geklappt hat, da die Konfiguration erst im HBWDevice-Konstruktor aus dem EEPROM gelesen wird. Vorher ist es mehr oder weniger Zufall, was in hbwconfig steht. Deine Lösung funktioniert erstmal, gefällt mir aber trotzdem nicht so ganz. Es bleibt z.B. das Problem, dass nach einer Änderung der Konfiguration das Device durchgestartet werden muss. Das soll nicht so sein. Für solche Sachen ist der "afterReadConfig"-Mechanismus da. Leider hat der auch zwei Problemchen:
1. Der Aufruf virtueller Funktionen im Konstruktor funktioniert nicht. Das ist der Grund, warum das Ding in Subklassen von HBWDevice immer explizit aufgerufen werden muss.
2. Kanäle haben kein afterReadConfig.
Mir wäre es viel lieber, wenn wir das korrigieren (und dann verwenden) könnten anstatt etwas neues zu bauen. Leider habe ich derzeit keine Testumgebung für den ganzen Kram, daher wäre es schön, wenn Du das machen könntest. Ich stelle mir Folgendes vor:

Zu Punkt 1:
In HBWDevice::readConfig wird afterReadConfig nicht direkt aufgerufen, sondern nur ein Flag gesetzt (in etwa "afterReadConfigPending") Am Ende von HBWDevice::loop wird dann afterReadConfig aufgerufen, wenn das Flag gesetzt ist.
Dann kann man sich wahrscheinlich auch die explizite Definition des Konstruktors für Subklassen von HBWDevice sparen.

Zu Punkt 2:
HBWChannel sollte genauso ein afterReadConfig haben wie HBWDevice. D.h. virtual, aber mit leerer Implementierung. Da wo in HBWDevice::loop das afterReadConfig für HBWDevice selbst aufgerufen wird (s.o.) sollte es dann auch für alle channels aufgerufen werden.
In HBWSwitch sollte dann afterReadConfig redefiniert werden mit dem Inhalt "Deines" initConfigPins.

Gruß,
  Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 07 März 2018, 22:55:04
Hi,
hier ist der nächste Punkt. Das mit dem useAnalogConfigPin passt mir nicht wirklich. Ich glaube, dass das nur gebraucht wird, weil Du da eine etwas spezielle Beschaltung hast. Normalerweise verwendet mal die Analog-Pins genauso wie die Digital-Pins, wenn man sie als Digital-Pin verwenden will. D.h. INPUT_PULLUP funktioniert und digitalRead ebenfalls. Meiner Meinung nach ist das ein Spezialfall für Deine Hardware und deshalb würde ich Dich bitten, was wieder auszubauen. (...und einfach Deine Widerstände abknipsen.)
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 08 März 2018, 23:06:25
Hi Thorsten,

vielen Dank für das super feedback. So richtig glücklich war ich mit dem "initConfigPins" Konstrukt auch nicht. Dein Vorschlag klingt deutlich eleganter. Habe das ganze mal mit "HBW-LC-Sw-8" umgesetzt. Hoffe das ist ok.. es funktioniert jedenfalls schon mal.  ::)

afterReadConfigPending wird nun als flag initial in HBWDevice::HBWDevice und aus afterReadConfig() gesetzt.
Im HBWDevice loop have ich das mal an den Anfang gesetzt, damit bei ersten Start alle Werte und IOs richtig gesetzt sind. (statt am ende vom loop)

@@ -801,6 +803,15 @@ uint8_t HBWDevice::get(uint8_t channel, uint8_t* data) {  // returns length
// The loop function is called in an endless loop
void HBWDevice::loop()
{
+  // read device and channel config, on init and if triggered by ReadConfig() // TODO test afterReadConfig
+   if (afterReadConfigPending) {
+               afterReadConfig();
+               for(uint8_t i = 0; i < numChannels; i++) {
+                      channels[i]->afterReadConfig();  // TODO test afterReadConfig
+               }
+               afterReadConfigPending = false;
+       }
// Daten empfangen und alles, was zur Kommunikationsschicht gehört
// processEvent vom Modul wird als Callback aufgerufen


>> Commit: https://github.com/loetmeister/HBWired/commit/2fe9cba85c60b312308d6e57d304b7427b0cce65#diff-804b89404ca1977353cbc9be6b56c357

Wo müsste ich den folgenden Teil unterbringen um die zusätzliche Subklasse von HBWDevice komplett los zu werden?
//    void afterReadConfig() {
//        // defaults setzen
//        if(hbwconfig.logging_time == 0xFF) hbwconfig.logging_time = 20;
//    };


Eigentlich in HBWDevice::afterReadConfig()..... aber da es Device spezifisch sein könnte nicht in HBWired.cpp...  :-[

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 08 März 2018, 23:42:47
Hi,

zum Punkt "useAnalogConfigPin"  8)
Hab mir schon fast gedacht, das wird nicht auf Gegenliebe stoßen  ;)

Der Grund ist, die Arduinos mit einem ATmega328 (NANO, MINI) haben zwei ADC ports (ADC6 & ADC7), die nicht mit einem digital Pin kombiniert sind (Port A, B, C, usw.) . Die beiden Pins können nur ADC oder AC (Analog Comparator).
Daher wollte ich einen der beiden Pins für den Config Button nutzen, nicht nur bei 8-fach Rollo, sondern als Standard Layout. (ADC6 = configPin und ADC7 zur Messung der Busspannung)
Mit #ifdef, etc. wars auch nicht schöner...

Ich schaue mal ob ich das per Analog Comparator Interrupt hinbekomme (trigger on raising/falling edge)....

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 09 März 2018, 21:56:21
Zitat von: loetmeister am 08 März 2018, 23:06:25
vielen Dank für das super feedback.
Ich bin froh, dass Du das so siehst. So manch anderer hätte sich über mein "Gemecker" aufgeregt...

Zitat
afterReadConfigPending wird nun als flag initial in HBWDevice::HBWDevice und aus afterReadConfig() gesetzt.
Tatsächlich sieht Dein Coding aber so aus, dass Du es im Konstruktor (HBWDevice::HBWDevice) und in readConfig setzt. Das im Konstruktor kannst Du Dir allerdings sparen, da es ja sowieso schon in readConfig gesetzt wird, was im Konstruktor aufgerufen wird.

Zitat
Im HBWDevice loop have ich das mal an den Anfang gesetzt, damit bei ersten Start alle Werte und IOs richtig gesetzt sind. (statt am ende vom loop)
Ja, das ist tatsächlich besser.
Allerdings ist im Commit noch eine überflüssige Abfrage auf  afterReadConfigPending drin, die in Deinem Forum-Beitrag anscheinend rausgeflogen ist.

Jetzt ist mir gerade noch was wichtiges aufgefallen: HBWChannel::afterReadConfig ist nirgends definiert (nur deklariert). Es kann sein, dass das klappt, wenn man in den Subklassen afterReadConfig definiert, aber wir wollen ja niemanden dazu zwingen. Könntest Du noch die Definition einfügen? (So wie bei afterReadConfig für's Device.

Zitat
Wo müsste ich den folgenden Teil unterbringen um die zusätzliche Subklasse von HBWDevice komplett los zu werden?
Ich meinte nicht, dass Du die Subklasse los wirst, sondern nur deren (expliziten) Konstruktor.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 09 März 2018, 22:10:37
Zitat von: loetmeister am 08 März 2018, 23:42:47zum Punkt "useAnalogConfigPin"  8)
Hab mir schon fast gedacht, das wird nicht auf Gegenliebe stoßen  ;)
Der Grund ist, die Arduinos mit einem ATmega328 (NANO, MINI) haben zwei ADC ports (ADC6 & ADC7), die nicht mit einem digital Pin kombiniert sind (Port A, B, C, usw.) .
Das war mir nicht so klar. Ich habe jetzt aber nochmal genauer hingeschaut. Stimmt...

Zitat
Ich schaue mal ob ich das per Analog Comparator Interrupt hinbekomme (trigger on raising/falling edge)....
Immer langsam... Du darfst bei mir nicht so schnell aufgeben. Das was Du sagst klingt ja ganz sinnvoll, da sollten wir eine schöne Lösung finden. Im Prinzip kann man das fest einbauen. D.g. wenn der "config button" A6 oder A7 ist, dann fragt man eben nicht per digitalRead ab, sondern so wie Du das machst. D.h. über einem Schwellwert ist es 1, ansonsten 0.
Dann spart man sich das mit dem extra Flag.

Irgendwelche #ifdefs können wir immer noch einbauen, wenn andere Prozessoren unterstützt werden sollen.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 10 März 2018, 01:12:11
Hallo Thorsten,

Zitat von: Thorsten Pferdekaemper am 09 März 2018, 21:56:21
[...] im Konstruktor kannst Du Dir allerdings sparen, da es ja sowieso schon in readConfig gesetzt wird, was im Konstruktor aufgerufen wird.

[...] HBWChannel::afterReadConfig ist nirgends definiert (nur deklariert). Es kann sein, dass das klappt, wenn man in den Subklassen afterReadConfig definiert, aber wir wollen ja niemanden dazu zwingen. Könntest Du noch die Definition einfügen? (So wie bei afterReadConfig für's Device.

Danke. Ist nun aufgeräumt und hinzugefügt...  8)

ZitatIch meinte nicht, dass Du die Subklasse los wirst, sondern nur deren (expliziten) Konstruktor.
Ok, ich glaube ich habs nun richtig. Die Subklasse bleibt, um eine eigene z.B. HBSwDevice::afterReadConfig() zu definieren, alles andere kommt über die Basisklasse.


HBWDevice::setConfigPins und HBWDevice::handleConfigButton() habe ich zum größten Teil wieder zurück gebaut... und so gelöst:
+       #if defined(__AVR_ATmega328P__) || defined(__AVR_ATmega328__)
+               if (configPin == A6 || configPin == A7)
+                       pinMode(configPin,INPUT);       // no pullup for analog input
+               else
+       #endif
+               pinMode(configPin,INPUT_PULLUP);


... so würde das nur für Boards mit ATmega328 gelten. Das wäre eine art Sicherheit falls es andere Boards gibt, bei den A6, A7 als digital/analog Kombi Pin existiert. (was ich nicht weiß)


ZitatIch bin froh, dass Du das so siehst. So manch anderer hätte sich über mein "Gemecker" aufgeregt...
Mit den direkten Verbesserungsvorschlägen ist es fern ab von "Gemecker" :-)
... zumal meine C++ Kenntnisse nicht so gut sind. ::)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 10 März 2018, 21:50:50
Hi,
ja, sieht schon viel besser aus.
Ich schaue mir momentan nur die Dateien an, die Du geändert hast. Alles was neu dazukommt ist erstmal Dein Problem. D.h. ich werde das alles übernehmen, sobald ich mit den geänderten Sachen zufrieden bin.
Könntest Du in "Deine" Dateien irgendwo oben einen Verweis auf Dich reinschreiben? Also z.B. auf Deinen FHEM-Forum Benutzernamen, wenn Du keinen echten Namen bzw. eine Mailadresse angeben willst.

So, jetzt zu weiteren Änderungsvorschlägen:

Zum HBW-Sen-Key-12

Hier habe mich zuerst gewundert, warum Du da überhaupt etwas geändert hast. Eine der Änderungen ist klar. Die Methode HBWSenKey::afterReadConfig passt jetzt natürlich nicht mehr und der Aufruf derselben braucht jetzt auch nicht mehr explizit gemacht zu werden. Das ist ok.
Das "defaulten" der long_press_time ist auch ok.
Das mit der logging_time war allerdings absichtlich nicht in der XML-Datei. Wahrscheinlich ist es durch einen "copy&paste"-Fehler in der .ino-Datei gelandet. Bei reinen Sensor-Devices ist logging_time nicht sinnvoll. Könntest Du das aus der XML-Datei wieder rauswerfen und auch die .ino entsprechend aufräumen? Die Subklasse von HBWDevice wird vermutlich gar nicht mehr gebraucht.
Du hast in der XML außerdem DIRECT_LINK_DEACTIVATE eingefügt. Warum? Ich glaube, dass das nicht richtig ist.

HBWLinkSwitchSimple
Da hast Du wohl einen Bug gefunden und gefixt. Das ist gut. Ich hätte es nur ein ganz klein wenig anders gemacht:

if (longPress) actionType >>= 2; 
actionType &= B00000011;

Das dürfte ein paar Bytes sparen.

HBWSwitch
Ich sehe, Du hast meine TODO-Anweisung befolgt. Das ist gut. Du kannst das gelösche Coding gerne wirklich löschen. (Also nicht nur "//-en".) Ich habe nicht so gerne Coding-Museen.

HBWired
Die Lösung für A6 und A7 finde ich jetzt richtig gut. Die Sonderlocke ist für die 328er und für alles andere bleibts wie es ist.
Vielleicht nur noch eine Kleinigkeit: Die Digital-Eingänge sind normalerweise Low-aktiv, da es ja keine eingebauten Pulldowns gibt. Gibt es einen Grund, warum A6 und A7 High-aktiv sind? Man könnte doch auch hier einen Pullup an den Pin legen und per Taste nach GND kurzschließen, oder? Möglicherweise übersehe ich da aber was.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 11 März 2018, 01:11:04
Hallo,

hab noch ein paar Änderungen gemacht... deine Vorschläge und "aufgeräumt", denke es nähert sich der "Fertigstellung".  :)
Schaltpläne mehr Infos zur Hardware würde ich später noch hinzufügen...

Zitat von: Thorsten Pferdekaemper am 10 März 2018, 21:50:50
Zum HBW-Sen-Key-12 [...] Das mit der logging_time war allerdings absichtlich nicht in der XML-Datei. Wahrscheinlich ist es durch einen "copy&paste"-Fehler in der .ino-Datei gelandet. Bei reinen Sensor-Devices ist logging_time nicht sinnvoll. Könntest Du das aus der XML-Datei wieder rauswerfen und auch die .ino entsprechend aufräumen? Die Subklasse von HBWDevice wird vermutlich gar nicht mehr gebraucht.
Ok, hatte mich auch ein wenig gewundert das logging_time im Code, aber nicht in der XML stand. Habs bei beiden nun raus genommen. Die HBWDevice Subklasse ist auch gelöscht.


ZitatDu hast in der XML außerdem DIRECT_LINK_DEACTIVATE eingefügt. Warum? Ich glaube, dass das nicht richtig ist.
Ich hatte den kompletten "DIRECT_LINK_DEACTIVATE" Block aus den XML Dateien der original HM Geräte kopiert... inkl. "enforce". Scheint der Funktion keinen Abbruch zu tun.
Wenns ok ist würde ich es drin lassen.
<parameter id="DIRECT_LINK_DEACTIVATE" hidden="true">
<logical type="boolean" default="false"/>
<physical interface="eeprom" size="0.1" type="integer">
<address index="0x0006"/>
</physical>
</parameter>
<enforce id="DIRECT_LINK_DEACTIVATE" value="true"/>



Zitat
HBWLinkSwitchSimple Da hast Du wohl einen Bug gefunden und gefixt. Das ist gut. Ich hätte es nur ein ganz klein wenig anders gemacht:

if (longPress) actionType >>= 2; 
actionType &= B00000011;

Das dürfte ein paar Bytes sparen.
Das ließt sich auf jeden Fall schön und die bitmaske ist nicht "doppelt".... aber es würde beim BL-4 zwei Bytes extra kosten. Beim Switch Sw-8 blieb es gleich, daher hab ich zu deinem Code geändert. :)

Zitat
HBWired Die Lösung für A6 und A7 finde ich jetzt richtig gut. Die Sonderlocke ist für die 328er und für alles andere bleibts wie es ist.
Vielleicht nur noch eine Kleinigkeit: Die Digital-Eingänge sind normalerweise Low-aktiv, da es ja keine eingebauten Pulldowns gibt. Gibt es einen Grund, warum A6 und A7 High-aktiv sind? Man könnte doch auch hier einen Pullup an den Pin legen und per Taste nach GND kurzschließen, oder?
Danke. :)
Es gibt eigentlich keinen Grund warum hier nicht auch Low-aktiv gilt... ich hatte einfach den Spannungsteiler im Schaltplan eingezeichnet und dann nicht weiter in Frage gestellt...
Habe es geändert. Beschaltung wäre nun ein "weak pullup" und der Taster gegen Masse.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 11 März 2018, 22:28:38
Hi,
Dein Pull-Request ist jetzt drin. Wie schon gesagt habe ich bisher nur die geänderten Dateien angeschaut. Alles, was neu dazugekommen ist, habe ich erst einmal ignoriert.
Ich werde jetzt noch das Wiki anpassen, so dass es auf die neuen Implementierungen verweist.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 11 März 2018, 22:52:07
Sodele, Wiki ist jetzt auch angepasst.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 11 März 2018, 23:46:37
Top.  8) Danke!

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Shortie am 18 März 2018, 16:19:45
Genial wäre jetzt noch eine universelle Hardware Basis, so in der Art wie es für die Funk-Variante hier im Forum entwickelt wurde.

Ich denke da an eine kleine Platine in SMD ähnlich wie ein Arduino Nano, aber mit Schaltregler und max485 onboard. Alles rausgeführt auf Pinleisten damit man variabel bleibt und so, das es in eine UP Dose passt.
Ich hatte sowas schonmal in Easyeda versucht zu routen, nur hat das leider nicht so richtig klappen wollen.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 18 März 2018, 21:08:58
Zitat von: Shortie am 18 März 2018, 16:19:45
Genial wäre jetzt noch eine universelle Hardware Basis, so in der Art wie es für die Funk-Variante hier im Forum entwickelt wurde.
Hier gibt es etwas in der Richtung:
https://forum.fhem.de/index.php/topic,84827.msg771453.html#msg771453
Vielleicht kannst Du Dich da mit reinhängen.
Ich selbst bin eher in der Software zuhause und bisher hat es für mich gereicht, einen Nano mit einem MAX487 zusammenzustöpseln.

ZitatIch denke da an eine kleine Platine in SMD ähnlich wie ein Arduino Nano, aber mit Schaltregler und max485 onboard. Alles rausgeführt auf Pinleisten damit man variabel bleibt und so, das es in eine UP Dose passt.
Max485 ist nicht so doll, da man damit glaube ich maximal 32 Geräte am Bus haben kann. Max487 (oder ähnlich) ist besser.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 18 März 2018, 23:26:01
Hi,

Zum Entwickeln, reicht z.B. einen Arduino + Spannungsversorgung + RS485 Baustein (Bspw. MAX487CSA), oder auch was hier als Universalsensor beschrieben ist: https://wiki.fhem.de/wiki/Universalsensor#RS485-Version_mit_1-Wire_Temperatursensoren

ZitatIch denke da an eine kleine Platine in SMD ähnlich wie ein Arduino Nano, aber mit Schaltregler und max485 onboard. Alles rausgeführt auf Pinleisten damit man variabel bleibt und so, das es in eine UP Dose passt.
Verm. wird das relativ eng, in einer tiefen UP Dose könnte man zwei Platinen stapeln. Ich würde aber etwas für den passenden Anwendungsfall bauen und die ganzen Steckkontakte weglassen, wo nicht absolut nötig.

Ich habe Platinen für 6 TE Hutschienengehäuse erstellt, da hat die Kontrollerplatine die gleiche Basis, die Relaisplatinen variiert dann (Schaltaktor, Rolladenaktor). Ich müsste noch eine Variante für 4 TE Gehäuse erstellen... 6TE ist für manches etwas groß...

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 24 März 2018, 22:08:29
Hallo,

ich versuche grade den Homematic Homebrew Switch mit einem erweiterten direkten peering zu ergänzen, bei denen man die Ein- und Ausschaltverzögerung einstellen kann. (siehe Screenshot)

Da ich aktuell kein "echtes" Homematic Gerät zum testen habe: Frage an Homematic Benutzer und die Besitzer von HMW-LC-Sw2-DR, o.ä., sind meine Annahmen richtig?  ;D

Ich habe mal am Beispiel eines kurzen Tastendrucks (short_*) die Funktionen aufgeführt. Bis auf "long_multiexecute" ist das peering für short und long gleich. Wenn jemand long_multiexecute erklären kann wär das auch hilfreich :)
--> long_multiexecute: Wiederholte lange Tastendrücke beachten. ja/nein. Bei nein wird nur der erste lange Tastendruck ausgewertet.

--> On/Off Zeiten können durch ein neuen Befehl verlängert werden (MINIMAL): Die neue Zeit muss länger als die aktuell verbleibende Restzeit sein! "ABSOLUTE" setzt den timer immer neu, egal welcher timer vorher lief.
(Gilt wohl nur für 'on_time'/'off_time' - nicht für 'ondelay_time'/'offdelay_time')
--> Auswahl: DONT_USE, DIRECT oder INVERTED.
DONT_USE ist klar. DIRECT toggelt den Ausgang, aber INVERTED ist mir nicht ganz klar... toggle kann ich irgendwie schlecht invertieren...
Es gibt bei anderen Geräten TOGGLE_TO_COUNTER / TOGGLE_INVERSE_TO_COUNTER, eventuell ist das die selbe Funktion.
--> Active oder Inactive: Gilt für alle short_* Einstellungen dieses peering. Auch short_toggle_use?

Dem besseren Verständnis würde ich folgende Implementierung bevorzugen (ist beim original Dimmer so ähnlich der Fall, wohl nicht für Schaltaktoren) - ersetzt auch "short_toggle_use"
short_ACTION_TYPE
- INACTIVE
- JUMP_TO_TARGET --> zur Sprungliste short_jt_* wechseln
- TOGGLE_TO_COUNTER
- TOGGLE_INVERS_TO_COUNTER
- TOGGLE

--> Zeit, bevor der Sprungpunkt 'jt_ondelay' angesprungen wird, z.B. der Ausgang nach EIN geschaltet wird.
--> Zeit die der Ausgang auf EIN bleibt. Danach wechsel über short_jt_on?
--> Zeit, bevor der Sprungpunkt 'jt_offdelay' angesprungen wird, z.B. der Ausgang nach AUS geschaltet wird.
--> Zeit die der Ausgang auf AUS bleibt. Danach wechsel über short_jt_off?
--> Sprungziele (Jump Target):
Die Auswahl gilt ausgehend vom aktuellen Status, wenn z.B. der Ausgang AUS ist, gilt die Auswahl von 'short_jt_off'.


Erste Version: https://github.com/loetmeister/HBWired/tree/430a7e13e325a17fd9dc1fdbd37d2ec8132833c5/HBW-LC-Sw-12
(Grundsätzlich funktionieren der Standard Wechsel off->ondelay->on->offdelay->off... Zeit ist aktuell 0-255 Sekunden, nicht Minuten :) )


PS: Neue Erkenntnisse eingearbeitet..

-->Details im ELVjournal: https://forum.fhem.de/index.php?action=dlattach;topic=22952.0;attach=99026

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 25 März 2018, 13:15:50
Zitatich versuche grade den Homematic Homebrew Switch mit einem erweiterten direkten peering zu ergänzen, bei denen man die Ein- und Ausschaltverzögerung einstellen kann.

Da hast Du Dir aber einiges vorgenommen.
Daß Du kein "echtes" Homematic Gerät zum testen hast, macht es noch schwieriger.

Das  direkte peering und die Statemaschine sind recht komplex. Du wirst wahrscheinlich noch auf einige details stossen die das ganze recht aufwendig machen.
Daß Teile der sendFrame Routine momentan noch blocking sind, kann evtl die Zeiten der Statemaschine beeinflussen.
Hast Du Dir schon gedanken gemacht wie Du das mit den broadcast Meldungen machen willst?
Es gibt außer on/off auch noch das stateflag working.
Wenn Z.B. bei 2 switche gleichzeitig der ontime timer abläuft und gleichzeitig 2 event gesendet werden, oder wenn bei einem event gerade der Bus nicht frei ist.
Eine Möglichkeit wäre eine Sendewarteschlange einzubauen.


Mit den events habe ich es bei mir so gemacht:

// state aenderungen beim peering
void HMWModule::broadcastPeeringEvent(byte channel, byte timeState) {
   hmwrs485->txFrameDataLength = 0x04;       // Length
   hmwrs485->txFrameData[0] = 0x69;          // 'i'
   hmwrs485->txFrameData[1] = channel;       // Sensornummer
   if (timeState < 2) {
      hmwrs485->txFrameData[2] = 0x00;       // off
   } else {
      hmwrs485->txFrameData[2] = 0xC8;       // on
   }
   if (timeState == 0 || timeState == 12) { 
      hmwrs485->txFrameData[3] = 0x00;       // stateflag, working off
   } else {
      hmwrs485->txFrameData[3] = 0x40;       // stateflag, working on
   }
   ...


Dabei ist time_state: 0 = off, 1 = ondelay, 2 = ontime, 12 = dauer on


Da es mir zu heftig war das komplette direkte peering einzubauen habe ich bei mir nur ein vereinfachtes direktes peering realisiert.
Ich verwende noch die alte Libary die ich modifiziert habe und habe folgendes eingebaut:

ondelay_time
on_time
short_action_type
long_action_type
shortOnJmpTo
longOnJmpTo
shortOffJmpTo   
longOffJmpTo


Das Problem mit der fehlenden Sendewarteschlange habe ich bei mir auch noch nicht gelöst.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 25 März 2018, 13:58:02
Zitat von: Ralf9 am 25 März 2018, 13:15:50
Da hast Du Dir aber einiges vorgenommen.
Manchmal ist es gut, nicht zu wissen auf was man sich einlässt...  ::)
Ich würde auch erstmal eine vereinfachte Version bauen.  ;)
Schon mal vorab danke für die Details.

Zitat
Hast Du Dir schon gedanken gemacht wie Du das mit den broadcast Meldungen machen willst?
Es gibt außer on/off auch noch das stateflag working.
Wenn Z.B. bei 2 switche gleichzeitig der ontime timer abläuft und gleichzeitig 2 event gesendet werden, oder wenn bei einem event gerade der Bus nicht frei ist.
Eine Möglichkeit wäre eine Sendewarteschlange einzubauen.
Das "stateflag working" habe ich bisher erst mal ignoriert...
Die keyEvents werden ganz normal Bestätigt (ACK), dann schicke ich logging/notify events, mit "sendInfoMessage" - wenn logging für den channel aktiv ist. Dabei gibt einen einfachen retry Mechanismus, falls der Bus belegt war. Den Code habe ich einfach übernommen.

Die Behandlung der Timer (on/off, on-/offdelay) läuft im device loop(). Dort werden alle channels der reihe nach geprüft. Hoffe das alle logging/notify events rausgehen...
Ein nofity event wird auch gesendet, wenn z.B. der Ausgangspegel sich wegen eines abgelaufenen Timers geändert hat.


Eine Sende und Empfangs Warteschlange wäre natürlich noch eine super Sache... nicht nur für peering/info Nachrichten. Ich backe erst mal kleinere Brötchen.  ;)


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 25 März 2018, 19:48:03
ZitatHoffe das alle logging/notify events rausgehen...
Das wäre mir zu wenig, es sollte schon einigermaßen zuverlässig funktionieren.
Wenn ich mir sowas selber baue, dann sollen die events zuverlässiger ankommen als bei meinem HMW_IO_12_FM.
Wenn Du auch noch einbaust, daß mit einem Taster 2 Ausgänge getriggert werden können, dann kannst Du es damit testen.

ZitatDabei gibt einen einfachen retry Mechanismus, falls der Bus belegt war.
Dies bedeutet dann, daß Du während dem retry eine Blockierung hast. Inwieweit dies z.B. auf die Abfrage und Verarbeitung der Eingänge auswirkt, kann ich nicht abschätzen.

Es wäre schön, wenn die Sende- und Empfangsroutinen das retry selbstständig und blockierungfrei erledigen könnten.
Ich habe zwar eine Idee wie man das machen könnte, aber zum Testen habe ich auf meinem Bus zuwenig Module.

Ich habe mir dies ungefähr so vorgestellt:

Die sendframe Routine erledigt nur das Senden:
Nach dem Senden wird der Status auf waitForAck und die Wartezeit gesetzt.
Bei einem busbusy wird Status auf busbusy gesetzt.

In der  HBWDevice::loop() wird dann nach einem receive geprüft ob ein ack empfangen wurde.
Ein evtl retry bei fehlendem ack müsste dann auch hier erfolgen.
Und bei einem busbusy müsste dann nach einer Wartezeit das sendframe erneut aufgerufen werden.

Der nächste Schritt wäre dann der Einbau einer Sendewarteschlange.

Bei meinem selbstbau I/O verwende ich momentan einen Arduino Micro und einen MCP23017, damit sind dann 16 Eingänge und 8 Ausgänge möglich.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 25 März 2018, 20:47:29
Hi,
so ähnliche Gedanken habe ich mir auch schon gemacht, aber wegen ausbleibender Probleme bisher verworfen. Oder anders gesagt: Es gab erst einmal wichtigeres zu tun. Die "alte" Library war meiner Meinung nach nicht wirklich verwendbar, da wollte ich erst einmal umstrukturieren.
Das Thema "Sendewarteschlange" ist meiner Meinung nach auf einem Arduino etwas schwierig, da man begrenzten Speicherplatz zur Verfügung hat. Irgendwann muss man dann doch anfangen zu blockieren oder Nachrichten zu verwerfen. So ein richtig gutes Konzept dafür ist mir bisher noch nicht eingefallen.
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 25 März 2018, 23:53:26
Hi Ralf,

ich nutzte ja die aktuelle Arduino HBWired lib, ist da das Verhalten beim Senden nicht schon ähnlich deiner Beschreibung?

Zitat von: Ralf9 am 25 März 2018, 19:48:03
Wenn Du auch noch einbaust, daß mit einem Taster 2 Ausgänge getriggert werden können, dann kannst Du es damit testen.
Dies bedeutet dann, daß Du während dem retry eine Blockierung hast. Inwieweit dies z.B. auf die Abfrage und Verarbeitung der Eingänge auswirkt, kann ich nicht abschätzen.
Ich habe mal 4 Ausgänge mit einem Taster verknüpft, das scheint ohne Probleme zu funktionieren. Die Ausgänge werden sofort gesetzt, zwei Sekunden später (logging_time ist auf 2 Sek. gestellt) rauschen dann 4 notify events rein und bei FHEM gehen die Lampen an.

Wenn ich ein paar mehr Geräte haben, teste ich das Verhalten weiter...


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 26 März 2018, 17:52:04
Zitat von: loetmeister am 25 März 2018, 23:53:26
ich nutzte ja die aktuelle Arduino HBWired lib, ist da das Verhalten beim Senden nicht schon ähnlich deiner Beschreibung?
(Das "deiner" bezieht dich auf Ralf9.)
Leider nicht wirklich. Er bezieht sich wahrscheinlich auf HBWDevice::sendFrame. Da kann es tatsächlich passieren, dass wenn die "Gegenstelle" nicht antwortet, das ganze etwa 600ms lang blockiert. Selbst wenn alles gut läuft, dann dauert es immerhin ein paar Millisekunden, bis das ganze gesendet ist und das ACK zurück kommt. Wenn man mehrere Peerings (zu anderen Devices, nicht nur intern) hat, dann kann sich das aufaddieren. Im Prinzip können dann weitere Tastendrücke verloren gehen oder sich auch zeitgesteuerte Sachen entsprechend verzögern.

Zitat
Ich habe mal 4 Ausgänge mit einem Taster verknüpft, das scheint ohne Probleme zu funktionieren. Die Ausgänge werden sofort gesetzt, zwei Sekunden später (logging_time ist auf 2 Sek. gestellt) rauschen dann 4 notify events rein und bei FHEM gehen die Lampen an.
Ich nehme mal an, dass das interne Peerings waren. Aber auch bei externen: Wenn alles gut läuft, dann dauert das ganze ja nur ein paar Millisekunden. Für einen Menschen ist das "sofort".

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 26 März 2018, 19:05:34
ZitatIch habe mal 4 Ausgänge mit einem Taster verknüpft, das scheint ohne Probleme zu funktionieren. Die Ausgänge werden sofort gesetzt, zwei Sekunden später (logging_time ist auf 2 Sek. gestellt) rauschen dann 4 notify events rein und bei FHEM gehen die Lampen an.

Wenn der Bus frei ist, was bei wenigen Modulen wahrscheinlich normalerweise fast immer der Fall sein wird, wird dies wahrscheinlich problemlos funktionieren.

Zitatdann schicke ich logging/notify events, mit "sendInfoMessage" - wenn logging für den channel aktiv ist. Dabei gibt einen einfachen retry Mechanismus, falls der Bus belegt war. Den Code habe ich einfach übernommen.

Mich würde interessieren wie Du das mit dem einfachen retry Mechanismus bei den logging/notify events realisiert hast.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 26 März 2018, 22:44:46
Zitat von: Ralf9 am 26 März 2018, 19:05:34Mich würde interessieren wie Du das mit dem einfachen retry Mechanismus bei den logging/notify events realisiert hast.
Hi,
bei "sendInfoMessage" wird überhaupt nur gesendet, wenn der Bus frei ist. Wenn gesendet wird, dann wird bei einem ausbleibenden ACK nur dann 3x "probiert", wenn der Bus tatsächlich die ganze Zeit ruhig war.
Es wird dem Aufrufer dann signalisiert, wenn das Senden nicht erfolgreich war, so dass man es nochmal versuchen kann.
Siehe z.B. Methode HBWSwitch::loop.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 26 März 2018, 23:12:43
Hi,

das peering war extern. Ich schau mal das ich mehr action auf den Bus bekomme :)


Danke Thorsten für die Erklärung zu HBWDevice::sendFrame und sendInfoMessage.
Somit mildert eine Art queue, bzw. retry counter für logging/notify events in jedem channel das Problem etwas ab, verhindert es aber nicht das irgendwann events verloren gehen können.

(der Code ist von Dirk, Markus, Thorsten... oder allen zusammen :) )
HBWChannelSw::set() {
//... set IO, dann setze lastFeedbackTime:

  // logging
  if(!nextFeedbackDelay && config->logging) {
    lastFeedbackTime = millis();
    nextFeedbackDelay = device->getLoggingTime() * 100;
  }
}

HBWChannelSw::loop() {
//...

  if(!nextFeedbackDelay)  // feedback trigger set?
    return;
  if (now - lastFeedbackTime < nextFeedbackDelay)
    return;
  lastFeedbackTime = now;  // at least last time of trying
  // sendInfoMessage returns 0 on success, 1 if bus busy, 2 if failed
  // we know that the level has only 1 byte here
  uint8_t level;
  get(&level);
  uint8_t errcode = device->sendInfoMessage(channel, 1, &level);   
  if (errcode == 1)  // bus busy
  // try again later, but insert a small delay
    nextFeedbackDelay = 250;
  else
    nextFeedbackDelay = 0;
}



Hab den post oben ergänzt, (z.B. --> long_multiexecute: Wiederholte lange Tastendrücke beachten. ja/nein. Bei nein wird nur der erste lange Tastendruck ausgewertet.)

Das bringt mich zum nächsten Problem... um das zu erkennen brauche ich den key press counter im set() bzw. receiveKeyEvent()...   ::)
Für LONG_MULTIEXECUTE und ein toggel was sich am Zähler "synchronisiert".
TOGGLE_TO_COUNTER / TOGGLE_INVERSE_TO_COUNTER


Ich bastel erst mal weiter... baue grade on/off time ABSOLUTE/MINIMAL ein.


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Langerrenner am 27 März 2018, 10:52:08
Hallo Thomas,
in der ELV war vor Jahren ein Bericht zu den Aktoren und deren Aktionsprofile. Kennst Du das, wenn nicht habe ich den File angehängt.
Ich finde Eure Arbeit toll und ich werde auf jeden Fall von diesen Modulen welche einsetzen.
Meine Homematic Anlage läuft seid über 10 Jahren. Nun möchte ich sie etwas umbauen und Zukunftssicherer machen. Leider wird ja die RS485 Schnittstelle im Homematic Bereich in Zukunft wohl auslaufen. Es gibt wohl was neues.
Seid Anfang des Jahres laufen schon einige Module auf meinem Bastel Tisch. In den nächsten Monaten möchte ich mir die eine oder andere Funktion noch hinzu bauen. Wenn ich Zeit habe.
Gruß Willi
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 27 März 2018, 14:37:09
Zitat von: Langerrenner am 27 März 2018, 10:52:08Leider wird ja die RS485 Schnittstelle im Homematic Bereich in Zukunft wohl auslaufen. Es gibt wohl was neues.
Ja, da hängt jetzt auch ein "IP" dran. Allerdings wird momentan sogar noch FS20 verkauft, da muss man mal abwarten, ob das wirklich ausläuft. Natürlich sind keine Neuentwicklungen zu erwarten.
Ich selbst werde wahrscheinlich bezüglich "HMW-IP" nichts tun. Soweit ich das verstehe, ist das wohl proprietär und nicht zu entschlüsseln, also kommt es für mich nicht in Frage.
Wenn ich da (irgend wann einmal) auf ein inkompatibles (zu HMW) System wechseln muss, dann wird das wohl nicht HMW-IP sein, sondern eher EnOcean.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 27 März 2018, 22:34:51
Zitatbei "sendInfoMessage" wird überhaupt nur gesendet, wenn der Bus frei ist. Wenn gesendet wird, dann wird bei einem ausbleibenden ACK nur dann 3x "probiert", wenn der Bus tatsächlich die ganze Zeit ruhig war.

ZitatDanke Thorsten für die Erklärung zu HBWDevice::sendFrame und sendInfoMessage.
Somit mildert eine Art queue, bzw. retry counter für logging/notify events in jedem channel das Problem etwas ab, verhindert es aber nicht das irgendwann events verloren gehen können.

Danke für die Erklärungen und Infos ich habe es mir mal in den libs angeschaut.
Demnach können logging/notify events nur verloren gehen, wenn bei einem ausbleibenden ACK und ruhigen Bus  3x erfolglos "probiert" wurde.
Wenn ich das richtig überblicke, dann wird bei key events per broadcast und ohne auf ack zu warten gesendet. Das retry wird hier auf denjenigen der den Taster drückt verlagert.

@loetmeister Du kannst mal testen wie es sich verhält, wenn der HM485d.pl nicht läuft.


Das ganze gefällt mir nicht so richtig.Ich möchte die Blockierungen beim Senden wegbekommen. Ich weiß inzwischen wie ich es besser hinbekomme.
Es ist dazu keine Sendewarteschlange notwendig.
Es müsste funktionieren, wenn ich die logging/notify events und die key events in jeweils einem eigenen Bitpuffer speichere. Die zugehörigen Infos werden in einem separaten Array gespeichert,
Bei z.B. 16 Eingängen sind es 16 Bit, also 2 byte.
In der loop wird dann, falls der puffer ungleich 0 ist, in einer Schleife geschaut welche Bits im Puffer gesetzt sind. Den gesetzen Bits entsprechenden Eingänge werden dann gesendet.

@loetmeister
Du verwendest, damit Du mehr Ausgänge bekommst, als Shiftregister 74HC595.
Die geht mit dem MCP23017 einfacher, es gibt dafür eine Lib
Damit sind z.B. 16 Eingänge möglich.
#include "Adafruit_MCP23017.h"
Adafruit_MCP23017 mcp;
mcp.begin();
mcp.pinMode(i, INPUT);
mcp.pullUp(i, HIGH);
x = mcp.readGPIO(0);


Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 27 März 2018, 23:32:39
Zitat von: loetmeister am 26 März 2018, 23:12:43Hab den post oben ergänzt, (z.B. --> long_multiexecute: Wiederholte lange Tastendrücke beachten. ja/nein. Bei nein wird nur der erste lange Tastendruck ausgewertet.)
Das bringt mich zum nächsten Problem... um das zu erkennen brauche ich den key press counter im set() bzw. receiveKeyEvent()...   ::)
Ich hab mir das mal angeschaut. Da hast Du wohl Recht... Mach mal einen Vorschlag, wie das aussehen könnte.

Zitat von: Ralf9 am 27 März 2018, 22:34:51
Danke für die Erklärungen und Infos ich habe es mir mal in den libs angeschaut.
Demnach können logging/notify events nur verloren gehen, wenn bei einem ausbleibenden ACK und ruhigen Bus  3x erfolglos "probiert" wurde.
Ich nehme an, mit "logging/notify" Eevents meinst Du das, was bei der Änderung eines Ausgangs geschickt wird. Dann hast Du Recht, zumindest wenn man HBWSwitch verwendet. Die Überlegung dabei ist, dass wenn der Bus tatsächlich ruhig ist und die Zentrale nicht antwortet, dann können wir's auch gleich bleiben lassen. Liegt es aber am (temporären?) Traffic auf dem Bus, dann wird bis in alle Ewigkeit wiederholt. Ich finde das im Prinzip so ok, das blockiert auch nicht ganz so schlimm. (Zugegebenermaßen ist etwas unschön, was dann passiert, wenn die Zentrale mal nicht will.)

ZitatWenn ich das richtig überblicke, dann wird bei key events per broadcast und ohne auf ack zu warten gesendet. Das retry wird hier auf denjenigen der den Taster drückt verlagert.
Bei Key Events wird tatsächlich nicht explizit an die Zentrale gesendet. (Ich glaube, das habe ich mir von den Original HMW-Teilen abgeschaut.) Nur bei Peerings wird an die jeweilige Adresse gesendet und dann auch auf ein ACK gewartet. D.h. wenn man mal ein kaputtes gepeertes Device hat wird es auch ein bisschen hässlich, insbesondere, wenn mit mehreren Kanälen gepeert ist (HBW sendet einmal pro Kanal, nicht nur pro Device wie bei HMW).
Tatsächlich geht bei Traffic auf dem Bus der Key Event sofort verloren.

Das mit den Bitpuffern hilft erstmal nur dafür, dass bei Traffic auf dem Bus nichts mehr verloren geht. (Es ist so ähnlich wie das, was in HBWSwitch heute schon passiert.) Allerdings hat man immer noch Blockaden, wenn ACKs auf sich warten lassen. Wenn man das noch "parallelisieren" will, dann müsste man sich noch merken, wo man gerade in der Abarbeitung ist. Wenn man z.B. zwei Taster hat, die jeweils mit vier (ggf. unterschiedlichen oder auch denselben) Kanälen gepeert sind, und beide Taster kurz hintereinander gedrückt werden, dann muss man sich merken, bei welchem Peering zu welchem Taster man gerade ist. (Oder man muss immer alle Peerings in einem Rutsch abarbeiten, aber dann blockiert's halt wieder.)
Außerdem sollte meiner Meinung nach sichergestellt sein, dass die Events zu Tastern immer in der Reihenfolge gesendet werden, in der die Taster auch gedrückt wurden. Das kann relevant sein, wenn z.B. ein Taster Rollläden hochfährt und der andere runter.
Dann ergeben sich darauf aufbauend solche Fragestellungen wie: Was ist, wenn derselbe Taster zweimal kurz hintereinander gedrückt wird und das System mit dem Abarbeiten der Peerings noch nicht fertig ist? Was soll passieren, wenn bei zwei Tastern erst der erste, dann der zweite, dann wieder der erste gedrückt wird und das System nicht hinterherkommt?

Vielleicht müssen wir uns da mal eine Liste machen und einfach mal anfangen, das ganze zu verbessern.

Gruß,
   Thorsten



Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 27 März 2018, 23:53:49
Hallo,

Zitat von: Langerrenner am 27 März 2018, 10:52:08
in der ELV war vor Jahren ein Bericht zu den Aktoren und deren Aktionsprofile. Kennst Du das, wenn nicht habe ich den File angehängt.
Super. Vielen Dank! Kannte ich nicht...
Hatte mir mal https://www.homematic-inside.de/software/download/item/expertenparameter angeschaut. War auch informativ, aber ein Dokument zum nachschlagen ist noch besser :)

Zitat von: Ralf9 am 27 März 2018, 22:34:51
Demnach können logging/notify events nur verloren gehen, wenn bei einem ausbleibenden ACK und ruhigen Bus  3x erfolglos "probiert" wurde.
Wenn ich das richtig überblicke, dann wird bei key events per broadcast und ohne auf ack zu warten gesendet. Das retry wird hier auf denjenigen der den Taster drückt verlagert.

@loetmeister Du kannst mal testen wie es sich verhält, wenn der HM485d.pl nicht läuft.
Ja, ohne FEHM sehe ich drei Versuche.
Die notify events gehen aber direkt an die Zentrale...

T: FD:00:00:00:01:D8:42:00:00:15:05:69:00:C8:3B:F6
T: FD:00:00:00:01:D8:42:00:00:15:05:69:00:C8:3B:F6
T: FD:00:00:00:01:D8:42:00:00:15:05:69:00:C8:3B:F6


Zitat von: Ralf9 am 27 März 2018, 22:34:51
Das ganze gefällt mir nicht so richtig.Ich möchte die Blockierungen beim Senden wegbekommen. Ich weiß inzwischen wie ich es besser hinbekomme.
Es ist dazu keine Sendewarteschlange notwendig.
Es müsste funktionieren, wenn ich die logging/notify events und die key events in jeweils einem eigenen Bitpuffer speichere. Die zugehörigen Infos werden in einem separaten Array gespeichert,
Bei z.B. 16 Eingängen sind es 16 Bit, also 2 byte.
In der loop wird dann, falls der puffer ungleich 0 ist, in einer Schleife geschaut welche Bits im Puffer gesetzt sind. Den gesetzen Bits entsprechenden Eingänge werden dann gesendet.
Das hab ich nicht so ganz Verstanden.... du will die 3 Sendeversuche beim belegten Bus in den loop verlagern, damit "HBWDevice::sendFrame" nicht das Gerät blockiert? Da müsstest du aber nicht nur wissen das noch ein notify event zu senden ist, sondern auch mit welchen daten und den Sende buffer neu schreiben...?

Für den notify Fall (sendInfoMessage) gibt es ja einen neuen Versuch, über nextFeedbackDelay - hier könnte man sendFrame ja mitteilen (per Parameter? - default =3?) nur einen Sendeversuch zu unternehmen... wenn das nicht die Zuverlässigkeit negativ beeinflusst. Aber dann hat man schon mal zwischen den sendInfoMessage Versuchen etwas Zeit was anderes zu machen... "non-blocking" wärs damit noch nicht...  ::)

Zitat
@loetmeister
Du verwendest, damit Du mehr Ausgänge bekommst, als Shiftregister 74HC595.
Die geht mit dem MCP23017 einfacher, es gibt dafür eine Lib
Danke. Über I²C ist das natürlich auch chic... Ich teste mal weiter mit den 74HC595, die sind billig und gibts bei Reichelt im SMD Gehäuse. Als DIP Version ist mir das zu groß :)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 30 März 2018, 00:22:29
Moin,

hab mal ein wenig weiter gemacht...
Der Vorschalg long_multiexecute, etc. zu implementieren würde in etwa so ausehen, das ich keyPressNum zu receiveKeyEvent() in HBWLinkReceiver class hinzugefügt habe:
https://github.com/loetmeister/HBWired/commit/0dfb801c744f65bcdf50b9163986b35be134d6ee

Dann habe ich alle Daten in HBWLinkSwitch::receiveKeyEvent zur Verfügung: keyPressNum, actionType und alle EEPROM peering Parameter.
  uint8_t data[8];  // store all peer parameter
  uint8_t *pdata = data;
  data[7] = keyPressNum;
  ...
        device->readEEPROM(&data, eepromStart + EEPROM_SIZE * i + 13, 7);     // read all parameters (must be consecutive)
        device->set(targetChannel,8,pdata);    // channel, data length, data

Set() ruft dann die channel set() Funktion auf, in der wird dann ein wenig mehr gemacht als bisher...  8)
Das ließe sich bestimmt was schöner schreiben, grade wenn man das array wieder auseinander nimmt...


Damit habe ich nun HBW-LC-Sw-12 um alle peering Funktionen ergänzt. Minimal und Absolute OFF time verhält sich noch nicht wie erwartet. [fixed!] Der Rest läuft aber schon ganz gut.

LONG_MULTIEXECUTE
- yes/no

short/long_ACTION_TYPE hab ich mit folgenden Optionen implementiert, das erübrigt auch "short_toggle_use". Auswahl:
- INACTIVE
- JUMP_TO_TARGET
- TOGGLE_TO_COUNTER
- TOGGLE_INVERS_TO_COUNTER
- TOGGLE

HBW-LC-Sw-12 commit, wer lust hat sich das anzutun :)
https://github.com/loetmeister/HBWired/tree/a733f5c9d7ffa9ee5b133224e95842d9ad38c71d/HBW-LC-Sw-12


Beitrag zu den peering optionen aktualisiert: https://forum.fhem.de/index.php/topic,22952.msg786308.html#msg786308

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 30 März 2018, 12:20:40
Zitat von: Thorsten Pferdekaemper am 27 März 2018, 23:32:39
Das mit den Bitpuffern hilft erstmal nur dafür, dass bei Traffic auf dem Bus nichts mehr verloren geht. (Es ist so ähnlich wie das, was in HBWSwitch heute schon passiert.) Allerdings hat man immer noch Blockaden, wenn ACKs auf sich warten lassen. Wenn man das noch "parallelisieren" will, dann müsste man sich noch merken, wo man gerade in der Abarbeitung ist. Wenn man z.B. zwei Taster hat, die jeweils mit vier (ggf. unterschiedlichen oder auch denselben) Kanälen gepeert sind, und beide Taster kurz hintereinander gedrückt werden, dann muss man sich merken, bei welchem Peering zu welchem Taster man gerade ist.
Dann ergeben sich darauf aufbauend solche Fragestellungen wie: Was ist, wenn derselbe Taster zweimal kurz hintereinander gedrückt wird und das System mit dem Abarbeiten der Peerings noch nicht fertig ist? Was soll passieren, wenn bei zwei Tastern erst der erste, dann der zweite, dann wieder der erste gedrückt wird und das System nicht hinterherkommt?

Stimmt, ich hatte nicht bedacht, daß ein Taster auch mehrere externe peerings haben kann. Da wird das Puffern sehr komplex und aufwendig.
Das mit den Bitpuffern bei den Tastern würde nur funkttionieren, wenn alle peerings intern sind und es kein long_multiexecute gibt.

Ein erster Schritt wäre daß die sendframe Routine blockierungsfrei ist.

Ich habe mir dies ungefähr so vorgestellt:

Die sendframe Routine erledigt nur das Senden:
Nach dem Senden wird der Status auf waitForAck und die Wartezeit gesetzt.
Bei einem busbusy wird Status auf busbusy gesetzt.
Nach dem Senden und einem erhaltenen ack geht der status z.B. auf ready.
Nach dem Senden per broadcast geht der staus sofort auf ready.

In der  HBWDevice::loop() wird dann nach einem receive geprüft ob ein ack empfangen wurde.
Ein evtl retry bei fehlendem ack müsste dann auch hier erfolgen.
Und bei einem busbusy müsste dann nach einer Wartezeit das sendframe erneut aufgerufen werden.

Bei einem logging/notify event wird das entsprechende Bit in dem Bitpuffer gesetzt und, wenn der status ready ist wird geschaut ob der Bus frei ist und gesendet.
In der loop wird geschaut ob etwas im bitpuffer ist und dann mit get der aktuelle Status des entsprechenden Ausgangs geholt und versucht zu senden.
Nach dem Senden wird das Bit im Bitpuffer gelöscht.

Wenn das Modul auch Eingänge hat, welche ja per broadcast gesendet werden, dann müssen diese Vorrang vor den logging/notify events haben.
Ein evtl retry eines logging/notify events kann dann abgebrochen werden da es ja noch im Bitpuffer gespeichert ist.

Wenn das Modul auch Eingänge hat ist auch ein internes peering möglich, was die Gefahr von Buskollisionen senkt.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 30 März 2018, 12:39:40
Zitat von: loetmeister am 27 März 2018, 23:53:49
Über I²C ist das natürlich auch chic... Ich teste mal weiter mit den 74HC595, die sind billig und gibts bei Reichelt im SMD Gehäuse. Als DIP Version ist mir das zu groß :)
Den MCP23017 habe ich auch in SMD gefunden.

Ich habe bei Dir nicht gefunden wie Du mit einem Tastendruck den Status der Statemaschine durchschaltest.
Z.B. wenn eine ondelay_time definiert ist, dann wechselt bei jedem Tastendruck der Zustand: off - ondelay - on - off ..

Nachtrag:

Mit
SHORT_JT_ON -> "NO_JUMP_IGNORE_COMMAND"
oder
SHORT_JT_ON -> "ON"    // verlängern

und

LONG_JT_OFF -> "NO_JUMP_IGNORE_COMMAND"

ist folgendes möglich:
short schaltet nur ein und long schaltet nur aus
Bei der rechten LED ist eine ondelay_time definiert
Am Anfang ist zu erkennen, daß wenn beide LED an sind, ein weiterer Tastendruck ignoriert wird.

https://www.youtube.com/results?search_query=HBW_IO_SW




Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 30 März 2018, 17:13:03
Hallo Ralf,

Zitat von: Ralf9 am 30 März 2018, 12:39:40
Ich habe bei Dir nicht gefunden wie Du mit einem Tastendruck den Status der Statemaschine durchschaltest.
Z.B. wenn eine ondelay_time definiert ist, dann wechselt bei jedem Tastendruck der Zustand: off - ondelay - on - off ..
Es gibt zwei trigger. Timer läuft und Wartezeit ist vorbei, oder aktueller und neuer Status sind nicht gleich. Wenn ein Tastendruck kommt (und keine absolute Zeit läuft) dann wird eine Änderung erzwungen:
nextState = FORCE_STATE_CHANGE; // force update
Damit lassen sich on/off delay Zeiten überspringen.


ZitatMit
SHORT_JT_ON -> "NO_JUMP_IGNORE_COMMAND"
oder
SHORT_JT_ON -> "ON"    // verlängern

und

LONG_JT_OFF -> "NO_JUMP_IGNORE_COMMAND"

ist folgendes möglich:
short schaltet nur ein und long schaltet nur aus
Bei der rechten LED ist eine ondelay_time definiert
Am Anfang ist zu erkennen, daß wenn beide LED an sind, ein weiterer Tastendruck ignoriert wird.
Das sind zwei Peerings für einen Taster, richtig?
Das klappt bei mir mit SHORT_JT_ON / LONG_JT_OFF -> "NO_JUMP_IGNORE_COMMAND" und einer ondelay_time für einen Ausgang, wie beschrieben.
Bei "SHORT_JT_ON -> "ON"    // verlängern" bin ich mir nicht sicher. Meinem Verständnis nach kann ich On/Off delay Zeiten nur überspringen, aber nicht verlängern. Das ginge nur für On/Off Zeiten.


Das Zeit Handling ist noch nicht ganz final... :)

Minimale Zeit läuft:
* alle neuen Zeiten die kleiner als die aktuelle Restzeit ist werden ignoriert. (auch peerings mit Minimal Zeit nicht in Benutzung (Wert = 0))
-> damit kann ich nur Zeiten verlängern, aber nicht abbrechen...
-> Toggle wird ignoriert, [korrekt?]
-> neue Absolute Zeiten überschreiben den timer, auch mit Zeit == 0. [korrekt?]

Absolute Zeit läuft:
* alle Änderungen (über peerings) werden ignoriert - bis auf neue absolute Zeit, bis der timer abgelaufen ist [korrekt?]
-> eine neue absolute Zeit überschreibt den timer, egal welcher Wert. D.h. eine neue absolute Zeit, bevor die laufende zu ende ist, verlängert ebenfalls die Ein-/Ausschaltzeit

=> In allen Fällen kann FHEM einen neuen Status setzen.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 30 März 2018, 18:37:34
Ja, das sind zwei Peerings für einen Taster.

ZitatBei "SHORT_JT_ON -> "ON"    // verlängern" bin ich mir nicht sicher. Meinem Verständnis nach kann ich On/Off delay Zeiten nur überspringen, aber nicht verlängern. Das ginge nur für On/Off Zeiten.

Das "SHORT_JT_ON ist für on. Beim Verlängern wird auch bei einer absoluten Zeit der on-Timer mit dem neuen Wert überschrieben.

Ich habe bei mir das "LONG_JT_ON -> "ON" gesetzt.
Wenn dann die short_on_time auf 5 Min und die long_on_time auf 60 Min steht,
dann wird das Licht mit einem kurzen Tastendruck für 5 Min eingeschaltet. Mit einem langen Tastendruck kann dann das Licht auf 60 Min verlängert werden.
Ich verwende nur absolute Zeiten.

Schau mal hier, da wird das im Teil 2 mit der minimalen und absoluten Zeit erklärt (ab der 19 Min):
http://www.homematic-inside.de/software/download/item/expertenparameter

Nachtrag:

Zitat-> Toggle wird ignoriert, [korrekt?]
Toggle verwende ich nicht.

Zitat-> neue Absolute Zeiten überschreiben den timer, auch mit Zeit == 0. [korrekt?]
Ja neue Absolute Zeiten überschreiben auch eine minimale Zeit.
Mir fällt nicht ein in welchem Fall überschreiben mit Zeit == 0 Sinn macht.
Hast Du mir für Zeit == 0 ein Beispiel.

ZitatAbsolute Zeit läuft:
alle Änderungen (über peerings) werden ignoriert - bis auf neue absolute Zeit, bis der timer abgelaufen ist [korrekt?]
Mir ist nicht klar wie das gemeint ist.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 30 März 2018, 22:16:15
Hallo,

Zitat von: Ralf9 am 30 März 2018, 18:37:34
Das "SHORT_JT_ON ist für on. Beim Verlängern wird auch bei einer absoluten Zeit der on-Timer mit dem neuen Wert überschrieben.

Ich habe bei mir das "LONG_JT_ON -> "ON" gesetzt.
Wenn dann die short_on_time auf 5 Min und die long_on_time auf 60 Min steht, dann wird das Licht mit einem kurzen Tastendruck für 5 Min eingeschaltet. Mit einem langen Tastendruck kann dann das Licht auf 60 Min verlängert werden. Ich verwende nur absolute Zeiten.

Schau mal hier, da wird das im Teil 2 mit der minimalen und absoluten Zeit erklärt (ab der 19 Min):
http://www.homematic-inside.de/software/download/item/expertenparameter
Ok, danke. Dann habe ich es nun richtig.
Das Video hatte ich mir auch angeschaut und Notizen gemacht, aber es lohnt sich es ein zweites mal, mit anderen Fragen im Kopf, zu sehen... und auch wenn alle paar Sekunden jemand hustet... :)  ::)

Zitat
Ja neue Absolute Zeiten überschreiben auch eine minimale Zeit.
Mir fällt nicht ein in welchem Fall überschreiben mit Zeit == 0 Sinn macht.
Hast Du mir für Zeit == 0 ein Beispiel.
Mit Zeit == 0 meinte ich "not_used".
Angenommen short_on_time ist 5 Min und die long_on_time auf "not_used". Wenn nun die 5 Min laufen, ich dann eine langen Tastendruck sende, erzwinge ich dann ein ausschalten? (long_jt_on steht auf OFF, bzw. über offdelay -> long_jt_offdelay -> off)


Was noch schön wäre, die Zeiten mit dem dynamischen Faktor zu nutzen, wie im Original, aber nicht als 2 byte Wert. Das wären pro peering 4 zusätzliche bytes.
Ich hatte versucht in der XML die Werte anzupassen, leider klappt es nicht. Bei 6 bit für den Wert und 2 bit für den Faktor sollte das maximum 63000 (63 * 1000) sein. Also 6 bits gesetzt und der vorletzte Faktor genommen werden.
z.B. EEPROM: 0x44 -> Faktor 60, Wert 4 -> 4*60 = 240 (Dezimal) -> in FHEM Wert : 240
Vermutlich hab ich da was falsch gemacht :( ---> value_size="0.8" nicht 0.6 :)
Der Fehler sieht auch nicht gut aus :)
2018.03.30 22:07:11 1: PERL WARNING: Use of uninitialized value in multiplication (*) at FHEM/lib/HM485/Device.pm line 1139.

NOT_USED -> alle bits gesetzt und maximaler Faktor => 63 * 6000 = 378000

<parameter id="SHORT_ON_TIME">
<logical type="float" min="0.0" max="63000.0" default="378000" unit="s">
<special_value id="NOT_USED" value="378000"/>
</logical>
<physical type="integer" size="1.0" interface="eeprom" endian="little">
<address index="+8"/>
</physical>
<conversion type="float_configtime" factors="1,60,1000,6000" value_size="0.8"/>
<conversion type="integer_integer_map">
<value_map device_value="0xc0" parameter_value="0xff" mask="0xc0"/>
</conversion>
</parameter>



Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 30 März 2018, 23:18:18
ZitatMit Zeit == 0 meinte ich "not_used".
Angenommen short_on_time ist 5 Min und die long_on_time auf "not_used". Wenn nun die 5 Min laufen, ich dann eine langen Tastendruck sende, erzwinge ich dann ein ausschalten? (long_jt_on steht auf OFF, bzw. über offdelay -> long_jt_offdelay -> off)

Ja, wenn das Licht an ist  und die 5 Min laufen, dann wird durch "long_jt_on ->OFF" mit einem langen Tastendruck das Licht ausgeschaltet.
Wenn die long_on_time auf "not_used" steht, dann wird mit einem langen Tastendruck das Licht eingeschaltet und bleibt an.
Wenn die long_on_time auf 0 steht, dann dürfte mit einem langen Tastendruck das Licht nicht mehr eingeschaltet werden können.

ZitatWas noch schön wäre, die Zeiten mit dem dynamischen Faktor zu nutzen, wie im Original, aber nicht als 2 byte Wert. Das wären pro peering 4 zusätzliche bytes.

Ich verwende den selben dynamischen Faktor,  wie im Original.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Shortie am 01 April 2018, 13:25:50
Ich nutze aktuell Arduino Nano, Max487 und dazu solche Step Down Regler um von den 24V auf 5V zu kommen: https://www.amazon.de/gp/product/B072BMBNG1

Mein Problem ist das mir aktuell reihenweise die Max487 sterben und ich nciht nachvollziehen kann warum. Unter anderem passiert das sogar beim Anstecken an einen leeren Bus (sind trotzdem schon mehrere Meter Kabel), Anschluss am Bus habe ich dabei über solche Stecker realisiert https://www.amazon.de/gp/product/B01MY8FLMV

Die Buchse sitzt dabei auf den HBW Devices mit folgender Belegung 1 - 24V, 2 - A, 3 - B, 4 - GND.

Hat jemand eine Idee woran das liegen kann? Kann man die Eingänge des Max487 auf einfache Art etwas absichern?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 01 April 2018, 14:24:04
Hi,

Mit leeren Bus meinst du einfach die Spannungsversorgung anlegen?
Dann hätte es ja nichts mit den Eingängen zu tun...

Hast du nach dem step down Wandler noch ein Elko oder weitere Kondensatoren?

Driver enable pin ist mit einem pull down verbunden? (und muss vom Arduino auf high gezogen werden)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Shortie am 01 April 2018, 14:42:19
Hi,

mit leerem Bus meine ich 24V und Gnd liegen an. Sonst keine weiteren Devices dran.
Der Step Down geht direkt auf den Arduino und Max487, ohne weitere Elkos oder Kondensatoren.
Der Max487 ist wie im Tutorial beschaltet, also RO an D4, RE und DE zusammen an D3 und DI an D2. A und B gehen direkt auf den Bus.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 01 April 2018, 15:47:30
Bedeutet bei Dir leerer Bus auch, daß die 24V abgeschaltet sind?
Haben das GND vom Max487 und das GND vom Bus evtl verschiedene Potentiale?
Ich verwende den LT1785.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Langerrenner am 01 April 2018, 18:31:05
Hallo Shortie,
beim stecken ist nicht sicher gestellt welcher Kontakt zuerst Kontakt macht. Da Du die 24V außen aufgelegt hast, kann es sein das Du zuerst die 24V und als nächstes den Bus A mit dem System verbindest. Der Max487 sieht nun 24V für kurze Zeit an seinen Eingängen. Das dürfte ihn zerstören.
Abhilfe: Zwei Stecker verwenden für Spannung und Bus. Oder Überspannungsfestere Typen als den MAX verwenden. Für den RS485 Bus gibt es Typen bis 60V Spannungsfestigkeit (Texas).
Oder Schutzbeschaltung. Ist später in der Anlage auch von Vorteil. Zwei 10Ohm in die Leitungen A und B. Zwischen Widerstände und Treiberbaustein Klemmdioden nach 5V und Masse.
So ist auch meine Anlage aufgebaut.
Gruß Willi
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Shortie am 01 April 2018, 20:34:02
Hi,

danke für die Ratschläge das erklärt die Probleme die ich aktuell habe.

Ich habe mal geguckt und die LT 1785 gefunden, die bis 60V Spannungsfest sind und auch Pinkompatibel zum Max487 sind. Wobei die Schutzschaltung trotzdem sehr sinnvoll klingt.

Nur ist es dann wohl sinnvoll sich doch wieder um eine kleine Platine Gedanken zu machen.

Gruß
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 01 April 2018, 21:34:46
Hi,
kaum ist man mal ein paar Tage nicht da und schon geht hier die Post ab.
Ich werde mir das ganze auch noch genauer anschauen. Damit sind v.A. die Entwicklungen von Thomas "loetmeister" gemeint. ...oder soll ich warten bis Du soweit bist und dann ein komplettes Review machen? (sofern ich das dann noch kapiere)
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: jochen_f am 01 April 2018, 22:13:52
Hallo,

erst einmal vielen Dank für das gute Tutorial und die vielen Informationen über das verwendete Protokoll.

Ich hatte hier noch ein paar alte Aktoren von Elektor mit einem Atmega88 rumliegen. Leider passte das in C++ bzw. mit Arduino entwickelte HBW dort nicht drauf. Daher habe ich mal geschaut, in wieweit eine optimierte C Implementierung funktionieren könnte.

Herausgekommen sind 3 Implementierungen, die jeweils auf das Elektor Testboard, das Relais Board und ein etwas aufgebohrtes Testboard passen. Sie benötigen ca. 5k Flash und passen damit bequem auf die Atmega88 Chips.

Implementiert sind Tasten, digitale Ein- und Ausgänge und auch Peerings.

Zu finden sind sie hier: https://git.colab.de/jochen/avr-hbw/

Eine Frage habe ich aber noch zu der XML Datei. Dort findet man manchmal einen Special Parameter "BEHAVIOUR", mit dem man scheinbar Alternativen bilden kann. Gibt es dazu genaueres? Ich würde die Port C Pins gerne alternativ als Analogeingänge nutzen, das sollte aber einstellbar sein. Geht das?

Gruß, Jochen
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 01 April 2018, 23:24:39
Zitat von: Thorsten Pferdekaemper am 01 April 2018, 21:34:46
Ich werde mir das ganze auch noch genauer anschauen. Damit sind v.A. die Entwicklungen von Thomas "loetmeister" gemeint. ...oder soll ich warten bis Du soweit bist und dann ein komplettes Review machen? (sofern ich das dann noch kapiere)

Hi Thorsten,

Ich passe noch XML und Code an das dynamischen Zeitformat an. Es wäre aber schon mal gut zu wissen ob die Änderungen an der lib ok sind.  ::)  8)
Man könnte in Zukunft eine switch simple und dazu passend link switch simple haben, mit dem bisherigen Funktionsumfang. Die erweiterten Funktionen als separate lib... Da weiß ich aber nicht wie das in der HBWired richtig einbindet um zwischen simple und advanced zu wechseln.

https://github.com/loetmeister/HBWired/commit/0dfb801c744f65bcdf50b9163986b35be134d6ee

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 02 April 2018, 22:14:36
Hi,
Zitat von: jochen_f am 01 April 2018, 22:13:52
Ich hatte hier noch ein paar alte Aktoren von Elektor mit einem Atmega88 rumliegen...
ich würde Dir empfehlen, dazu einen neuen Thread aufzumachen. Sollte tatsächlich jemand daran interessiert sein, dann wird derjenige kaum in diesem großen Thread zufällig drauf stoßen. (Ich verstehe sowieso nicht, warum sich immer wieder in sowieso schon unübersichtliche Threads gehängt wird.)

Zitat
Eine Frage habe ich aber noch zu der XML Datei. Dort findet man manchmal einen Special Parameter "BEHAVIOUR", mit dem man scheinbar Alternativen bilden kann. Gibt es dazu genaueres? Ich würde die Port C Pins gerne alternativ als Analogeingänge nutzen, das sollte aber einstellbar sein. Geht das?
Auch das wäre einen eigenen Thread wert, oder nicht?
Genaueres gibt es dazu nicht wirklich. Ich habe da auch eine ganze Weile herumexperimentiert, bis das in FHEM geklappt hat. Schau Dir dazu am besten mal eins der Standard-XMLs an von Geräten, die sowas können. Ich glaube, beim 12/14er findet man dazu einiges.
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 02 April 2018, 22:31:14
Zitat von: loetmeister am 01 April 2018, 23:24:39Ich passe noch XML und Code an das dynamischen Zeitformat an. Es wäre aber schon mal gut zu wissen ob die Änderungen an der lib ok sind.  ::)  8)
Beim "dynamischen Zeitformat" habe ich gesehen, dass Du das mit vier Bytes anstatt der üblichen zwei machen willst. Das finde ich jetzt nicht so toll. Warum willst Du das erweitern?

Die Änderungen in der Lib sehen im Prinzip gut aus. Du hast ja nur überall den Parameter keyPressNum dazugenommen. Das kann zwar zu Inkompatibilitäten führen, aber die sind dann ziemlich einfach zu korrigieren.
Nur eine Kleinigkeit hätte ich gern anders. In HBWired.cpp hast Du es so gemacht:

receiveKeyEvent(senderAddress, frameData[1], frameData[2], frameData[3], frameData[3] & 0x01);

Ich hätte es lieber so:

receiveKeyEvent(senderAddress, frameData[1], frameData[2], frameData[3] >> 2, frameData[3] & 0x01);

Die untersten zwei Bits haben nämlich nichts mit der Tastendruck-Nummer zu tun. Für das, was Du vorhast, spielt das zwar keine Rolle, aber es ist trotzdem "richtiger", würde ich sagen.
Schickst Du mir dann einen Pull-Request dazu?

Zitat
Man könnte in Zukunft eine switch simple und dazu passend link switch simple haben, mit dem bisherigen Funktionsumfang. Die erweiterten Funktionen als separate lib... Da weiß ich aber nicht wie das in der HBWired richtig einbindet um zwischen simple und advanced zu wechseln.
Also das keyPressNum bauen wir einfach für alle ein. Das tut ja kaum weh. Ansonsten, also für die ganzen vielen Einstellungen für Peerings, hätte ich erwartet, dass es halt für die "advanced"-Dinger eigene Subklassen von HBWChannel bzw. HBWLinkReceiver gibt, die dann im Konstruktor von HBWDevice verwendet werden.
Wahrscheinlich müsste ein Großteil der Logik in der neuen Subklasse von HBWLinkReceiver sein, d.h. wir bräuchten wahrscheinlich noch eine loop-Methode in HBWLinkReceiver. Das könnten wir aber einfach einbauen.

Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 03 April 2018, 00:58:14
Hi,

Zitat von: Thorsten Pferdekaemper am 02 April 2018, 22:31:14
Beim "dynamischen Zeitformat" habe ich gesehen, dass Du das mit vier Bytes anstatt der üblichen zwei machen willst. Das finde ich jetzt nicht so toll. Warum willst Du das erweitern?
Ja, es waren ursprünglich 2 Byte. Das kostet mir aber zu viel Platz im EEPROM, lieber mehr peerings, als Relais im Millisekunden Intervall schalten können  ::)

Bsp.: "HMW-LC-Sw2-DR" (16 bit)
<physical type="integer" size="2.0" interface="eeprom" endian="little">
[...]
<conversion type="float_configtime" factors="0.1,1,60,1000" value_size="1.6"/>


Ich habe es auf ein Byte und andere Multiplikatoren geändert. Damit sind immer noch 17,5 Stunden Zeiten möglich.
<logical type="float" min="0.0" max="63000.0" default="0.0" unit="s"/>
<physical type="integer" size="1.0" interface="eeprom" endian="little">
[...]
<conversion type="float_configtime" factors="1,60,1000,6000" value_size="0.8"/>

1 - 63 Sekunden (Sekundengenau)
60 - 3780  Sekunden (max. 63 Minuten, 60 Sekunden Schritte)
4000 - 63000 Sekunden (max. 17,5 Stunden, 1000 Sekunden Schritte ~16,6 Minuten)
... hoffe das stimmt. :)
Jedenfalls habe ich den Code und XML entsprechend angepasst. Testkaninchen ist HBW-LC-Sw-12.
(https://github.com/loetmeister/HBWired/tree/828c8a48382b0b32c61e4daf264e773bbccbb3ad/HBW-LC-Sw-12)

Zitat

receiveKeyEvent(senderAddress, frameData[1], frameData[2], frameData[3] >> 2, frameData[3] & 0x01);

Die untersten zwei Bits haben nämlich nichts mit der Tastendruck-Nummer zu tun. Für das, was Du vorhast, spielt das zwar keine Rolle, aber es ist trotzdem "richtiger", würde ich sagen.
Klingt gut, habe ich geändert.
Den bitshift hatte ich im link/set code... da hab ich es wieder raus genommen. Den Zusätzlichen Parameter hatte ich vorher "senderValue" genannt, aber dann auf keyPressNum geändert, da ja für den Event 0x4B/0xCB nur key events kommen sollten(?) :)

Pull-Request kommt..

Zitat
Also das keyPressNum bauen wir einfach für alle ein. Das tut ja kaum weh. Ansonsten, also für die ganzen vielen Einstellungen für Peerings, hätte ich erwartet, dass es halt für die "advanced"-Dinger eigene Subklassen von HBWChannel bzw. HBWLinkReceiver gibt, die dann im Konstruktor von HBWDevice verwendet werden.
Wahrscheinlich müsste ein Großteil der Logik in der neuen Subklasse von HBWLinkReceiver sein, d.h. wir bräuchten wahrscheinlich noch eine loop-Methode in HBWLinkReceiver. Das könnten wir aber einfach einbauen.
Schaue ich mir die Tage mal an. Im Moment ist der Code über HBWLinkSwitch (HBWLinkReceiver), HBWChanSw::set und HBWChanSw::loop verteilt...

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 04 April 2018, 23:06:31
Hi,
das wird jetzt mal wieder alles relativ viel... D.h. es kann gut sein, dass ich da was übersehe.

Zitat von: loetmeister am 03 April 2018, 00:58:14
Ja, es waren ursprünglich 2 Byte. Das kostet mir aber zu viel Platz im EEPROM, lieber mehr peerings, als Relais im Millisekunden Intervall schalten können  ::)
Ach so. Ich dachte, Du wolltest das von 2 auf 4 erweitern. Das hätte ich etwas seltsam gefunden, so finde ich es nur etwas unschön. Hast Du mal ausgerechnet, wie viele Peerings Du mit den beiden Varianten hinbekommen würdest?

Zitat
aber dann auf keyPressNum geändert, da ja für den Event 0x4B/0xCB nur key events kommen sollten(?) :)
Ja, genau. Das ist nur für Key Events.

Zitat
Pull-Request kommt..
Ich dachte eigentlich, dass der Pull-Request nur für die keyPressNum Erweiterung ist. Das, was Du mir jetzt geschickt hast, ist für alle Änderungen. Das würde ich ungern einfach so übernehmen. Kannst Du das irgendwie splitten, so dass ich erst einmal nur die keyPressNum-Änderungen übernehmen kann?

Zitat
Schaue ich mir die Tage mal an. Im Moment ist der Code über HBWLinkSwitch (HBWLinkReceiver), HBWChanSw::set und HBWChanSw::loop verteilt...
Das habe ich jetzt auch gesehen, wobei da ein paar Sachen dabei sind, die mir noch nicht so gefallen bzw. zu dem ich noch Fragen/Kommentare habe.

NO_DEBUG_OUTPUT: Gab es da ein Problem oder warum willst Du das abschalten?

Momentan wird in HBWLinkSwitch nur das EEPROM ausgelesen, aber die "eigentliche Arbeit" ist beim Aktor selbst. Das finde ich nicht so geschickt. Meiner Meinung nach sollte die ganze Logik im LinkReceiver (also HBWLinkSwitch in dem Fall) sein. Insbesondere sollte die set-Methode nicht so missbraucht werden. Es sollten nur die Daten übergeben werden, die tatsächlich für ein "set" gebraucht werden.

TOGGLE_TO_COUNTER (und ähnliche): Was ist denn das? Wo gibt es das ansonsten bei HMW? Die Implementierung sieht so aus, als ob man damit erreichen will, dass auch bei "vergessenen" Tastendrücken richtig getoggelt wird. Ich denke, dass das bei Peerings mit mehreren Tastern seltsame Effekte geben kann, genauso bei gemischten kurzen und langen Tastendrücken, die unterschiedliche Sachen machen sollen. (Die Zählung ist für kurze und lange gemeinsam.)

Funktioniert das hier wirklich?

device->readEEPROM(&data, eepromStart + EEPROM_SIZE * i + 6, 7);     

(Aus HBWLinkSwitch::receiveKeyEvent)
Die Variable data ist ja schon ein Zeiger (Arrays und Zeiger sind fast dasselbe). D.h. mir ist nicht so ganz klar, wo &data tatsächlich hinzeigt. Vielleicht hier sicherheitshalber pdata verwenden (natürlich nicht &pdata).
   
Gruß,
   Thorsten   
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 05 April 2018, 00:37:40
Hi Thorsten,

Zitat von: Thorsten Pferdekaemper am 04 April 2018, 23:06:31
Ach so. Ich dachte, Du wolltest das von 2 auf 4 erweitern. Das hätte ich etwas seltsam gefunden, so finde ich es nur etwas unschön. Hast Du mal ausgerechnet, wie viele Peerings Du mit den beiden Varianten hinbekommen würdest?
Wenn ich die ersten 32 byte im EEPROM reserviere, habe ich bei 12 Kanälen ein zusätzliches peering pro Kanal "gewonnen".
address_step="20" address_start="0x20" --> 49 (4 peerings pro Kanal - 12 Kanäle im Device)
Bei der Original Zeit Konfiguration sind es 8 byte mehr, also step 28 --> 35 peerings

ZitatIch dachte eigentlich, dass der Pull-Request nur für die keyPressNum Erweiterung ist. Das, was Du mir jetzt geschickt hast, ist für alle Änderungen. Das würde ich ungern einfach so übernehmen. Kannst Du das irgendwie splitten, so dass ich erst einmal nur die keyPressNum-Änderungen übernehmen kann?
Hm... ich müsste wohl einen eigenen Branch anlegen... und nur noch pull requests für den "sauberen" master stellen :)
Bisher habe ich ja nur HBW-LC-Sw-12 "verbastelt und dort eine Kopie der LinkSwitch lib abgelegt....

ZitatNO_DEBUG_OUTPUT: Gab es da ein Problem oder warum willst Du das abschalten?
Nein, kein Problem. Wollte es nur per direktive abschaltbar machen - für die "produktiven" Geräte. Weniger im loop()  ;)

Zitat
Momentan wird in HBWLinkSwitch nur das EEPROM ausgelesen, aber die "eigentliche Arbeit" ist beim Aktor selbst. Das finde ich nicht so geschickt. Meiner Meinung nach sollte die ganze Logik im LinkReceiver (also HBWLinkSwitch in dem Fall) sein. Insbesondere sollte die set-Methode nicht so missbraucht werden. Es sollten nur die Daten übergeben werden, die tatsächlich für ein "set" gebraucht werden.
Ich versuche das mal etwas besser aufzuteilen...
Wäre es möglich/sinvoll alles in HBWLinkSwitch zu packen? Die meisten Vorgänge beziehen sich ja auf einen bestimmten Kanal. (Alle timer, Status, etc.)
Das eigentlich set() ist in setOutput() gewandert. Ich schaue das ich set() wieder ins original versetzte, dann brauche ich aber eine neue Funktion im HBWSwitch, die ich in HBWLinkSwitch aufrufen kann, statt set().

Zitat
TOGGLE_TO_COUNTER (und ähnliche): Was ist denn das? Wo gibt es das ansonsten bei HMW? Die Implementierung sieht so aus, als ob man damit erreichen will, dass auch bei "vergessenen" Tastendrücken richtig getoggelt wird. Ich denke, dass das bei Peerings mit mehreren Tastern seltsame Effekte geben kann, genauso bei gemischten kurzen und langen Tastendrücken, die unterschiedliche Sachen machen sollen. (Die Zählung ist für kurze und lange gemeinsam.)
Das gibts im original Dimmer. Bei ungeraden Tastendruckzähler wird Eingeschaltet, bei geraden Aus. Damit kann man bei einem mehrfach peering für eine Taste (z.B. nur kurzer Tastendruck) alle Ausgänge gleich schalten. (spätestens nach der zweiten Betätigung ist es wieder synchron)
Das"normale" toggle ist ja noch da... :)

ZitatFunktioniert das hier wirklich?

device->readEEPROM(&data, eepromStart + EEPROM_SIZE * i + 6, 7);     

(Aus HBWLinkSwitch::receiveKeyEvent)
Die Variable data ist ja schon ein Zeiger (Arrays und Zeiger sind fast dasselbe). D.h. mir ist nicht so ganz klar, wo &data tatsächlich hinzeigt. Vielleicht hier sicherheitshalber pdata verwenden (natürlich nicht &pdata).
Hat funktioniert... sollte eigentlich beides auf die Adresse/Anfang des Arrays data[] zeigen. Jedenfalls bekomme ich die Werte aus dem EEPROM. :)
Ich kann auch *pdata wieder raus nehmen. Brauche ich gar nicht mehr....
        device->readEEPROM(&data, eepromStart + EEPROM_SIZE * i + 13, 7);     // read all parameters (must be consecutive)
        device->set(targetChannel,NUM_PEER_PARAMS,data);


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 05 April 2018, 14:38:28
Zitat von: loetmeister am 05 April 2018, 00:37:40
Wenn ich die ersten 32 byte im EEPROM reserviere, habe ich bei 12 Kanälen ein zusätzliches peering pro Kanal "gewonnen".
address_step="20" address_start="0x20" --> 49 (4 peerings pro Kanal - 12 Kanäle im Device)
Bei der Original Zeit Konfiguration sind es 8 byte mehr, also step 28 --> 35 peerings
Ich glaube zwar nicht, dass Du jemals auch nur die 35 ausnutzen wirst, aber ich kann mich auch irren. Bei mir daheim habe ich meistens die Original 12/7er eingebaut und im Durchschnitt wahrscheinlich so ungefähr 1,5 Peerings pro Switch.
Ich fände es halt schöner, wenn wir erst einmal eine Art Standard-Peering zusammengebastelt bekommen, aber diese Stelle kann man später leicht noch ändern oder eben zwei Versionen machen.

Zitat
Hm... ich müsste wohl einen eigenen Branch anlegen... und nur noch pull requests für den "sauberen" master stellen :)
Bisher habe ich ja nur HBW-LC-Sw-12 "verbastelt und dort eine Kopie der LinkSwitch lib abgelegt....
Wenn das so richtig Aufwand wird, dann lass es mal. So wichtig ist es ja nicht, dass wir das sofort reinbringen. Den Aufwand sollten wir dann lieber in eine vollständige und gute Lösung stecken.

Zitat
Nein, kein Problem. Wollte es nur per direktive abschaltbar machen - für die "produktiven" Geräte. Weniger im loop()  ;)
Ok. Es wäre schön, wenn wir zwei serielle Schnittstellen in der Hardware hätten, aber dann müsste man sich wieder was eigenes basteln oder etwas größeres nehmen. Möglicherweise ist es "abschaltbar" gar nicht so schlecht.

Zitat
Ich versuche das mal etwas besser aufzuteilen...
Wäre es möglich/sinvoll alles in HBWLinkSwitch zu packen? Die meisten Vorgänge beziehen sich ja auf einen bestimmten Kanal. (Alle timer, Status, etc.)
Ich glaube trotzdem, dass das alles im HBWLinkSwitch abgehandelt werden sollte. Die ganzen Einstellungen beziehen sich auf die Verknüpfung. Außerdem sollten im Kanal eher die Hardware-Spezifika gekapselt sein. D.h. es wäre schön, wenn wir eine "Link"-Klasse hätten, die man dann mit verschiedenen "Switch"-Klassen verwenden kann. Bei Deinem Gerät scheint ja schon die Hardware etwas besonders zu sein.

Zitat
Das eigentlich set() ist in setOutput() gewandert. Ich schaue das ich set() wieder ins original versetzte, dann brauche ich aber eine neue Funktion im HBWSwitch, die ich in HBWLinkSwitch aufrufen kann, statt set().
Siehe oben. Ich glaube, dass man das hinbekommen kann, ohne irgend etwas an der Switch-Klasse zu ändern. Das einzige, was man meiner Meinung nach hinzufügen müsste, ist eine loop-Methode in der Link-Klasse, die dann automatisch regelmäßig aufgerufen wird.

Zitat
Das gibts im original Dimmer. Bei ungeraden Tastendruckzähler wird Eingeschaltet, bei geraden Aus. Damit kann man bei einem mehrfach peering für eine Taste (z.B. nur kurzer Tastendruck) alle Ausgänge gleich schalten. (spätestens nach der zweiten Betätigung ist es wieder synchron)
Das"normale" toggle ist ja noch da... :)
Ah, jetzt ja. Ich hab's jetzt auch gefunden. Das klingt tatsächlich sinnvoll und ich könnte das bei mir sogar anwenden. Die 12/7er haben das leider nicht, wie es aussieht.

Zitat
Hat funktioniert... sollte eigentlich beides auf die Adresse/Anfang des Arrays data[] zeigen. Jedenfalls bekomme ich die Werte aus dem EEPROM. :)
Ich habe mir gerade nochmal die C++-Feinheiten dazu betrachtet. Tatsächlich ist es wohl in dem Fall egal, ob man "&data" oder einfach nur "data" verwendet, da wir sowieso auf void* casten. Ich habe nur noch nie gesehen, dass jemand das mit "&data" macht.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 07 April 2018, 01:04:52
Hi,

Zitat von: Thorsten Pferdekaemper am 05 April 2018, 14:38:28
Ich glaube trotzdem, dass das alles im HBWLinkSwitch abgehandelt werden sollte. Die ganzen Einstellungen beziehen sich auf die Verknüpfung. Außerdem sollten im Kanal eher die Hardware-Spezifika gekapselt sein. D.h. es wäre schön, wenn wir eine "Link"-Klasse hätten, die man dann mit verschiedenen "Switch"-Klassen verwenden kann.
[...]
dass man das hinbekommen kann, ohne irgend etwas an der Switch-Klasse zu ändern. Das einzige, was man meiner Meinung nach hinzufügen müsste, ist eine loop-Methode in der Link-Klasse, die dann automatisch regelmäßig aufgerufen wird.
Möglich ist das bestimmt... ob ich das auf die Reihe bekomme eine andere Frage  ::)

Angenommen ich nehme meinen neuen Code aus dem set() und loop() der Switch Klasse raus, da würde ich folgende Unterteilung vornehmen.
In der Klasse von HBWLinkSwitch (HBWLinkReceiver) müsste ich Arrays für alle Variablen anlegen welche ich später im loop() brauche. Den HBWLinkReceiver loop dann genau wie den channels loop() im device loop aufrufen?

HBWLinkReceiver receiveKeyEvent()
// read EEPROM (wie bisher auch), direkte Aktionen prüfen, die direkt ausgeführt werden können -> channel set(), z.B.:
// SHORT_ACTION_TYPE, ACTIVE
// TOGGLE_USE
// store values from peering/EEPROM for state machine (um sie im loop() zu nutzen)
// jumpTargets[NUM_CHANNELS], on/offTime[NUM_CHANNELS], on/offDelayTime[NUM_CHANNELS], usw.

HBWLinkReceiver loop()
// state machine
// check timer, set new timer, set new state
// lastStateChangeTime[targetChannel]; / stateCangeWaitTime[targetChannel];

void HBWDevice::loop()
   for(uint8_t i = 0; i < numChannels; i++) {
        channels[i]->loop(this,i);
       HBWLinkReceiver->loop(i); // <--- neu
}


Geht das in die Richtig, die du angedacht hast? Was mich noch ein wenig verunsichert, die Aussage: "Die ganzen Einstellungen beziehen sich auf die Verknüpfung"
Die Einstellungen / Werte kommen von der Verknüpfung, beziehen sich aber auf den Verknüpften Kanal. Ich muss ja weiter die nächsten Aktionen ausführen können. (z.B. nach einem on delay in die jumpTargets schauen und z.B. zur on Time springen, o.ä.).

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 07 April 2018, 22:52:28
Hi,
ich habe jetzt nochmal ein bisschen darüber nachgedacht. Es ist wohl tatsächlich etwas ungeschickt, alles in der HBWLinkReceiver-Subklasse abzuarbeiten. Das Ding weiß schonmal gar nicht, wie viele Kanäle es eigentlich gibt und das ganze dynamisch zu machen ist auf so kleiner Hardware nicht wirklich gut.
Also müsste man die "state machine" im Kanal selbst (HBWSwitch) implementieren, während HBWLinkSwitch sozusagen nur die Liste abklappert und das EEPROM liest. Natürlich muss HBWLinkSwitch dann auch die Daten irgendwie an den Kanal weitergeben. Das sollte dann aber meiner Meinung nach mit einer neuen Methode passieren und nicht mit set(). Wie wär's mit triggerEvent()?
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 12 April 2018, 00:18:27
Hi,

Zitat von: Thorsten Pferdekaemper am 07 April 2018, 22:52:28
Also müsste man die "state machine" im Kanal selbst (HBWSwitch) implementieren, während HBWLinkSwitch sozusagen nur die Liste abklappert und das EEPROM liest. Natürlich muss HBWLinkSwitch dann auch die Daten irgendwie an den Kanal weitergeben. Das sollte dann aber meiner Meinung nach mit einer neuen Methode passieren und nicht mit set(). Wie wär's mit triggerEvent()?

Klingt gut.. habe mal peeringEventTrigger() als namen genommen. Bisher ist es sehr nah an der original set() Funktion, auch was den Aufruf über das Device angeht. Könnte man das eleganter/einfacher lösen?

Der Aufbau ist wie folgt. ("set()" ist wieder Standard, d.h. nur Ausgänge und logging setzen)

In HBWLinkSwitch::receiveKeyEvent wird peeringEventTrigger() aufgerufen:
device->peeringEventTrigger(targetChannel,data);    // channel, data

Dann über HBWired:
void HBWDevice::peeringEventTrigger(uint8_t channel, uint8_t const * const data){
// to avoid crashes, do not try to set any channels, which do not exist
if(channel < numChannels)
        channels[channel]->peeringEventTrigger(this, data);
}


Um dann in HBWChannelSw::peeringEventTrigger oder loop() den Ausgang mit "set()" zu setzten:
this->set(device,1,&level);

Die weitere Methode hat 6 Byte RAM und 112 Byte Programmspeicher gekostet...  ???


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 13 April 2018, 14:26:03
Zitat von: loetmeister am 12 April 2018, 00:18:27
Klingt gut.. habe mal peeringEventTrigger() als namen genommen. Bisher ist es sehr nah an der original set() Funktion, auch was den Aufruf über das Device angeht. Könnte man das eleganter/einfacher lösen?
Im Prinzip finde ich das elegant. Man hat eine Indirektion über HBWDevice, so dass die Link-Klasse gar nicht wissen muss, was da für Channels dranhängen. Außerdem erlaubt man HBWDevice, die Channels so zu verwalten, wie es gerade passt. Wenn die Link-Klasse direkt auf die Channels-Liste zugreifen würde könnte man das nicht mehr so machen. Unschön ist natürlich, dass es viel Programmspeicher etc. kostet.

Zitat
Die weitere Methode hat 6 Byte RAM und 112 Byte Programmspeicher gekostet...  ???
Mmm... Also was im Prinzip immer gemacht werden muss ist die Prüfung, ob der Kanal überhaupt existiert (es ist relativ einfach, ein kaputtes Peering anzulegen, was ansonsten das Device lahmlegen könnte). Aber wir können uns vielleicht sparen, die Methode "virtual" zu machen. Dann könnte man es noch mit "inline" versuchen. Also statt...

virtual void peeringEventTrigger(HBWDevice*, uint8_t const * const data);

...das Ding mal so deklarieren:

inline void peeringEventTrigger(HBWDevice*, uint8_t const * const data);

Da die Methode nur an einer Stelle aufgerufen wird dürfte das zumindest nicht mehr Programmspeicher brauchen.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 14 April 2018, 01:31:03
Hi,

Zitat von: Thorsten Pferdekaemper am 13 April 2018, 14:26:03
...das Ding mal so deklarieren:

inline void peeringEventTrigger(HBWDevice*, uint8_t const * const data);

Da die Methode nur an einer Stelle aufgerufen wird dürfte das zumindest nicht mehr Programmspeicher brauchen.

Danke. Habe mal "wild" rumprobiert. In class HBWChannel kann ich es nicht auf "inline" ändern. Dann spar ich zwar 88 Byte aber es läuft nicht mehr. :o  ;D
In class HBWDevice kann ich es ändern, spart 26 Byte.

Ich schau mal das ich was aufräume und es als library HBWSwitchAdvanced und HBWLinkSwitchAdvanced verpacke...

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 April 2018, 09:14:49
Zitat von: loetmeister am 14 April 2018, 01:31:03Danke. Habe mal "wild" rumprobiert. In class HBWChannel kann ich es nicht auf "inline" ändern. Dann spar ich zwar 88 Byte aber es läuft nicht mehr. :o  ;D
Nein, da geht das natürlich nicht. Dort brauchst Du ja den Vererbungsmechanismus.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 14 April 2018, 19:20:10
Hallo,

habe ein wenig getestet. Peerings und über FHEM.
Das Verhalten der peerings ist denke ich ok, absolute Zeiten überschreiben minimale, delay Zeiten können übersprungen werden, etc.
Toggle (toggle [invers] to counter) lasse ich nur zu wenn keine timer laufen...

Wenn ich aus FHEM ein on/off schicke bin ich mir über das richtige Verhalten nicht ganz klar... aktuell wird immer ein- oder aus geschaltet, ohne aber die timer zu löschen. D.h. läuft der aktuelle timer dann aus, wird wieder aus dem aktuellen Status begonnen: jump table gelesen und z.B. von ON nach offdelay gewechselt.
Bsp. onDealy läuft, FEHM schickt ON -> nach Ablauf des onDealy timers wird zu OFF gewechselt. Der Ausgang war nur kurz eingeschaltet, wäre weder über das peering, noch FHEM das gewünschte verhalten...  ???

Wenn ich die timer bei einem set() aufruf über FHEM löschen will, nicht aber über ein peering (peeringEventTrigger), bastel ich wieder an der set() Funktion rum... :)

Aktueller Stand: https://github.com/loetmeister/HBWired/blob/master/HBW-LC-Sw-12/HBW-LC-Sw-12.ino

Edit:
Ich habe mal HBW-LC-Sw-8 mit dem erweiterten Peering erstellt. Ist eventuell was übersichtlicher als der HBW-LC-Sw-12...
Da habe ich peeringEventTrigger() erst mal wieder raus genommen. Mit set() finde ich es eigentlich ganz gut... so "missbraucht" wird die Methode gar nicht ;)
https://github.com/loetmeister/HBWired/tree/master/HBW-LC-Sw-8_AdvancedPeering
https://github.com/loetmeister/HBWired/tree/master/libraries/HBWSwitchAdvanced

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 16 April 2018, 20:41:13
Hi,
sorry, dass ich mir das bisher nicht genauer betrachtet habe. Ich hab's aber noch vor...
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 18 April 2018, 21:11:50
Hi,
ich komme zurzeit beim besten Willen nicht dazu, mir das ganze wirklich richtig anzuschauen. Ich habe daher Deinen Pull-Request einfach so übernommen. Ich denke, Du weißt, was Du da tust.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 24 April 2018, 22:32:28
Hi Thorsten,

Danke. Es kommen wahrscheinlich nach dem Testen der Elektronik noch ein paar Korrekturen...  ;)


Apropos Elektronik. Für HBW-LC-Sw-12 habe ich mal angefangen die erste Version der Platine zu bestücken und zu testen. Die Platine mit Atmega 328p, MAX 487CSA/ECSA und Spannungsversorgung soll vom grundsätzlichen Aufbau in allen Geräten gleich sein. Sie sitzt oben im Gehäuse und nimmt auch ISP Anschluss, LEDs und Taster auf. Dann gibt es eine weitere Platine auf der Relais und Klemmen montiert sind.
Der Atmel muss hier per ISP geflasht werden, das Hex File lässt sich aber per Arduino IDE erstellen.
Ein Bild vom Gerät im Anhang. Das Gehäuse hat 6 TE.


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: derHeimwerker am 25 April 2018, 07:52:53
Hallo Thomas,

wow ... Respekt. Sieht ja sensationell aus. Wenn du die Herstellungskosten durch eine erhöhte Abnahmemenge senken möchtest dann sag gerne Bescheid. Das Projekt "Heimkinosteuerung" steckt zwar noch in den Kinderschuhen, ist aber für die nächsten Winterabende vorgesehen :-)

Gruß
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 01 Mai 2018, 01:01:18
Hallo Namensvetter, ;)

bisher belaufen sich die Kosten auf die Bauteile, die Platinen fräse ich selber. Ob ich das in größerer Stückzahl mache... mal sehen.
Im Anhang mal die Erste Version des HBW-LC-BL-8 (HBW-LC-BL-4, wenn man die Erweiterungsplatine weg lässt). Wahrscheinlich erstelle ich noch eine kleinere Erweiterung, die dann 3, statt 4 weitere Kanäle, aber in einem 4TE Gehäuse bringt (statt 6TE).
Also 4 + 4, oder 4 + 3 Kanäle/Rollos.

Wie man sieht haben die Platinen größenteils SMD Bauteile. Damit es nicht ganz so fummelig wird, ist nichts kleiner als Bauform 0805 (Länge 2 mm und eine Breite 1,25 mm)
(ok... die LEDs sind 0603, hatte noch 200 Stück :) - es passen aber auch 0805 drauf)


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 01 Mai 2018, 20:18:20
Hallo,

eine Frage an die, die schon länger in diesem Thread dabei sind... Thorsten?  ;)

Über die Liste im Wiki der Wired Geräte (https://wiki.fhem.de/wiki/HomeMatic_Wired#Aktoren_.2F_Sensoren) bin ich auf der GitHub Seite von Harald Glaser über die folgende change history gestolpert.

https://github.com/hresalg/HMW
Sep. 2016 Harald Glaser (hglaser-at-linuxen.at)
      -einige kleine Änderungen
      -Discovery hinzugefügt
      -Fallback Adresse und Modul Type dem Modul zugeordnet
      -frameControlByte in die untere HMWRS485 Schicht verlagert
      -Modul On/Off u.a. für Discovery
      -short_key_events senden/empfangen
      -long_key_events senden/empfangen TODO Broadcast empfangen
Okt. 2016
   - Timing verbessert
   - Sende- und Empfangsfolgenummer implementiert


Nach dem Datum und der Code Struktur handelt es sich wohl um Ergänzungen und Änderungen an der alten Lib?
Ein paar Dinge klingen ganz nützlich, z.B. "Modul On/Off u.a. für Discovery" oder auch "Sende- und Empfangsfolgenummer".
Hatte aktuelle und die Lib von Harald Glaser mal verglichen... die Unterschiede sind mittlerweile recht groß, zumindest Geräte für "Discovery" auf dem Bus müsste aber recht einfach eingebaut werden können...


PS: Der Link im Wiki für "HBW-CC-Vd2-T" auf GitHub führt in leere (Steuerung 24V-Ventile). Das finale Gerät scheint  -> https://github.com/hresalg/HBW_CC_VD2_FM zu sein, auch wenn es eine andere ID hat (ID 0x97).

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: derHeimwerker am 02 Mai 2018, 08:58:50
Hi Thomas,

mit der Platine machst du deinem Nickname aber allen Ehren ! Mich interessiert vor allem eine 230V Dimmer Platine. Da habe ich bisher im Netz so überhaupt nichts finden können. Eine Relaisplatine für diverse Hifi Komponenten würde ich dir aber auch abnehmen :-)

Weiterhin viel Spaß !
Gruß
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 05 Mai 2018, 00:31:05
Hi,

ein 230V Dimmer ist noch eine Sache bei der ich unschlüssig bin wie man das am besten Umsetzten kann. Einen Vernünftigen Phasenanschnitt/-abschnitt Dimmer zu bauen, der einem nicht die Unterverteilung abfackelt ist nicht mal eben gemacht... falls jemand Schaltpläne oder Vorschläge hat, immer her damit. :)

Optionen, die ich aktuell sehe:
1. Homematic HMW-LC-Dim1L-DR
    + Original Homematic Komponente
    - Preis, ca. 80,-
    - Nur Phasenanschnitt (230V LED Lampen brauchen teilw. Phasenabschnitt)
    - 2TE für nur einen Kanal


2. Eigenbau 6 Kanal Modul + 0-10V Dimmer
-> Die 6 PWM Kanäle des Ardunio (z.B. atmega328p) in 0-10V wandeln, dort können dann Dimmer, Trafos, etc. mit 0-10V "Schnittstelle" angeschossen werden.
    z.B.: Finder Typ 15.11 - Slave Dimmer (ca. 45,-)
    • Ansteuerung über 0...10 V / 1...10 V
    • Phasenanschnitt- und Phasenabschnitt-Dimmverfahren
    • Kurzschluß-, Übertemperatur-Schutz und Thermosicherung
    https://www.findernet.com/sites/default/files/2017-01/adv15de.pdf
    + Das Homebrew Modul wäre universell für Geräte mit 1-10V Eingang einsetzbar

Alternativ zum Finder Slave Dimmer: Eltako LUD12-230V https://www.eltako.com/fileadmin/downloads/de/datenblatt/Datenblatt_LUD12-230V.pdf
Statt 0-10V, PWM-Ansteuerung:
Frequenz: 100 Hz
Dutycycle: 0 (= Aus) linear bis 90 % (= volle Ausgangsspannung)
    + Vorteil, keine Wandlung PWM -> Analogspannung
    - Nachteil, weniger universell?


3. Kompletter Eigenbau...
Phasenanschnitt, (Komparator aus PWM-> Analogsignal speisen? https://www.mikrocontroller.net/attachment/8285/dimmer.jpg)
-> Galvanische Trennung unbedingt nötig! Überlast/Übertemperatur, Absicherung, etc. zu Beachten!!!


Mein Favorit ist aktuell Option 2 mit 0-10V ;)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: hresalg am 05 Mai 2018, 01:18:07
Hallo Thomas
Zitat
PS: Der Link im Wiki für "HBW-CC-Vd2-T" auf GitHub führt in leere (Steuerung 24V-Ventile). Das finale Gerät scheint  -> https://github.com/hresalg/HBW_CC_VD2_FM zu sein, auch wenn es eine andere ID hat (ID 0x97).
tut mir leid, ich hab den HBW-CC-Vd2-T gelöscht, weil ich das Modul komplett umgeschrieben habe und jetzt nicht mehr auf Arduino Basis ist, sondern nur mehr normales gcc-avr. Auch einen Bootloader habe ich bereits. nur ist er noch immer ziemlich groß. (~2400 byte). Ich stelle es wieder online wenn ich fertig bin. also bitte nicht aus dem wiki löschen.

H.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 15 Mai 2018, 21:55:39
Hi Harald,

alles klar. Dann bin ich mal auf die neue Version gespannt.  8)


Ich hab mir derweil weiter mit meinen Testgeräten. Rollo und Schaltaktor komplett mit Relais bestückt...
Beim testen des HBW-LC-Sw-12 ist mir aufgefallen, dass bei einer Änderung der Kanalkonfiguration (logging, inverted, o.ä.) alle Kanäle zurückgesetzt werden.
Das ist natürlich Käse... :)
Daher habe ich die lib für HBWSwitch und HBWSwitchAdvanced angepasst, so das afterReadConfig() nur beim ersten Einschalten die Kanäle auf AUS setzt.
HBW-LC-Sw-8 und HBW-LC-Sw-8_AdvancedPeering sind somit mit einer neuen Version im github.
https://github.com/loetmeister/HBWired/tree/master/libraries

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 21 Mai 2018, 23:26:08
Hallo,

wie erwänt habe ich HBWSwitch und HBWSwitchAdvanced angepasst, so das afterReadConfig() nur beim ersten Einschalten die Kanäle auf AUS setzt (+ invert Option).
Dazu würde ich die Tage einen Pull Request stellen. Hier der diff:
https://github.com/ThorstenPferdekaemper/HBWired/compare/master...loetmeister:master#diff-c3decd83a85f5d65f1781e8f756c0157
Sieht nach viel aus, das meiste sind aber kleine Korrekturen, nur an HBW-LC-Sw-12 habe ich noch ein paar mehr Dinge verändert.


Die zweite Sache mit der ich mich beschäftige, ist Modul On/Off bzw. dann auch "Discovery" Funktion, die Harald Glaser bereits eingebaut hat... würde versuchen viel davon zu Übernehmen.  ;)
Bevor das kommt, sollte aber erst mal 'Z' und 'z' - "zero communication" Modus funktionieren.

Dazu habe ich den Code in HBWDevice::processEvent() wieder aktiviert. Wenn der "zero communication" Modus aktiv ist, dann wird nur noch auf 'Z' und 'u' reagiert.
Denke das ist soweit ok... die Discovery Funktion würde ja noch eine Ebene tiefer arbeiten.
Um auf HBWDevice Ebene keine Sendeaktivität zuzulassen, habe ich
     if (pendingActions.zeroCommunicationActive) return 1;    // don't send in zeroCommunication mode, return with "bus busy" instead
in die folgenden Funktionen eingefügt:
Das ist 5 mal die selbe "if" Abfrage. Nicht besonders elegant... mir ist aber keine zentrale Stelle eingefallen in die das besser passen würde.  ???

Hier die Änderungen an processEvent() und broadcastAnnounce() als Beispiel:
@@ -379,19 +383,26 @@ void HBWDevice::processEvent(byte const * const frameData, byte frameDataLength,
       // Wenn irgendwas von Broadcast kommt, dann gibt es darauf keine
       // Reaktion, ausser z und Z (und es kommt von der Zentrale)
       // TODO: Muessen wir pruefen, ob's wirklich von der Zentrale kommt?
+      if(isBroadcast) {
+         switch(frameData[0]) {
+            case 'Z':                                            // End discovery mode
+            pendingActions.zeroCommunicationActive = false;
+            break;
+          case 'z':                                              // start discovery mode
+            pendingActions.zeroCommunicationActive = true;
+            break;
+        }
+        return;
       };
+
+         if (pendingActions.zeroCommunicationActive) {                         // block any messages in this state, except:
+         /* case 'u':                                                              // Update (Bootloader starten)
+            // Bootloader neu starten
+            // Goto $7c00                                                          ' Adresse des Bootloaders
+               // TODO: Bootloader?
+               break; */
+                 return;
+         };

       txTargetAddress = senderAddress;
       // gibt es was zu verarbeiten -> Ja, die Kommunikationsschicht laesst nur Messages durch,

@@ -564,13 +576,14 @@ void HBWDevice::receiveKeyEvent(uint32_t senderAddress, uint8_t srcChan,

    // "Announce-Message" ueber broadcast senden
    byte HBWDevice::broadcastAnnounce(byte channel) {
+      if (pendingActions.zeroCommunicationActive) return 1;    // don't send in zeroCommunication mode, return with "bus busy" instead
       txTargetAddress = 0xFFFFFFFF;  // broadcast
       txFrameControlByte = 0xF8;     // control byte
......... usw.



Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 24 Mai 2018, 20:03:11
Zitat von: hresalg am 05 Mai 2018, 01:18:07
[...] Auch einen Bootloader habe ich bereits. nur ist er noch immer ziemlich groß. (~2400 byte). Ich stelle es wieder online wenn ich fertig bin.

Hallo,

Wenn du mit dem Bootloader noch nicht fertig bist, könnte man nicht den folgenden bootloader nehmen und anpassen? Er soll CCU Kompatibel sein
https://github.com/haus-bus/HBW-Devices/tree/HM-Wired/Firmware/HBW-Booter


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 31 Mai 2018, 00:24:21
Hallo,

beim testen des "Discovery" ist mir aufgefallen das es nicht richtig funktioniert (mag an meinem USB - RS485 Adapter liegen, o.a.) und FHEM alle gescannten Geräte "gefunden" hat [Nachtrag. Eigene Doofheit: beim testen hat mein test Deive alle Discovery Nachrichten positiv beantwortet. Also war für jede angefragte Adresse fälschlicherweise ein Gerät vorhanden]. Auch ist mit "auto create", die Discovery Funktion nicht besonders wichtig (außer die kann noch mehr, was mir aktuell nicht bekannt ist)
Soll heißen, "nice to have" und werde ich erst mal nicht weiter verfolgen...

Ich habe nun einen Pull request gestellt. Im Kern ist folgendes geändert:
libraries/HBWSwitch/HBWSwitch.cpp (https://github.com/ThorstenPferdekaemper/HBWired/compare/master...loetmeister:master#diff-c3decd83a85f5d65f1781e8f756c0157)
libraries/HBWSwitchAdvanced/HBWSwitchAdvanced.cpp

libraries/HBWired/HBWired.cpp (https://github.com/ThorstenPferdekaemper/HBWired/compare/master...loetmeister:master#diff-804b89404ca1977353cbc9be6b56c357)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 02 Juni 2018, 16:36:12
Zitat von: loetmeister am 31 Mai 2018, 00:24:21
beim testen des "Discovery" ist mir aufgefallen das es nicht richtig funktioniert (mag an meinem USB - RS485 Adapter liegen, o.a.) und FHEM alle gescannten Geräte "gefunden" hat.
Also bei mir (mit dem einfachen Digitus USB-Adapter) hat das Discovery bisher bestens funktioniert, zumindest mit den Original-eq3-Geräten.
Was meinst Du damit eigentlich, dann es nicht funktioniert, da es alle Geräte gefunden hat. Das ist doch genau, was man vom Discovery erwartet.

ZitatAuch ist mit "auto create", die Discovery Funktion nicht besonders wichtig
Hä? Ohne Autocreate ist Discovery nicht so besonders interessant. Erst durch das Autocreate werden die gefundenen Geräte auch tatsächlich in FHEM angelegt (soweit ich mich erinnere).
ZitatIch habe nun einen Pull request gestellt.
Ist ge-merge-t. (Oder wie man das auch immer auf Denglisch schreibt.)
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 02 Juni 2018, 22:03:31
Zitat von: Thorsten Pferdekaemper am 02 Juni 2018, 16:36:12
Also bei mir (mit dem einfachen Digitus USB-Adapter) hat das Discovery bisher bestens funktioniert, zumindest mit den Original-eq3-Geräten.
Was meinst Du damit eigentlich, dann es nicht funktioniert, da es alle Geräte gefunden hat. Das ist doch genau, was man vom Discovery erwartet.
Sorry, mein Fehler...  :-[ scheint zu funktionieren. Ich hatte aber beim testen mit meinem "homebrew"-Discovery Device alle Discovery Nachrichten positiv beantwortet. Also war für jede angefragte Adresse fälschlicherweise ein Gerät vorhanden.

War mich dabei aber wundert, es wurden alle Adressen von 00 bis FF angefragt. Würde der Discovery mode keine Geräte mit Adresse größer FF finden? Ich konnte in der "commandref" keine Option finden den Adressbereich festzulegen der gescannt werden soll...

Zitat
Ohne Autocreate ist Discovery nicht so besonders interessant. Erst durch das Autocreate werden die gefundenen Geräte auch tatsächlich in FHEM angelegt (soweit ich mich erinnere).
Ja, das war etwas unglücklich ausgedrückt. Ich meinte das für eine automatische Anlage des Gerät in FHEM eine Broadcast "Announce" Nachricht reicht und man dafür keine Discovery Funktion braucht...


PS: Danke für den "Merge"  8)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 03 Juni 2018, 08:39:24
Zitat von: loetmeister am 02 Juni 2018, 22:03:31Ich hatte aber beim testen mit meinem "homebrew"-Discovery Device alle Discovery Nachrichten positiv beantwortet. Also war für jede angefragte Adresse fälschlicherweise ein Gerät vorhanden.
War mich dabei aber wundert, es wurden alle Adressen von 00 bis FF angefragt. Würde der Discovery mode keine Geräte mit Adresse größer FF finden?
Discovery findet alle Adressen. Es gibt keine Möglichkeit, das irgendwie einzuschränken. Allerdings gibt es ein Limit der Anzahl der Geräte auf dem Bus, weswegen Discovery nach (etwa?) 255 gefundenen Geräten zu suchen aufhört.
Hätten Deine Devices nur auf passende Nachrichten geantwortet, dann hätte Discovery auch weitergesucht.
Discovery scannt übrigens nicht einfach die Adressen durch, sondern sucht etwas intelligenter. Die Implementierung ist also ein klein wenig komplexer als einfach die Adresse zu vergleichen. Eine genauere Beschreibung findest Du hier:
http://forum.fhem.de/index.php?action=dlattach;topic=10027.0;attach=2441
oder als Perl Coding in /opt/fhem/FHEM/lib/HM485/HM485d/HM485_Protocol.pm in den Routinen, die mit "discovery" anfangen.
Gruß,
   Thorsten

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 24 Juli 2018, 21:11:07
Zitat von: hresalg am 05 Mai 2018, 01:18:07
Hallo Thomas tut mir leid, ich hab den HBW-CC-Vd2-T gelöscht, weil ich das Modul komplett umgeschrieben habe und jetzt nicht mehr auf Arduino Basis ist, sondern nur mehr normales gcc-avr. Auch einen Bootloader habe ich bereits. nur ist er noch immer ziemlich groß. (~2400 byte). Ich stelle es wieder online wenn ich fertig bin. also bitte nicht aus dem wiki löschen.

Hallo Harald,

gibt es was neues zum Bootloader? Passt er in einen Mega328P mit 1024 Word Bootsize? (BOOTSZ=01)  ::)
https://github.com/hresalg/HBW-BootLoader sieht ja schon gut aus.  ;)



PS: Ich bastel derweil ein wenig an der 0-10V Schnittstelle.... https://forum.fhem.de/index.php/topic,22952.msg799706.html#msg799706

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 08 August 2018, 22:29:59
Hallo,

es gibt eine Kleine Ergänzung zu HBW-LC-BL-4 und HBW-LC-BL-8 (die Rollo Aktoren). Dort kann man im Peering nun wahlweise einen Bestimmten Wert zwischen 0 und 100% setzen (Auswahl, open: 100%, close: 0%, toggle/stop, set level 0...100%).
https://github.com/loetmeister/HBWired/tree/master/HBW-LC-BL-4

@Thorsten, Ich habe einen Pull request gestellt, mit der beschriebenen Änderung - damit es nicht so viele Änderungen auf einen Schlag sind, wenn ich das neue Dimmer Modul in GitHub lade :)


Zu dem Dimmer mit 0-10V Schnittstelle... so wie ich bisher das Modul aufbaue, soll es folgenden Möglichkeiten geben:

Für Punkt 5. bin ich mir noch nicht sicher wie ich die 10 IOs nutzen soll... - Was braucht man so? :)
Bisher habe ich 10 Eingänge, per Optokoppler getrennt (4-24V) eingeplant. z.B. für Fensterkontake.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 30 August 2018, 23:59:21
Hallo,

habe mal die erste Version des Dimmer & IO Moduls in GitHub eingestellt.  :D
https://github.com/loetmeister/HBWired/tree/master/HBW-IO-10-Dim-6

6 analoge/PWM Ausgangskanäle
Geplant: 10 Eingänge

Das ganze ist noch nicht Fertig, es funktioniert aber schon soweit:
Peering mit TOGGLE_TO_COUNTER, TOGGLE_INVERSE_TO_COUNTER, UPDIM, DOWNDIM, TOGGLEDIM, TOGGLEDIM_TO_COUNTER, TOGGLEDIM_INVERSE_TO_COUNTER, onTime, offTime (Ein-/Ausschaltdauer), onDelayTime, offDelayTime (Ein-/Ausschaltverzögerung), RampOn, RampOff.

Dimmer Kanal Konfig:
"0-10V" oder "1-10V" (OUTPUT_VOLTAGE)
Maximalwert von 40-100% (PWM_RANGE)


Die Hardware existiert bisher nur auf dem Steckbrett... da ist auch noch was zu tun.  ;)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 31 August 2018, 14:57:23
Hi,
sorry, dass es so lange gedauert hat. HMW ist momentan nicht meine oberste Priorität.
Zitat von: loetmeister am 08 August 2018, 22:29:59
@Thorsten, Ich habe einen Pull request gestellt, mit der beschriebenen Änderung - damit es nicht so viele Änderungen auf einen Schlag sind, wenn ich das neue Dimmer Modul in GitHub lade :)
Ich habe inzwischen Deinen Pull-Request akzeptiert.

ZitatFür Punkt 5. bin ich mir noch nicht sicher wie ich die 10 IOs nutzen soll... - Was braucht man so? :)
Bisher habe ich 10 Eingänge, per Optokoppler getrennt (4-24V) eingeplant. z.B. für Fensterkontake.
Ich habe bisher nur Taster-Eingänge gebraucht. Zustands-Sensoren (wie etwa Fensterkontakte) wären aber bestimmt auch ganz nett.

Zitat von: loetmeister am 30 August 2018, 23:59:21
habe mal die erste Version des Dimmer & IO Moduls in GitHub eingestellt.  :D
https://github.com/loetmeister/HBWired/tree/master/HBW-IO-10-Dim-6
Könntest Du die Liste im Wiki entsprechend erweitern?
...oder mir die Daten geben, dann mach ich das.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 01 September 2018, 18:06:19
Hallo zusammen,

Ich habe mir mein erstes Homebrew Device zusammengebaut. Hat auch erstaunlich gut funktioniert!

Eine Frage habe ich zur Stromversorgung. Idealerweise würde ich das Devise an die gleiche Stromversorgung anschließen. Wie habt ihr das gelöst? Habt ihr einen Stromwandler von 24V auf 5V im Einsatz? Könnt ihr mir da was kleines zum verbauen empfehlen mit dem ihr schon Erfahrung habt?

Danke euch!
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 01 September 2018, 21:18:00
Hi,

Ich denke du kannst da jeden step-down Wandler nehmen, der die gewünschten Spannungen liefert... Ich hab einen MC34063A verbaut.
Bei fertigen Modulen würde ich keinen übertrieben großen Ausgangstrom wählen, da meist bei weniger last der Wirkungsgrad sinkt.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 01 September 2018, 22:17:58
Hi,
ich hab da einfach ein kleines 5V-Netzteil mit in den Schrank gehängt. Irgendwann hatt ich keine Lust mehr zu basteln...
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 02 September 2018, 17:20:58
Danke für euer Feedback!

Kann leider nicht alle Aktoren an einer zentralen Stelle verbauen. :(

Habe jetzt mal geschaut was es an fertigen Modulen gibt und habe folgendes gefunden, was mir zusagen würde:

https://www.amazon.de/dp/B07DP2MDJQ/ref=sspa_dk_detail_0?psc=1&pd_rd_i=B07DP2MDJQ&pf_rd_m=A3JWKAKR8XB7XF&pf_rd_p=5d9f1d21-75bb-4018-838c-214f697868c6&pf_rd_r=5R7J4GM1VCRV3H51FTE3&pd_rd_wg=OnMcS&pf_rd_s=desktop-dp-sims&pf_rd_t=40701&pd_rd_w=TQwlf&pf_rd_i=desktop-dp-sims&pd_rd_r=44476c82-aec2-11e8-9d19-530a15f05916 (https://www.amazon.de/dp/B07DP2MDJQ/ref=sspa_dk_detail_0?psc=1&pd_rd_i=B07DP2MDJQ&pf_rd_m=A3JWKAKR8XB7XF&pf_rd_p=5d9f1d21-75bb-4018-838c-214f697868c6&pf_rd_r=5R7J4GM1VCRV3H51FTE3&pd_rd_wg=OnMcS&pf_rd_s=desktop-dp-sims&pf_rd_t=40701&pd_rd_w=TQwlf&pf_rd_i=desktop-dp-sims&pd_rd_r=44476c82-aec2-11e8-9d19-530a15f05916)

oder

https://www.amazon.de/dp/B01MQGMOKI/ref=sspa_dk_detail_2?psc=1&pd_rd_i=B01MQGMOKI&pf_rd_m=A3JWKAKR8XB7XF&pf_rd_p=5d9f1d21-75bb-4018-838c-214f697868c6&pf_rd_r=M2QMA7K22WEX801YVVKQ&pd_rd_wg=8Yqig&pf_rd_s=desktop-dp-sims&pf_rd_t=40701&pd_rd_w=PIg6M&pf_rd_i=desktop-dp-sims&pd_rd_r=3e0da4a2-aec2-11e8-a1f4-150dcd1d19a7 (https://www.amazon.de/dp/B01MQGMOKI/ref=sspa_dk_detail_2?psc=1&pd_rd_i=B01MQGMOKI&pf_rd_m=A3JWKAKR8XB7XF&pf_rd_p=5d9f1d21-75bb-4018-838c-214f697868c6&pf_rd_r=M2QMA7K22WEX801YVVKQ&pd_rd_wg=8Yqig&pf_rd_s=desktop-dp-sims&pf_rd_t=40701&pd_rd_w=PIg6M&pf_rd_i=desktop-dp-sims&pd_rd_r=3e0da4a2-aec2-11e8-a1f4-150dcd1d19a7)

Von der Größe würde diese für mich noch im Rahmen liegen. Würde aus eurer Sicht technisch etwas dagegen sprechen? 
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 02 September 2018, 23:08:26
Zitat von: holzwurm83 am 02 September 2018, 17:20:58
Habe jetzt mal geschaut was es an fertigen Modulen gibt und habe folgendes gefunden, was mir zusagen würde:
[...]
Von der Größe würde diese für mich noch im Rahmen liegen. Würde aus eurer Sicht technisch etwas dagegen sprechen?

Bei beiden Typen wird erwähnt, eine Last von 10% nicht zu unterschreiten. Das wäre 300mA oder 100mA für das zweite Modul. Ich weiß nicht was du alles anschließen willst... :)  ::)
Mein Basismodul, mit Prozessor, Busankoppler, und ein paar Schieberegistern braucht knapp 40mA bei 5V. Da wären die vorgeschlagenen Step-Down Wandler wohl nicht geeignet....

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 09 September 2018, 15:47:17
Hallo,

habe mal ein wenig weiter am Dimmer/IO Modul gebaut. (https://github.com/loetmeister/HBWired/tree/master/HBW-IO-10-Dim-6)
Hinzugefügt OFFDELAY_BLINK, OFFDELAY_STEP peering settings. Was noch fehlt, ist "on_level_prio" und "ramp_start_step" - für letzteres ist mir die Verwendung nicht klar. Ich meine man könnte mit on_min_level und offdelay_step das selbe Ergebnis erzielen...  ???

Key & Sensor Kanäle habe ich auch hinzugefügt, aber LinkKey will nicht so recht. (Problem s.u.)
Die 10 Eingänge können als Key (Taster/Schalter/etc. - input_type s.u.) benutzt werden. Direkte Peerings sollen noch dazukommen...
Parallel stehen die 10 Eingänge auch als SENSOR zur Verfügung. Die Sensor Kanäle müssen abgefragt werden, und liefern dann sensor_open oder sensor_closed zurück. (Möglichkeit der Invertierung über Kanalkonfiguration)


Bzgl. dem Problem...
Wenn ich mit getConfig das neue Dimmer Modul Abfrage, scheint es Abzustürzen/Neustarts des Arduino zu kommen und sich sonderbar zu verhalten. Währen das EEPROM von FHEM gelesen wird, hat es sogar (mehrfach) die Adresse gewechselt!  :o
Wie kann ich durch lesen des EEPROM so ein Chaos erzeugen? :)

fhem-...log
3: hm485: Initialisierung von Modul 42000015
3: hm485: HM485_QueueStepFailed Call step
3: HBW_IO_10_Dim_6_HBW7296277: RESPONSE TIMEOUT for 42000015
2: autocreate: define HBW_IO_10_Dim_6_HBW4073471 HM485 42FFFFFF hm485
2: hm485: Assigned 42FFFFFF as HBW_IO_10_Dim_6_HBW4073471


oder auch andere Adressen:
(42000015 ist die "richtige", von mir gesetzte)
3: hm485: Initialisierung von Modul 42000015
3: hm485: Initialisierung von Modul 05F605FF
3: hm485: Initialisierung von Modul 9205DB05
3: hm485: Initialisierung von Modul 039205DB
3: hm485: Initialisierung von Modul 05FFFFFF


Das ganze passiert aber nur wenn ich HBWLinkKey mit im Device habe.  >:( Wenn ich das rausnehme ist es ok. Dabei bleibt die XML (address_start, address_step, etc. Definitionen) aber unverändert...  :o

-------
-> Ergänzung:
Selbst ohne HBWLinkKey kann ich Abstürze produzieren, wenn ich ein anderes Modul am Bus mit getConfig Abfrage.
Im log unten wurde das Modul 42000017 angefragt, aber meins mit einer anderen Adresse schmiert ab... :o

Arduino Log:
> "B: 2A" Ausgabe nach dem starten, dann init Ausgabe (cfg...)
R: FD:42:00:00:17:1C:00:00:00:01:03:68:51:6A
R: FD:00:00:00:01:58:42:00:00:17:04:93:01:9B:44
R: FD:42:00:B: 2A 706 szChan:52
cfg SCPin:4
cfg SCPin:7
cfg SCPin:19
cfg SCPin:12

R: FD:42:00:00:17:18:00:00:00:01:03:68:19:90
R: FD:00:00:00:01:18:42:00:00:17:04:B: 2A 706 szChan:52
cfg SCPin:4
cfg SCPin:7
cfg SCPin:19
cfg SCPin:12
cfg SCPin:14


...
R: FD:42:00:00:15:18:00:00:00:01:06:52:00:60:10:46:52
C: Read EEPROM
T: FD:00:00:00:01:18:42:00:00:15:12:55:11:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:F0:04
R: FD:42:00:00:15:19:00:00:00:01:02:E8:C6
R: ACK
R: FD:42:00:00:15:1A:00:00:00:01:06:52:00:70:10:0D:78
C: Read EEPROM
T: FD:00:00:00:01:38:42:00:00:15:12:FF:FF:?B: 2A 693
(reboot)


-------------------
Dabei habe ich auch HBWKey mal etwas erweitert... Hinzugefügt: locked, inverted und input_type(s):
IN_DOORSENSOR    // sends a short KeyEvent on HIGH and long KeyEvent on LOW input level changes
IN_MOTIONSENSOR  // sends a short KeyEvent for raising or falling edge - not both
IN_SWITCH        // sends a short KeyEvent, each time the input (e.g. wall switch) changes the polarity
IN_PUSHBUTTON    // (default) - sends a short KeyEvent on short press and (repeated) long KeyEvent on long press

https://github.com/loetmeister/HBWired/commit/93e0a2b19bbbbaee14c17ba85a7c81304386f625

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 09 September 2018, 20:19:19
Hi,

es scheint als war die neue Version der Ardunio IDE das Problem...  >:(
Man sollte nicht währen der Entwicklung die Umgebung ändern...  :-[

Nachdem der Empfang von anderen Paketen auf dem Bus zum Crash geführt hatte, habe ich wieder die alte Version genommen... damit gibt es keine Probleme!

Der selbe Code mit beiden Versionen der Ardunio IDE kompiliert:
Version 1.8.5
Der Sketch verwendet 18148 Bytes (59%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 562 Bytes (27%) des dynamischen Speichers, 1486 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.


Version 1.8.6
Der Sketch verwendet 17848 Bytes (58%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 562 Bytes (27%) des dynamischen Speichers, 1486 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.



Eventuell liegts an SoftSerial (die Lib hat sich in den beiden Versionen nicht geändert) oder was anderes in "void HBWDevice::receive(){" ??  ::)


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 11 September 2018, 14:51:24
Hi,
Zitat von: loetmeister am 09 September 2018, 20:19:19
Eventuell liegts an SoftSerial (die Lib hat sich in den beiden Versionen nicht geändert)
Eigentlich sollte HBW die originale SoftSerial gar nicht verwenden. Dafür wird ja die HBWSoftwareSerial mitgeliefert. Möglicherweise können die Probleme aber trotzdem da irgendwo liegen, da das Timing schon etwas "frickelig" ist.
Momentan habe ich dazu allerdings keine richtige Idee. Die zwei Änderungen zur normalen SoftwareSerial.cpp habe ich mit "PFE" markiert.
Möglicherweise kannst Du mal ein Gerät bauen, dass per Hardware-Serial kommuniziert. Dann könnte man schonmal das Problem eingrenzen.
Gruß,
  Thorsten


Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 11 September 2018, 15:27:17
Zitat von: holzwurm83 am 02 September 2018, 17:20:58
Kann leider nicht alle Aktoren an einer zentralen Stelle verbauen. :(
Du könntest ja auch 5V statt 24V auf das Buskabel legen. Das geht natürlich nur solange Du nicht auch noch Original-Geräte dranhängen hast. Bei langen Leitungen muss man ggf. auch ein bisschen aufpassen von wegen Spannungsabfall.
Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 11 September 2018, 22:31:05
Zitat von: Thorsten Pferdekaemper am 11 September 2018, 14:51:24
Hi,Eigentlich sollte HBW die originale SoftSerial gar nicht verwenden. Dafür wird ja die HBWSoftwareSerial mitgeliefert. Möglicherweise können die Probleme aber trotzdem da irgendwo liegen, da das Timing schon etwas "frickelig" ist.
Momentan habe ich dazu allerdings keine richtige Idee. Die zwei Änderungen zur normalen SoftwareSerial.cpp habe ich mit "PFE" markiert.
Möglicherweise kannst Du mal ein Gerät bauen, dass per Hardware-Serial kommuniziert. Dann könnte man schonmal das Problem eingrenzen.

Hi Thorsten,

stimmt SoftSerial war ja eine eigene... habe noch kein Testmodul für die Hardware Variante, aber schon im kompilieren zeigen sich auch dort Abweichungen.

HW Serial
1.8.5
Der Sketch verwendet 16308 Bytes (53%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 455 Bytes (22%) des dynamischen Speichers, 1593 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
1.8.6
Der Sketch verwendet 16368 Bytes (53%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 453 Bytes (22%) des dynamischen Speichers, 1595 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.

Differenz -60 Bytes

Soft Serial
1.8.5
er Sketch verwendet 18112 Bytes (58%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 562 Bytes (27%) des dynamischen Speichers, 1486 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
1.8.6
Der Sketch verwendet 17812 Bytes (57%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 562 Bytes (27%) des dynamischen Speichers, 1486 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.

Differenz -300 Bytes

Hab dann mal die Kompilierte *.elf Dateien von 1.8.5 und 1.8.6 in Assembler übersetzt und geschaut ob sich da offensichtliche Unterschiede zeigen... war aber nix was mir in Auge gesprungen ist (bin aber auch kein Assembler Spezi ::) ) Ein Teil des Codes habe ich 1:1 in beiden Versionen gefunden, andere Teile waren aber komplett anders aufgebaut (CALL statt JMP für eeprom_write_byte Aufruf) verteilt. Oder z.b. 5 vs. 7 mal der Aufruf der Funktion <eeprom_read_byte> (call   0x..) in v1.8.6.
Export: ...\arduino\hardware\tools\avr\bin\avr-objdump.exe" -S ...Local\Temp\arduino_build_395116\HBW-IO-10-Dim-6.ino.elf

Hab die kleineren Hardware-Serial Assembler Versionen mal angehängt..  ;D

Ich bleibe jedenfalls erst mal auf der 1.8.5...


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 18 September 2018, 00:40:45
Zitat von: Thorsten Pferdekaemper am 31 August 2018, 14:57:23
Könntest Du die Liste im Wiki entsprechend erweitern?
...oder mir die Daten geben, dann mach ich das.

Hi Thorsten,

wäre schön wenn du das Device hinzufügen könntest.
HBW-IO-10-Dim-6
ID 0x96
6 analoge Ausgangskanäle (Dimmer)
10 Eingänge (20 Kanäle: 10 Taster, 10 Sensorkontakte/Schließerkontakt)



Etwas detaillierter:
Direktes Peering möglich (HBWLinkDimmerAdvanced & HBWLinkKey)

Die 6 analogen Ausgangskanäle geben eine Spannung von "0-10V" (alternativ "1-10V", pro Kanal) als Dimmer aus (0-100%). Das PWM Signal kann auch direkt ausgeben werden (12V Ausgangsspannung). Der PWM, bzw. Spannungsbereich kann auf ein Maximalwert von 40-100% pro Kanal konfiguriert werden.

Die 10 Eingänge stehen als Sensor oder Schalterkanal gleichzeitig zur Verfügung, d.h. pro Eingang sind Zwei Kanäle vorhanden.
Die Schalterkanäle können normal als Taster/Schalter inkl. Peering genutzt werden. Mögliche Typen: PUSHBUTTON, SWITCH, MOTIONSENSOR, DOORSENSOR)
Die Sensor Kanäle müssen abgefragt werden (kein Peering), und liefern dann "sensor_open" oder "sensor_closed" zurück. (Möglichkeit der Invertierung über Kanalkonfiguration)

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

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 19 September 2018, 00:19:35
Hi,

noch eine kleine Änderung für HBWired...
Bei Devices mit vielen Kanälen steigt meiner Ansicht nach die Gefahr die receive(); Funktion (Teil des main loops) nicht oft genug aufzurufen und eventuell Daten auf dem Bus zu verpassen.
Ich habe daher die "for" schleife gegen einen counter 'getauscht' (+10 byte Speicher, +1 byte RAM).
Teste aktuell mit dem 26 Kanal IO/Dimmer. Test mit long press "spam" alle 300ms auf dem Bus + Key events an einen anderen Aktor - Funktioniert...

@@ -834,8 +834,10 @@ void HBWDevice::loop()
   // send announce message, if not done yet
   handleBroadcastAnnounce();
// feedback from switches and handle keys
-   for(uint8_t i = 0; i < numChannels; i++)
-        channels[i]->loop(this,i);
+   static uint8_t loopCurrentChannel = 0;
+   channels[loopCurrentChannel]->loop(this,loopCurrentChannel);
+   loopCurrentChannel++;
+   if (loopCurrentChannel >= numChannels) loopCurrentChannel = 0;
// config Button
    handleConfigButton();
};


Erstelle noch einen Pull request....   ;)
https://github.com/ThorstenPferdekaemper/HBWired/compare/master...loetmeister:5e226dd4d8dccac9853ae7e6c7d10daa4bacec4e


Ich würde gerne den "libraries" Ordner etwas umbauen.. als Arduino lib wäre es einfacher wenn alle Dateien *.cpp und *.h in einem Ordern sind, z.B.:
HBWired\libraries
  library.properties
  keywords.txt
  src\
    *.h
    *.cpp

library.properties:
name=HBWired
version=1
author=Thorsten Pferdekaemper (thorsten@pferdekaemper.com)
maintainer=Thorsten Pferdekaemper (thorsten@pferdekaemper.com)
sentence=HBWired Homebrew
paragraph=Build your own Homematic Wired bus Devices.
category=Communication
url=https://github.com/ThorstenPferdekaemper/HBWired/tree/master/libraries
architectures=*



Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 25 September 2018, 15:48:45
Zitat von: loetmeister am 18 September 2018, 00:40:45
wäre schön wenn du das Device hinzufügen könntest.
Erledigt.

Zitat von: loetmeister am 19 September 2018, 00:19:35
noch eine kleine Änderung für HBWired...
Bei Devices mit vielen Kanälen steigt meiner Ansicht nach die Gefahr die receive(); Funktion (Teil des main loops) nicht oft genug aufzurufen und eventuell Daten auf dem Bus zu verpassen.
Ich habe daher die "for" schleife gegen einen counter 'getauscht' (+10 byte Speicher, +1 byte RAM).

Erstelle noch einen Pull request....   ;)
Sieht ok aus, aber einen Pull Request habe ich bisher keinen bekommen.

Zitat
Ich würde gerne den "libraries" Ordner etwas umbauen.. als Arduino lib wäre es einfacher wenn alle Dateien *.cpp und *.h in einem Ordern sind, z.B.:
Was würde das bringen? Eigentlich dachte ich, dass man so bessere Kontrolle darüber hat, was alles benutzt wird. Es soll ja nur das reingelinkt werden, was auch gebraucht wird. 
...oder verstehe ich da was falsch?

Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 26 September 2018, 19:13:23
Hi Thorsten,

danke fürs aktualisieren des Wikis.

Bzgl. dem "libraries" Ordner. Vermutlich reden wir aneinander Vorbei.  ??? Der Hintergrund ist folgender.
Aktuell kopiere ich immer die Dateien (*.cpp und *.h) aus dem GitHub Repository (bzw. dessen Ordnerstruktur) in ein "HBWired\src" Verzeichnis welcher in "Arduino\libraries\" liegt. Da es nun Teil der Standard Arduino Library ist, hatte ich mir eine Beschreibungs und "Syntax Coloring" (keywords.txt) Datei erstellt. Finde ich eigentlich ganz praktisch...  ;)
Wenn nun das GitHub Repository die selbe Ordnerstruktur wie die "Arduino\libraries\HBWired\..." hätte, kann man sich das hin- und herkopieren sparen, bzw. es ist etwas einfacher.
Ich meine der linker bindet auch ein was inkludiert wurde. So verstehe ich das, was ich im arduino_build cache sehe.

Hier mal der Inhalt der beiden Verzeichnisse:

Verzeichnis von C:\Users\user\Documents\Arduino\libraries\HBWired

[.]                  keywords.txt         [src]
[..]                 library.properties
               2 Datei(en),          1.729 Bytes

Verzeichnis von C:\Users\user\Documents\Arduino\libraries\HBWired\src

[.]                         HBWBlind.cpp                HBWLinkBlindSimple.h        HBWSoftwareSerial.cpp
[..]                        HBWBlind.h                  HBWLinkKey.cpp              HBWSoftwareSerial.h
ClickButton.cpp             HBWired.cpp                 HBWLinkKey.h                HBWSwitch.cpp
ClickButton.h               HBWired.h                   HBWLinkSwitchAdvanced.cpp   HBWSwitch.h
FreeRam.cpp                 HBWKey.cpp                  HBWLinkSwitchAdvanced.h     HBWSwitchAdvanced.cpp
FreeRam.h                   HBWKey.h                    HBWLinkSwitchSimple.cpp     HBWSwitchAdvanced.h
hardware.h                  HBWLinkBlindSimple.cpp      HBWLinkSwitchSimple.h
              25 Datei(en),        110.458 Bytes



Edit: Habe mal einen pull request erstellt. Dateien habe ich noch keine verschoben. Es sind erst mal alle bisherigen Änderungen.
HBWired: channels[loop... geändert
HBWKey.cpp - Erweitert
Der Rest für HBW-IO-10-Dim-6, bzw. "Kosmetik" für den Rest...
https://github.com/ThorstenPferdekaemper/HBWired/compare/master...loetmeister:020d764c12089e32dd1ba60c984d333710bdca34


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 06 Oktober 2018, 21:05:59
Hi,
sorry, hat ein bisschen gedauert, aber der Pull-Request ist jetzt drin.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Langerrenner am 28 November 2018, 14:59:14
Hallo Thorsten,
ich habe einige Module seid ca. 10 Monaten in einer Probe- Fhem Anlage am laufen.
HBW-LC-BL-4
HBW-LC-SW8
HBW-Sen-Key-12
HM Modul
HBW-1W-T10
Ziel soll es sein, meine 10 Jahre alte HM- Anlage komplett zu ersetzen, da es die Module mit RS485 in der Form wie ich sie brauche nicht mehr gibt.
Ich würde gerne die Module auf die neuste Software bringen.
Welchen Stand hat die Software erreicht. Ist ein finaler Zustand fast erreicht?
MfG. Willi Florin
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 28 November 2018, 15:04:49
Zitat von: Langerrenner am 28 November 2018, 14:59:14
Hallo Thorsten,
Hi,
ich habe an dem Kram schon ewig nichts mehr gemacht. Vielleicht mag Thomas (loetmeister) etwas dazu sagen.
...einen "finalen Stand" gibt es meiner Meinung nach bei Software nicht. Speziell bei Open Source musst Du für Dich selbst entscheiden, ob das alles für Dich funktioniert. Insbesondere wenn es das laut 10-monatigem Test tut, würde ich an Deiner Stelle kein Update machen.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Langerrenner am 28 November 2018, 16:07:45
Ja sorry Thomas,
loetmeister hat die letzten Erweiterungen eingestellt. Daher die Frage an Ihn.
Ich möchte schon gerne den letzten Stand verwenden, weil hier gerade die Erweiterungen drin sind, die ich auch gerne hätte.
Auch möchte ich einige Sonderfunktionen noch zusätzlich einbauen, dies wird aber erst nächstes Jahr was werden.
MfG. Willi Florin
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 28 November 2018, 20:20:15
Hi,

ein 10-monatiger Test ist ja schon mal ne Hausnummer  8)
Wenns aber nur eine Testanlage ist, dann spiele mal neue Software in ein Modul ein und schau ob alles weiterhin funktioniert :) Kann natürlich sein das die neuen Device XML Dateien nicht mit den alten Modulen funktionieren... mischen könnte da ein Problem sein.


Welcher Stand hat denn deine Firmware? (wann Kompiliert?)
Du kannst dir für die Module die Commits anschauen, z.B.
HBW-Sen-Key-12
--> https://github.com/ThorstenPferdekaemper/HBWired/commits/master/HBW-Sen-Key-12
Funktionen sind dort eigentlich nicht verändert worden, (fast) nur Anpassungen für Änderungen in den Libraries, und ein paar kosmetische Änderungen.

Bei HBW-LC-BL-4 oder HBW-LC-SW8 sind ein paar zusätzliche Funktionen hinzugekommen.
Größere Änderungen gibt es bei den neuen Modulen, oder auch z.B. HBW-LC-Sw-8_AdvancedPeering (Peering mit TOGGLE, TOGGLE_TO_COUNTER, TOGGLE_INVERSE_TO_COUNTER, onTime, offTime (Ein-/Ausschaltdauer), onDelayTime, offDelayTime (Ein-/Ausschaltverzögerung).

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Langerrenner am 29 November 2018, 09:12:57
Hallo Thomas,
danke für Deine Infos und für Deine umfangreiche Arbeit an diesen Modulen.
Ich werde meine Anlage mal komplett auf die neuste Software und XML Files setzen. Genau diese neuen Funktionen fehlten mir nämlich noch.
Dann wieder alle Verknüpfungen erzeugen und mein Tasten- Simulator wieder darauf ansetzten.
Die Module Temperatur- Module zeigten in der Eindraht- Kommunikation ab und zu mal Probleme.
Muss ich mal untersuchen. Nächstes Jahr werde ich wohl mehr Zeit haben, bin dann in Rente :) (Hoffe ich  ???, bei vier Enkelkindern?).
Gruß Willi
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 29 November 2018, 09:19:37
Zitat von: Langerrenner am 29 November 2018, 09:12:57Die Module Temperatur- Module zeigten in der Eindraht- Kommunikation ab und zu mal Probleme.
Dass es beim Temperatur-Teil Probleme gibt habe ich auch schon gehört. Ich glaube, das kommt vor, wenn man mehr als 5 (oder so) Sensoren dranhängen hat. Ein Arduino ist halt doch kein vollwertiger 1-Wire Busmaster. Allerdings weiß ich nicht, was man da viel besser machen könnte. Vielleicht einen richtigen Busmaster kaufen (?) und den dann wiederum per Arduino ansteuern. Vielleicht reicht aber auch ein bisschen Hühnerfutter an der richtigen Stelle.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Langerrenner am 29 November 2018, 10:42:44
Ja, mal sehen, vielleicht setze ich auch I2C Bausteine ein. Der BM280 von Bosch liefert direkt Luftdruck, Feuchte und Temperatur.
Gruß Willi
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 01 Dezember 2018, 13:11:42
Zitat von: Thorsten Pferdekaemper am 29 November 2018, 09:19:37
Dass es beim Temperatur-Teil Probleme gibt habe ich auch schon gehört. Ich glaube, das kommt vor, wenn man mehr als 5 (oder so) Sensoren dranhängen hat. Ein Arduino ist halt doch kein vollwertiger 1-Wire Busmaster. Allerdings weiß ich nicht, was man da viel besser machen könnte. Vielleicht einen richtigen Busmaster kaufen (?) und den dann wiederum per Arduino ansteuern. Vielleicht reicht aber auch ein bisschen Hühnerfutter an der richtigen Stelle.
Gruß,
   Thorsten

Das Problem ist das diese wohl in der Konstellation sehr Störanfällig sind. Ihr könnt hier mal schauen.
https://forum.fhem.de/index.php/topic,89519.0.html (https://forum.fhem.de/index.php/topic,89519.0.html)
Hat zwar gedauert aber mittlerweile laufen die problemlos.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Langerrenner am 03 Dezember 2018, 16:52:34
Danke holzwurm83 für die Infos. Sie sind mir bekannt, hab aber noch nicht alles eingebaut. Aber schon ein Kondensator über der Versorgungsspannung und ein kleiner über dem Bus waren schon sehr hilfreich.
Frage an Thomas, da ich einige Sonderwünsche bei mir einbauen möchte, muss ich natürlich erstmal in die Software einsteigen.
Gibt es hilfreiche Darstellungen, oder Infos über die Struktur und Ablauf? Das ein oder andere Bild könnte hilfreich sein.
Gruß Willi
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 03 Dezember 2018, 18:29:48
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 04 Dezember 2018, 16:22:19
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

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 04 Dezember 2018, 20:45:34
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 05 Dezember 2018, 23:24:32
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!

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 17 Dezember 2018, 13:32:09
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 17 Dezember 2018, 20:13:29
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 18 Dezember 2018, 00:34:50
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 18 Dezember 2018, 08:44:58
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 23 Dezember 2018, 23:31:12
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 08 Februar 2019, 22:13:25
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 10 Februar 2019, 21:57:42
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 12 Februar 2019, 22:59:24
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 13 Februar 2019, 15:13:10
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 25 März 2019, 23:07:04
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 23 April 2019, 23:39:09
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 24 April 2019, 15:03:58
...warum kommt eigentlich immer alles in denselben unübersichtlichen Thread? Na egal..

HMW hat halt bei den Peerings im Prinzip nur Tasten und Schalter. Vielleicht war bei eq3 mal mehr vorgesehen, aber das wissen wir halt nicht. Wenn  Du das jetzt erweitern willst, dann wäre es wohl am Besten, irgendwo in der Basisklasse ein receiveEvent zu haben (wofür steht das "IM"?). Davon abgeleitet könnte es dann etwas spezielleres für (z.B.) Keys geben.

Das Peering selbst wäre dann erstmal ein Problem im XML. Es gibt ja nicht so etwas wie "TemperatureSender" und "TemperaturReceiver". ...und wenn man es macht, dann müsste FHEM das auch erstmal noch kennenlernen. D.h. man könnte da höchstens was mit Key/Switch faken, was aber auch etwas hässlich wäre.
Ansonsten halt mit raw-Kommandos ins EEPROM schreiben.

Nachricht 0x41 ist die Announce-Message. Das passt irgendwie gar nicht. Da sollte man eher den 0x69 (das ist "Information") oder eben 0x4B (Key) nehmen und halt ein bisschen abwandeln. Schön ist das aber alles nicht.

Ich würde da ehrlich gesagt nicht so viel Aufwand reinstecken. Besser wäre meiner Meinung nach, einen Stellwert (Prozent Ventilöffnung, Puls/Pause-Verhältnis oder so) zu schicken und die ganze Regelung FHEM zu überlassen. Man könnte noch eine Notfall-Stellung vorgeben, wenn das Ding eine bestimmte Zeit keinen Befehl empfängt, aber das wär's dann meiner Meinung nach schon.

Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 24 April 2019, 20:39:14
Hi Thorsten,

Zitat
HMW hat halt bei den Peerings im Prinzip nur Tasten und Schalter. Vielleicht war bei eq3 mal mehr vorgesehen, aber das wissen wir halt nicht. Wenn  Du das jetzt erweitern willst, dann wäre es wohl am Besten, irgendwo in der Basisklasse ein receiveEvent zu haben (wofür steht das "IM"?). Davon abgeleitet könnte es dann etwas spezielleres für (z.B.) Keys geben.
"IM" steht für Info Message (0x69 bzw. 'i'). Diese Message hatte ich abgewandelt und HBWired eine Empfangsmöglichkeit hinzugefügt.
Ich versuche es mal aus einer Klasse abzuleiten...
receiveEvent
          -> receiveKeyEvent
          -> receiveIMEvent



Fände es halt schön eine Einzelraumsteuerung autonom zu haben, erst zum ändern der Zieltemperatur, Visualisierung, etc. käme FHEM ins Spiel.


Zitat
...warum kommt eigentlich immer alles in denselben unübersichtlichen Thread? Na egal..
... dachte den haben einige in den Lesezeichen ::)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 25 April 2019, 17:10:24
Zitat von: loetmeister am 24 April 2019, 20:39:14
"IM" steht für Info Message (0x69 bzw. 'i'). Diese Message hatte ich abgewandelt und HBWired eine Empfangsmöglichkeit hinzugefügt.
Ach so, Du verwendest gar nicht 0x41. Dann ist ja ok.

Zitat
Ich versuche es mal aus einer Klasse abzuleiten...
receiveEvent
          -> receiveKeyEvent
          -> receiveIMEvent

So unbedingt notwendig wäre das ja nicht. Ich dachte nur, da das receiveIMEvent schon sehr allgemein aussieht...

Zitat
Fände es halt schön eine Einzelraumsteuerung autonom zu haben, erst zum ändern der Zieltemperatur, Visualisierung, etc. käme FHEM ins Spiel.
Klar, schön ist das schon. Der Aufwand ist halt nur ziemlich groß. Außerdem ist es recht schwierig, das zu konfigurieren. Ich fände es z.B. gut, wenn man nicht auf eine Regelung festgelegt ist, die nur (eine) Ist- und Solltemperatur kennt. Z.B. würde bei mir noch ggf. Vorlauftemperatur und (möglicherweise vorhergesagte) Außentemperatur mit einfließen. Das sind aber nur Ideen. Ob ich das jemals so mache steht in den Sternen...

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 28 April 2019, 19:06:33
Hi Thorsten,

ich wollte mich erst mal auf die Einzelraumsteuerung beschränken, die Heizungssteuerung kümmert sich um Vorlauftemperatur und Außentemperatur.
Wie du angemerkt hast, wäre es sicher einfacher nur ein Aktor als Ventilsteller zu nehmen und FHEM den Rest zu überlassen...

Habs aber dennoch mal in HBW-CC-VD-2 eingebaut.  :D
Der PID Regler lässt sich intern (extern hab ich noch nicht getestet) mit dem 1-Wire Temperatur Sensor peeren. Der (fest verküpfte) Valve Kanal setzt dann den Wert an einem Ausgangspin um.
https://github.com/loetmeister/HBWired/tree/master/HBW-CC-VD-8

Leider ist bei zwei Sachen noch der Wurm drin.  :-\

1. In FHEM bekomme ich nicht die Option angezeigt im PID Kanal die "DESIRED_TEMP" zu setzen, obwohl set request="TEMP_SET" frame und operations write gesetzt sind. Nur "config", "inhibit" und "peer"...  ???
TEMP_GET und INFO_TEMP funktionieren im Temperatur Kanal...
<paramset type="VALUES" id="hmw_pid_ch_values">
<parameter id="DESIRED_TEMP" operations="read,write,event" control="TEMP.LEVEL">
<logical type="float" default="0.0" min="0.0" max="30.0" unit="℃"/>
<physical type="integer" interface="command" value_id="TEMP">
<set request="TEMP_SET"/>
<get request="TEMP_GET" response="INFO_TEMP"/>
<event frame="INFO_TEMP"/>
</physical>
<conversion type="float_integer_scale" factor="100"/>
</parameter>
<parameter id="INHIBIT" operations="read,write,event" control="NONE" loopback="true">
<logical type="boolean" default="false"/>
<physical type="integer" interface="command" value_id="INHIBIT">
<set request="SET_LOCK"/>
</physical>
</parameter>
</paramset>




Das zweite, noch seltsamere Problem betrifft den Arduino....
Ohne HBWLinkSender / HBWLinkReceiver im Device (also beides 'NULL') funktioniert alles soweit. Valve- und Temperaturkanäle senden ihren Status, etc. Ausgabe im Seriellen Monitor ist ok.
Wenn ich aber meine HBWLinkSender / HBWLinkReceiver dazu nehme (ohne ein peering gesetzt zu haben) startet der Arduino nach einiger zeit neu.
Bevor das passiert gab es sonderbare Effekte das im Seriellen Monitor Zeichen der debug Ausgabe verändert haben ('!' statt '%' oder nicht druckbare Zeichen) - was eigentlich statischer Text ist. Klingt als gäbe es Pointer die an die falsche Speicheradresse zeigen oder verändert werden... was ich mir aber nicht erklären kann..  :o
z.B.
T: FD:00:00:00:01:98:42:00:00:30:06:69:02:C8:70:89:46
R: FD:42:00:00:30:19:00:00:00:01:02:77:50
R: ACK
Valve ch: 2 snd: 100%

Der Fette Text sollte "send" sein... Schnöde hbwdebug Ausgabe...
hbwdebug("Valve ch: "); hbwdebug(channel); hbwdebug(" send: "); hbwdebug(level/2); hbwdebug("%\n");
... davor ein device->sendInfoMessage(channel, 2, &level);

Um den Link Kram anzuschalten wenn man ihn wirklich braucht, habe ich erst mal #define Support_HBWLink_InfoMessage in HBWired.h gesetzt. Schöner wäre es, dies über den Sketch zu steuern, was meines Wissens aber nicht geht.

Hab mal statt "IMEvent" "InfoEvent" genommen. Ist etwas weniger Generisch/Kryptisch...
HBWLinkInfoMessageActuator: receiveInfoEvent
HBWLinkInfoMessageSensor: sendInfoEvent

https://github.com/ThorstenPferdekaemper/HBWired/compare/master...loetmeister:master#diff-340d6f8cfa01a00fa61bea3db56dfddf

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 28 April 2019, 20:26:36
Zitat von: loetmeister am 28 April 2019, 19:06:33
ich wollte mich erst mal auf die Einzelraumsteuerung beschränken, die Heizungssteuerung kümmert sich um Vorlauftemperatur und Außentemperatur.
Ich meinte ja auch gar nicht, die Vorlauftemperatur zu steuern. Ich meinte, die Vorlauftemperatur ebenfalls als Messwert für den Regler zu haben. Ich habe beispielsweise bei mir manchmal das Problem, dass die Vorlauftemperatur so zweimal am Tag sehr hoch ist, weil die Heizung heißes Wasser produziert. Währenddessen bekommen die Heizkörper kein neues warmes Wasser und machen die Ventile auf. Wenn jetzt das heiße Wasser fertig ist, dann schaltet das System um und der "heiße" Vorlauf donnert in die Heizkörper. Je nach Raum wird es dann zu warm. Das könnte man durch eine intelligentere Regelung bei den Heizkörpern vermeiden. (Natürlich könnte man das auch mit einem Mischer hinbekommen...).
Aber wie schon gesagt: Du solltest nicht auf die Idee kommen, meine "Anforderungen" umzusetzen, da ich das wahrscheinlich in absehbarer Zeit sowieso nicht umsetze.

Zitat
1. In FHEM bekomme ich nicht die Option angezeigt im PID Kanal die "DESIRED_TEMP" zu setzen, obwohl set request="TEMP_SET" frame und operations write gesetzt sind. Nur "config", "inhibit" und "peer"...  ???
Lass mal das "control"-Attribut weg.

Zitat
Das zweite, noch seltsamere Problem betrifft den Arduino....
Das klingt mir irgendwie nach Speicherüberlauf. Kann es sein, dass Du den kleinen etwas überforderst?

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 29 April 2019, 00:34:10
ZitatLass mal das "control"-Attribut weg.
Ok, das bringt mich einen Schritt weiter, danke. Jetzt kommt die Auswahl, inkl. Eingabefeld (zeigt das aktuelle Reading). Leider kommt die folgende Meldung wenn ich den Wert setzen will:
Unknown argument desired_temp, choose one of  config desired_temp inhibit:on,off peer:HBW_CC_VD2_...


Um das Problem zu finden hatte ich DESIRED_TEMP mit dem "VALVE" Kanal verglichen... der Funktioniert, nutzt aber andere Frames.

<paramset type="VALUES" id="hmw_input_ch_values">
        <parameter id="VALVE" operations="read,write,event" control="VALVE.LEVEL">
<logical type="float" default="0.0" min="0.0" max="1.0" unit="100%"/>
<physical type="integer" interface="command" value_id="STATE">
<set request="LEVEL_SET"/>
<get request="LEVEL_GET" response="INFO_LEVEL"/>
<event frame="INFO_LEVEL"/>
</physical>
<conversion type="float_integer_scale" factor="200"/>
        </parameter>



Zitat
Das klingt mir irgendwie nach Speicherüberlauf. Kann es sein, dass Du den kleinen etwas überforderst?

Der Fehler hing wohl damit zusammen in der virtual void HBWPidsValve::set() einen Aufruf zu einer nicht vituellen Funktion setPidsValve() zu haben, bzw. darin einen Pointer weiter zu reichen... nachdem sie "virtual" ist, läuft es. Mit dem code für  meine HBWLinkSender / HBWLinkReceiver hatte es nichts zu tun.

virtual uint8_t getPidsValve(uint8_t* data);  // <--- war nicht "virtual"
...

void HBWPidsValve::set(HBWDevice* device, uint8_t length, uint8_t const * const data)
{
  pid->setPidsValve(data);
}

void HBWPids::setPidsValve(uint8_t const * const data)
{
  if (*(data) == 0) {...

 

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 29 April 2019, 12:53:29
Zitat von: loetmeister am 29 April 2019, 00:34:10
Ok, das bringt mich einen Schritt weiter, danke. Jetzt kommt die Auswahl, inkl. Eingabefeld (zeigt das aktuelle Reading). Leider kommt die folgende Meldung wenn ich den Wert setzen will:
Unknown argument desired_temp, choose one of  config desired_temp inhibit:on,off peer:HBW_CC_VD2_...
Ich bin mir nicht ganz sicher, aber versuch' mal folgendes: In Datei 10_HM485.pm, Zeile 582, steht das hier:

if($isChannel && defined($sets{$cmd})) {

Ändere mal das "defined" in "exists". Dann FHEM neu starten (ein "reload 10_HM485" könnte auch reichen) und probier's nochmal.

Zitat
Um das Problem zu finden hatte ich DESIRED_TEMP mit dem "VALVE" Kanal verglichen... der Funktioniert, nutzt aber andere Frames.
HM485 in FHEM "kennt" VALVE.LEVEL. Ich weiß nicht (mehr) warum das drin ist, da es ja nirgends in den Original-XMLs vorkommt. Jedenfalls ist es fest verdrahtet und reagiert genause wie DIMMER.LEVEL.

Zitat
Der Fehler hing wohl damit zusammen in der virtual void HBWPidsValve::set() einen Aufruf zu einer nicht vituellen Funktion setPidsValve() zu haben, bzw. darin einen Pointer weiter zu reichen... nachdem sie "virtual" ist, läuft es.
Das finde ich zwar etwas seltsam, aber wenn es jetzt geht, dann ist ja gut.

Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 29 April 2019, 15:54:08
Zitat

if($isChannel && defined($sets{$cmd})) {

Ändere mal das "defined" in "exists". Dann FHEM neu starten (ein "reload 10_HM485" könnte auch reichen) und probier's nochmal.
Das hat geklappt. Danke. Jetzt kann ich die "desired_temp" setzten.
Was müsste ich denn an meiner XML ändern, damit es ohne der Modifikation an 10_HM485.pm läuft? Ich kann nicht erkennen wie ich den set Befehel (TEMP_SET) anders definieren müsste...  :-[ Wenn HM485::Device::getAllowedSets() die erlaubten "set" Befehle aus der XML liest und Validiert... ist das etwas zu Kryptisch für mich...  ???


Ok, gut zu wissen das es die gibt :)
                'blind.level'   => "slider,0,1,100 on:noArg off:noArg up:noArg down:noArg",
                'blind.stop'    => "noArg",
                'dimmer.level'  => "slider,0,1,100 on:noArg off:noArg",
                'valve.level'   => "slider,0,1,100 on:noArg off:noArg",
                'button.long'   => "noArg",
                'button.short'  => "noArg",
                'digital_analog_output.frequency' => "slider,0,1,50000",



EDIT:
Hab mal https://github.com/loetmeister/HBWired/tree/master/HBW-CC-VD-8 aktualisiert. In dem PID Regler waren noch ein paar größere Schnitzer.  ::)
Läuft nun aber auch mit Cycle Zeiten größer 65 Sekunden....
Auf 8 Kanäle änder ich es, wenn ich das externe peering mit den Temperatursensoren getestet habe.


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 01 Mai 2019, 15:21:50
Zitat von: loetmeister am 29 April 2019, 15:54:08
Was müsste ich denn an meiner XML ändern, damit es ohne der Modifikation an 10_HM485.pm läuft?
Da hast Du wahrscheinlich keine Chance. Das ist halt ein Bug im FHEM-Modul. Ich kann das mal fixen, aber momentan habe ich kein HM485-Testaufbau. Vielleicht finden wir dafür ja einen Freiwilligen... (Hallo Freiwillige!)
Könntest Du dazu mal einen Issue hier erfassen:
https://github.com/kc-GitHub/FHEM-HM485/issues
...am besten mit allen (beiden?) Änderungen, die Du jetzt gemacht hast. Nur damit das nicht in Vergessenheit gerät.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 02 Mai 2019, 20:52:38
Hi Thorsten,

ok... danke. Habe, wie vorgeschlagen, ein "issue" festgehalten:
https://github.com/kc-GitHub/FHEM-HM485/issues/63

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 02 Mai 2019, 23:46:54
Hallo,

hab noch ein Device in die aktuelle Lib übernommen: HBW-Sen-EP
Das Modul HBW-Sen-EP liest bis zu 8 angeschlossene S0-Signale ein und sendet die aktuellen Zählerstände an die Zentrale.
Über das S0-Interface können bspw. Stromzähler, Gaszähler, Wärmemengenzähler, Wasserzähler, etc. eingelesen werden.

Code ist ist von Thorsten + meine Änderungen/Ergänzungen. Bei jfische hatte ich auch mal geschaut, die Änderungen dort waren mir aber zu "speziell" für seinen Anwendungsfall ;)
Einstellungen pro Kanal:
# Deaktivierung
# Invertierung

# Minimum-Sendeintervall
# Maximum-Sendeintervall
# Abtastung (10...150ms in 10 ms Schritten)
# Zählerdifferenz

https://github.com/loetmeister/HBWired/tree/master/HBW-Sen-EP


HBW-CC-VD-8 drehe ich nochmal etwas auf Links... Ziel ist es unabhängige 'valve' Kanäle zu haben, die entweder intern über den PID oder extern von FHEM gesteuert werden können. Aus der  'valve' Kanalklasse müsste man dann auch einfach ein eigenständiges Device erstellen können.


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 05 Mai 2019, 22:58:04
Hi,

habe grade noch eine kleine Änderung für HBW-Sen-EP hochgeladen.
https://github.com/loetmeister/HBWired/tree/master/HBW-Sen-EP

Mir ist reproduzierbar der Controller abgeschmiert, wenn ich den Pointer (uint8_t level) für get(&level) nicht als "static" deklariere...
Ich habe das bisher in keinem Device gemacht... meist war die Rückgabe vom get() nur 1 byte (falls das einen Unterschied macht?), aber bei HBW-1W-T10 ist sie auch 2 byte, und dort hatte ich nicht diesen Effekt. Hab ich da Glück gehabt? ::)

uint8_t HBWSenEP::get(uint8_t* data) {
  *data++ = (currentCount >> 8);
  *data = currentCount & 0xFF;
  return 2;
};

loop()
[...]
    // send
    uint8_t level;   // <--- Fehler
    //static uint8_t level;   // <--- OK!
    get(&level);

[...]
    hbwdebug(F("Ch: ")); hbwdebug(channel); hbwdebug(F(" send: ")); hbwdebug(lastSentCount); hbwdebug(F("\n"));


    
Im Serial Monitor kommt noch ein Teil der hbwdebug Ausgabe, dann die neue hbwdebug Ausgabe nach dem Neustart. Welche mit "B: 2A " beginnen sollte...
22:17:43.808 -> Ch?? 2A 1198


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 08 Mai 2019, 21:32:02
Hi,
naja, uint8_t ist halt mal nur ein Byte, wenn Du dann sowas machst wie *data++ = ..., dann überschreibst Du irgendwas, was zufällig danach kommt. Wenn Du das ganze mit static deklarierst, dann steht es halt in einem anderen Speicherbereich, bei dem es zufällig nicht ganz so weh tut (oder eben erst später). Ungefähr so wäre es vermutlich richtig:

uint8_t HBWSenEP::get(uint8_t* data) {
  *data++ = (currentCount >> 8);
  *data = currentCount & 0xFF;
  return 2;
};

loop()
[...]
    // send
    uint16_t level;   
    get((uint8_t*)(&level));


Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 08 Mai 2019, 21:42:27
Hallo,

habe HBW-CC-VD-8 "etwas" verändert. Der PID ist von seiner Funktion so geblieben, dafür gibt es neue Ventilregler (HBWValve) bei denen die Stellzeiten und Verhalten separat Konfiguriert werden kann.

HBWValve setzt im Kern auf den code von hglaser. Dazu ein paar Anpassungen für die aktuelle Lib und Ergänzungen meinerseits.
Zitat"time proportioning control" eine Art extrem langsames PWM. Bei über 50% schaltet das Ventil zuerst ein, unter 50% zuerst aus. Nach einer Änderung wird die erste Ein- oder Auszeit einmal halbiert
HBWValve kann auch in einem eigenen Device genutzt werden, als einfacher Ventilsteller.

Konfiguration:
   LOGGING
   OUTPUT_LOCKED
   INVERTED
   SEND_MAX_INTERVALL
   VALVE_ERROR_POS
   SWITCH_TIME (Zeit die zum vollständigen öffnen benötigt wird)

set the desired Valve State in Manual Mode level = 0 - 200 like a Blind or Dimmer
* Special values:
* 201 - toggle automatic/manual
* 203 - manual (set error position 1st. Then allow any level 0...100%)
* 205 - automatic (locks the channel to be controlled by linked PID channel)


https://github.com/loetmeister/HBWired/tree/master/HBW-CC-VD-8

PS: Sind noch immer keine 8 Kanäle.... bin noch am testen.. :)



Thorsten,
bzgl. der Möglichkeit das HBW Devices untereinander daten per peering auszutauschen. Ich wollte ja die "InfoMessage" (0x69) nutzen... Da aber der Frame doch anders aufgebaut ist, habe ich das in HBWLink_InfoEvent umbenannt und type 0xB4 definiert (ein mix auf Info Message und KeyEvent 0x4B).
Das ganze ist Standardmäßig inaktiv, wenn man die Funktion braucht muss man es per "define" aktivieren.
Wäre das ein gangbarer Weg?
HBWired.h
// #define Support_HBWLink_InfoEvent


https://github.com/loetmeister/HBWired/commit/6f25152bb04cb5d8ed103eda8b41dd8e84ba612c


PPS: Bzgl. dem Pointer werde ich testen und ändern... [uint16_t level;   get((uint8_t*)(&level));] Danke!

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: stan23 am 09 Mai 2019, 13:57:13
Zitat von: Thorsten Pferdekaemper am 08 Mai 2019, 21:32:02
uint8_t ist halt mal nur ein Byte, wenn Du dann sowas machst wie *data++ = ..., dann überschreibst Du irgendwas, was zufällig danach kommt. Wenn Du das ganze mit static deklarierst, dann steht es halt in einem anderen Speicherbereich, bei dem es zufällig nicht ganz so weh tut (oder eben erst später).

Das ist eine funktionslokale Variable und sie liegt auf dem Stack. Weil der Stack rückwärts wächst, hast du dir damit irgendwas überschrieben, was in loop() kurz davor auf den Stack gelegt wird.

uint8_t level;


Diese Variable behält ihren Wert bis zum nächsten Funktionsaufruf und sie liegt im globalen Speicherbereich. Du hast dir damit irgendwas überschrieben was danach liegt, oder mit etwas Glück ist dort frei. Zumindest wird der Fehler nicht gleich sichtbar.

static uint8_t level;   

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 09 Mai 2019, 22:39:31
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
    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)
    static uint8_t level[2];
    get(level);
    device->sendInfoMessage(channel, 2, level):


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 18 Mai 2019, 19:16:30
Hallo Thorsten,

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

Neue Geräte:

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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 20 Mai 2019, 09:03:57
...ist gemerged.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 09 August 2019, 11:29:21
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 10 August 2019, 11:26:56
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 10 August 2019, 12:23:43
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ß
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 10 August 2019, 12:39:33
Hi,

Zitat von: aperoap am 10 August 2019, 12:23:43
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  ;D
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 10 August 2019, 21:30:36
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.

// 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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 10 August 2019, 23:48:30
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?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 11 August 2019, 16:46:35
Zitat von: aperoap am 10 August 2019, 23:48:30
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 11 August 2019, 21:34:57
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ß
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 12 August 2019, 14:23:07
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 12 August 2019, 14:41:17
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 12 August 2019, 18:25:28
Zitat von: Thorsten Pferdekaemper am 12 August 2019, 14:41:17
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 12 August 2019, 21:54:33
Zitat von: Thorsten Pferdekaemper am 12 August 2019, 14:23:07
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?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 12 August 2019, 23:19:40
Zitat von: aperoap am 12 August 2019, 21:54:33
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?
Gegen GND schalten ist gut... passt deine Pin Zuordnung? Der erste KEY Kanal ist Nr. 17 an Pin 7 im "DEBUG" modus, mit #define USE_HARDWARE_SERIAL aber Pin 12.... :)
Wie hast du denn den "KEY" Kanal konfiguriert? Ich glaube PUSHBUTTON ist die Standard Einstellung. Ändert sich der "SENSOR" Kanal? (Diese müssen aber mit FHEM abgefragt werden.)
Siehst du was im Seriellen Monitor von der Arduino IDE? Mit "#define DEBUG_OUTPUT" in HBWKey.h gibt es ein paar mehr Details.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 13 August 2019, 10:46:55
Zitat von: loetmeister am 12 August 2019, 18:25:28
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?
Genau.

Zitat
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?
Nein, ich glaube nicht, dass die CCU das so macht. Ich habe zwar keine CCU, aber es würde mich wundern. Ich denke eher, dass das im Sensor-Device beim Tastendruck erledigt wird. D.h. auch wenn es mehrere Peerings zu einem Device gibt, wird nur eine Nachricht geschickt.

Zitat
Müsste das nicht sogar schon jetzt funktionieren? (wenn FHEM das EEPROM so beschreiben würde?)
Im Prinzip schon, aber nur, wenn das Aktor-Device ein Original-eq3-Teil ist. Bei HBW prüfen wir ja, ob der Empfänger-Kanal richtig gesetzt wurde, oder?
Allerdings wird es beim Löschen eines Peerings schwierig. Woher soll das Sensor-Device wissen, dass man nur einen der zwei "Endpunkte" rauswerfen will. Theoretisch könnte man das irgendwie in FHEM erledigen, aber momentan würde sowas von Sensor-Seite aus wahrscheinlich "falsch" angezeigt werden.

Zitat
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.
Ich meinte das ja auch gar nicht als komplette Lösung des Problems. Ich hatte mir nur überlegt, wie man die Anzahl der Nachrichten ggf. reduzieren kann. Ansonsten muss man ja jedesmal auf ein ACK warten, was dann in der Summe dazu führen kann, dass der ganze Vorgang ein paar Sekunden dauert. Das wäre natürlich sehr lästig. Wenn man dann wenigstens alle Kanäle eines Device zusammenfassen könnte, dann wäre schon viel geholfen.

Gruß,
    Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 13 August 2019, 10:53:16
Zitat von: aperoap am 12 August 2019, 21:54:33Somit wäre die arduino Lösung mit homebrew viel besser auch wenn es mir viel Zeit kosten würde.
Na dann, wenn Du Zeit hast, dann geh mal das Homebrew-Tutorial durch und baue den HMW-Sen-SC-12-DR/FM nach.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 13 August 2019, 22:44:26
Zitat von: Thorsten Pferdekaemper am 13 August 2019, 10:46:55
Ich denke eher, dass das im Sensor-Device beim Tastendruck erledigt wird. D.h. auch wenn es mehrere Peerings zu einem Device gibt, wird nur eine Nachricht geschickt.
[...] Bei HBW prüfen wir ja, ob der Empfänger-Kanal richtig gesetzt wurde, oder?
Ja, es müssen Senderadresse, Senderkanal und Zielkanal übereinstimmen, sonst wird das peering im Aktor nicht angewendet.

Hätte denn diese KeyEvent Nachricht, die mehrere Kanäle im Aktor schaltet auch mehrere Kanalnummern im Frame? Der Aktor kann ja nicht einfach den Ziel- oder Quellkanal ignorieren und nur auf die Quelladresse schauen...

Leicht erweitertes Setup:
Sensor A ch 1 -> Aktor B ch 1 (short action, toggle)
Sensor A ch 1 -> Aktor B ch 2 (short action, toggle)
Sensor A ch 2 -> Aktor B ch 1 (short action, on)

Aktor B sollte ja nur die ersten beiden peering Aktionen bei einem 'short' KeyEvent von Sensor A ch 1 ausführen... bin mir nicht sicher wie das gehen könnte.. :)


Zitat
Ich meinte das ja auch gar nicht als komplette Lösung des Problems. Ich hatte mir nur überlegt, wie man die Anzahl der Nachrichten ggf. reduzieren kann. Ansonsten muss man ja jedesmal auf ein ACK warten, was dann in der Summe dazu führen kann, dass der ganze Vorgang ein paar Sekunden dauert. Das wäre natürlich sehr lästig. Wenn man dann wenigstens alle Kanäle eines Device zusammenfassen könnte, dann wäre schon viel geholfen.
Stimmt, mit nur drei peerings ist schon eine leichte Verzögerung sichtbar. Wäre gut weniger auf die Leitung zu schicken.


PS: Hab mal ein bisschen in den XML geschaut, bzgl. den Key Events... "KEY_SIM_*" hat im Frame receiver_channel_field="11" (id="KEY_SIM_SHORT" direction="from_device" type="#K" channel_field="10" receiver_channel_field="11")
Im "normalen" Key Event ist das nicht vorhanden, d.h. HBW nutzt immer "KEY_SIM_*"? (da die Zielkanalnummer mit geschickt wird)
id="KEY_EVENT_SHORT" direction="from_device" event="true" type="#K" channel_field="10"
Ich hatte bisher nur gesehen das beim KeyEvent an die Broadcast Adresse Kanal 0 genutzt wird...

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 August 2019, 12:12:17
Zitat von: loetmeister am 13 August 2019, 22:44:26
Hätte denn diese KeyEvent Nachricht, die mehrere Kanäle im Aktor schaltet auch mehrere Kanalnummern im Frame? Der Aktor kann ja nicht einfach den Ziel- oder Quellkanal ignorieren und nur auf die Quelladresse schauen...
Nein, es gibt nicht mehrere Kanalnummern im Frame. Der Aktor ignoriert nur den Ziel-Kanal, der Quell-Kanal wird aber beachtet.

Zitat
Leicht erweitertes Setup:
Sensor A ch 1 -> Aktor B ch 1 (short action, toggle)
Sensor A ch 1 -> Aktor B ch 2 (short action, toggle)
Sensor A ch 2 -> Aktor B ch 1 (short action, on)
Aktor B sollte ja nur die ersten beiden peering Aktionen bei einem 'short' KeyEvent von Sensor A ch 1 ausführen... bin mir nicht sicher wie das gehen könnte.. :)
Es geht, indem das Ziel-Device nur die Peerings mit Quell-Kanal 1 beachtet. Im Aktor ist in den Links sowohl die Quell-Adresse als auch der Quell-Kanal gespeichert. So weiß der Aktor, dass in diesem Fall nur die ersten beiden Peerings in Frage kommen.

Zitat
PS: Hab mal ein bisschen in den XML geschaut, bzgl. den Key Events... "KEY_SIM_*" hat im Frame receiver_channel_field="11" (id="KEY_SIM_SHORT" direction="from_device" type="#K" channel_field="10" receiver_channel_field="11")
Im "normalen" Key Event ist das nicht vorhanden, d.h. HBW nutzt immer "KEY_SIM_*"? (da die Zielkanalnummer mit geschickt wird)
id="KEY_EVENT_SHORT" direction="from_device" event="true" type="#K" channel_field="10"
Die Devices nutzen die "normalen" Key-Events und schicken einen Target-Kanal mit, auch wenn das nicht im XML steht. (Wenn man von eq3-Standard-Devices ausgeht, dann müssten sie das nicht einmal tun.) Soweit ich das verstehe, sind die XMLs ja vor Allem für die Zentrale gedacht. Die Devices selbst werten das XML ja nicht aus. Außerdem reagieren die Geräte auf einen KEY_SIM-Event genauso wie auf einen "normalen".
Man kann KEY_SIM-Events und normale Events auch nur daran unterscheiden, dass normale das zweite Bit im "Event"-Byte gesetzt haben. KEY_SIM-Events sollten auch nur von der Zentrale geschickt werden (also einer CCU oder eben FHEM), um einen Tastendruck zu "simulieren". Wahrscheinlich müssen KEY_SIM- und normale Events nur deshalb unterschiedlich sein, weil sonst ein KEY_SIM-Event vom Empfänger fälschlicherweise als Wiederholung eines normalen Events missverstanden werden kann.

Gruß,
  Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 14 August 2019, 19:55:28
Zitat von: loetmeister am 12 August 2019, 23:19:40
Gegen GND schalten ist gut... passt deine Pin Zuordnung? Der erste KEY Kanal ist Nr. 17 an Pin 7 im "DEBUG" modus, mit #define USE_HARDWARE_SERIAL aber Pin 12.... :)
Wie hast du denn den "KEY" Kanal konfiguriert? Ich glaube PUSHBUTTON ist die Standard Einstellung. Ändert sich der "SENSOR" Kanal? (Diese müssen aber mit FHEM abgefragt werden.)
Siehst du was im Seriellen Monitor von der Arduino IDE? Mit "#define DEBUG_OUTPUT" in HBWKey.h gibt es ein paar mehr Details.

Gruß,
Thomas

ich wusste nicht, dass ich den Zustand von Sensoren aktiv mit fhem abfragen soll. Mit der abfrage funktioniert das schon, wie bekomme ich das hin, dass der Arduino bei eine Zustandsänderung bei Sensoren per rs485 automatisch sendet? Der Tutorial hat mich da nicht weiter (wenn ich nichts übersehen habe :))

Gruß
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 14 August 2019, 20:35:49
Zitat von: aperoap am 14 August 2019, 19:55:28
ich wusste nicht, dass ich den Zustand von Sensoren aktiv mit fhem abfragen soll. Mit der abfrage funktioniert das schon, wie bekomme ich das hin, dass der Arduino bei eine Zustandsänderung bei Sensoren per rs485 automatisch sendet?

Hi,

du testest noch mit HBW-SC-10-Dim-6? Oder hast du HMW-Sen-SC-12-DR schon nachgebaut?  ;D

Hab grad noch mal selber kurz getestet.... bei den "Sensor" Kanälen hatte ich die "notify" Nachricht standardmäßig deaktiviert. Da musst du per FHEM in die Kanalkonfiguration gehen und "NOTIFY" aktivieren. Dann sieht man in FHEM auch die Änderung, ohne es Abfragen zu müssen.
Die "Key" Kanäle sind aber standardmäßig aktiv. Sie sollten sich wie normale Taster verhalten. Umschalten auf DOORSENSOR geht auch hier in der Kanalkonfiguration.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 15 August 2019, 16:31:59
Zitat von: aperoap am 14 August 2019, 19:55:28wie bekomme ich das hin, dass der Arduino bei eine Zustandsänderung bei Sensoren per rs485 automatisch sendet? Der Tutorial hat mich da nicht weiter (wenn ich nichts übersehen habe :))
Im Prinzip müsstest Du das aus dem letzten Post herauslesen können (https://forum.fhem.de/index.php/topic,61780.msg560544.html#msg560544). Du bastelst Dir eine eigene Kanal-Implementierung (wie DimmerChannel) und schickst per sendInfoMessage in der Methode loop den aktuellen Status raus, wenn sich was geändert hat.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 15 August 2019, 21:53:55
Werde es mir mal am Wochenende intensiv anschauen.
HMW-Sen-SC-12-DR Habe ich noch nicht ausprobiert, werde es auch am Wochenende bzw. am Sonntag machen.  ;)
Danke und Lg
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 18 August 2019, 18:56:01
guten Abend zusammen,

habe mir seit gestern Zeit genommen, habe versucht mit Hilfe von Thorstens Tutorial und HBW_SC_10_Dim_6 ein HMW-Sen-SC-12-DR nachzubauen.
Bin jedoch langsam am verzweifeln. Habe vielen Ausprobiert. Endergebnis ist Folgendens
FHEM erkennt das xml Datei wandelt um in das benötigte pm.
Arduino nano Wird von FHEM erkannt, die 12 Sensor Inputs werden in FHEM generiert, es funktioniert jedoch nur ein Sensor und zwar der Letzter :)
hab anfänglich gedacht, dass das chanal Array nicht funktioniert und habe alles manuell eingetragen - ohne erfolg :(

anbei mein Sketch
#define HARDWARE_VERSION 0x01
#define FIRMWARE_VERSION 0x0004

//#define NUMBER_OF_INPUT_CHAN 0 //10   // input channel - pushbutton, key, other digital in
#define NUMBER_OF_SEN_INPUT_CHAN 12  // equal number of sensor channels, using same ports/IOs as INPUT_CHAN
//#define NUMBER_OF_DIM_CHAN 6  // PWM & analog output channels
//#define NUMBER_OF_VIRTUAL_INPUT_CHAN 6


#define HMW_DEVICETYPE 0x97 //device ID (make sure to import hbw_io-10_dim-6.xml into FHEM)

//#define USE_HARDWARE_SERIAL   // use hardware serial (USART) - this disables debug output


#include "FreeRam.h"

// HB Wired protocol and module
#include <HBWired.h>
#include <HBWLinkKey.h>
#include <HBWSenSC.h>


// Pins

  #define RS485_RXD 4
  #define RS485_TXD 2
  #define RS485_TXEN 3  // Transmit-Enable
  #define BUTTON 8  // Button fuer Factory-Reset etc.
  #define ADC_BUS_VOLTAGE A7  // analog input to measure bus voltage

 
  #define IO1 A3
  #define IO2 10
  #define IO3 11
  #define IO4 A0
  #define IO5 A1
  #define IO6 A2
  #define IO7 A4
  #define IO8 A5
  #define IO9 9  // dummy pin to fill the array elements
  #define IO10 7  // dummy pin to fill the array elements
  #define IO11 6
  #define IO12 5
 
  #include "HBWSoftwareSerial.h"
  // HBWSoftwareSerial can only do 19200 baud
  HBWSoftwareSerial rs485(RS485_RXD, RS485_TXD); // RX, TX


#define LED LED_BUILTIN        // Signal-LED




struct hbw_config {
  uint8_t logging_time;     // 0x01
  uint32_t central_address;  // 0x02 - 0x05
  uint8_t direct_link_deactivate:1;   // 0x06:0
  uint8_t              :7;   // 0x06:1-7
   hbw_config_senSC senCfg[NUMBER_OF_SEN_INPUT_CHAN]; // 0x13 - 0x1C (address step 1)
} hbwconfig;


HBWChannel* channels[NUMBER_OF_SEN_INPUT_CHAN];  // total number of channels for the device


class HBDimIODevice : public HBWDevice {
    public:
    HBDimIODevice(uint8_t _devicetype, uint8_t _hardware_version, uint16_t _firmware_version,
               Stream* _rs485, uint8_t _txen,
               uint8_t _configSize, void* _config,
               uint8_t _numChannels, HBWChannel** _channels,
               Stream* _debugstream, HBWLinkSender* linksender = NULL, HBWLinkReceiver* linkreceiver = NULL) :
    HBWDevice(_devicetype, _hardware_version, _firmware_version,
              _rs485, _txen, _configSize, _config, _numChannels, ((HBWChannel**)(_channels)),
              _debugstream, linksender, linkreceiver) {
    };
    //virtual void afterReadConfig();
};


HBDimIODevice* device = NULL;



void setup()
{




  byte digitalInput[12] = {IO1, IO2, IO3, IO4, IO5, IO6, IO7, IO8, IO9, IO10, IO11, IO12};  // assing pins
 
  for(uint8_t i = 0; i < NUMBER_OF_SEN_INPUT_CHAN; i++) {
   channels[i] = new HBWSenSC(digitalInput[i], &(hbwconfig.senCfg[i]));
  }


  Serial.begin(19200);
  rs485.begin();    // RS485 via SoftwareSerial
 
   
   
  device = new HBDimIODevice(HMW_DEVICETYPE, HARDWARE_VERSION, FIRMWARE_VERSION,
                             &rs485, RS485_TXEN, sizeof(hbwconfig), &hbwconfig,
                             NUMBER_OF_SEN_INPUT_CHAN, (HBWChannel**)channels,
                             &Serial, NULL, NULL);
 
  device->setConfigPins(BUTTON, LED);  // 8 (button) and 13 (led) is the default
  device->setStatusLEDPins(LED, LED); // Tx, Rx LEDs

  hbwdebug(F("B: 2A "));
  hbwdebug(freeRam());
  hbwdebug(F("\n"));
 

}


void loop()
{
  device->loop();
};


mein XML Datei

<?xml version="1.0"?>
<device eep_size="1024" version="14">
<supported_types>
<type priority="2" id="HBW-Sen-Win-12" name="RS485 6-channel master dimming actuator and 10 Digital inputs">
<parameter const_value="0x97" size="1" index="0"/><!--HMW_DEVICETYPE-->
<parameter const_value="1" size="1" index="1"/><!--HARDWARE_VERSION-->
<parameter const_value="0x0004" size="2" cond_op="GE" index="2"/><!--Min. FIRMWARE_VERSION-->
</type>
</supported_types>

<paramset id="HBW-Sen-Win-12_dev_master" type="MASTER">
<parameter id="LOGGING_TIME">
<logical type="float" unit="s" default="5.0" max="25.5" min="0.1"/>
<physical size="1.0" type="integer" interface="eeprom">
<address index="0x0001"/>
</physical>
<conversion type="float_integer_scale" offset="0.0" factor="10"/>
</parameter>
<parameter id="CENTRAL_ADDRESS" hidden="true">
<logical type="integer"/>
<physical size="4" type="integer" interface="eeprom">
<address index="0x0002"/>
</physical>
</parameter>
<parameter id="DIRECT_LINK_DEACTIVATE" hidden="true">
<logical type="boolean" default="false"/>
<physical interface="eeprom" size="0.1" type="integer">
<address index="0x0006"/>
</physical>
</parameter>
<enforce id="CENTRAL_ADDRESS" value="1"/>
<enforce id="DIRECT_LINK_DEACTIVATE" value="true"/>
</paramset>

<frames>
<frame id="LEVEL_SET" type="#x" channel_field="10" direction="to_device">
<parameter size="1.0" index="11.0" type="integer" param="LEVEL"/>
</frame>
<frame id="LEVEL_GET" type="#S" channel_field="10" direction="to_device"/>
<frame id="INFO_LEVEL" type="#i" channel_field="10" direction="from_device" event="true">
<parameter size="1.0" index="11.0" type="integer" param="LEVEL"/>
<parameter size="0.3" index="12.4" type="integer" param="STATE_FLAGS"/>
</frame>
<frame id="STATE_LEVEL" type="#i" channel_field="10" direction="from_device" event="true">
<parameter size="1.0" index="11.0" type="integer" param="STATE"/>
</frame>
<frame id="KEY_EVENT_SHORT" type="#K" channel_field="10" direction="from_device" event="true">
<parameter const_value="0" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="KEY_EVENT_LONG" type="#K" channel_field="10" direction="from_device" event="true">
<parameter const_value="1" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="KEY_SIM_SHORT" type="#K" channel_field="10" direction="from_device" receiver_channel_field="11">
<parameter const_value="0" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="KEY_SIM_LONG" type="#K" channel_field="10" direction="from_device" receiver_channel_field="11">
<parameter const_value="1" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="SET_LOCK" type="#l" channel_field="11" direction="to_device">
<parameter param="inhibit" size="1.0" index="12.0" type="integer"/>
</frame>
<frame id="TOGGLE_INSTALL_TEST" type="#x" channel_field="10" direction="to_device">
<parameter param="toggle_flag" size="1.0" index="11.0" type="integer"/>
</frame>
</frames>

<channels>
<channel index="0" type="MAINTENANCE" count="1" class="maintenance" ui_flags="internal">

</channel>



<channel index="1" physical_index_offset="-1" count="12" type="SENSOR"> <!-- input sensor contact chan -->
<paramset type="MASTER" id="hmw_sensor_ch_master" address_start="0x13" address_step="1">
    <parameter id="INPUT_LOCKED">
<logical type="boolean" default="false"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.0"/>
</physical>
<conversion type="boolean_integer" invert="true"/>
</parameter>
<parameter id="INVERTED">
<logical type="boolean" default="false"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.1"/>
</physical>
<conversion type="boolean_integer" invert="true"/>
</parameter>
<parameter id="NOTIFY">
<logical type="option">
<option id="ON"/>
<option id="OFF" default="true"/>
</logical>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.2"/>
</physical>
</parameter>
</paramset>

<paramset type="VALUES" id="hmw_sensor_ch_values">
<parameter id="SENSOR" operations="read,event" control="DOOR_SENSOR.STATE">
<logical type="boolean"/>
<physical type="integer" interface="command" value_id="STATE">
<event frame="STATE_LEVEL" auth_violate_policy="reject"/>
<get request="LEVEL_GET" response="STATE_LEVEL"/>
</physical>
</parameter>
<parameter id="INSTALL_TEST" operations="event" ui_flags="internal">
<logical type="action"/>
<physical type="integer" interface="command" value_id="TEST_COUNTER">
<event frame="STATE_LEVEL"/>
</physical>
</parameter>
</paramset>
</channel>



</channels>
</device>


natürlich kann mann die <frames> noch kürzen, werde das machen Sobald die Sensoren funktionieren :)

kann mir jemand von euch Profis ein Tipp geben wo mein Fehler ist, bzw was ich übersehen habe?

Gruß
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 18 August 2019, 19:57:06
ZitatArduino nano Wird von FHEM erkannt, die 12 Sensor Inputs werden in FHEM generiert, es funktioniert jedoch nur ein Sensor und zwar der Letzter

Interessant wäre der log vom HM485d Dämon. Bei jeder änderung open/close müsste da ungefähr folgendes im log stehen:
2019.08.18 19:34:20.271 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42ABFFEE -> 00000001 [6] 69(i) 00C800 {EC7C}
Dabei ist bei 00C800 das Hexbyte am Anfang der Kanal - 1 (00 ist Kanal 1 und 0B ist Kanal 12) 
und das zweite Hexbyte der Zutand open oder close

Gruß Ralf

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 18 August 2019, 20:08:47
Zitat von: Ralf9 am 18 August 2019, 19:57:06
Interessant wäre der log vom HM485d Dämon. Bei jeder änderung open/close müsste da ungefähr folgendes im log stehen:
2019.08.18 19:34:20.271 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42ABFFEE -> 00000001 [6] 69(i) 00C800 {EC7C}
Dabei ist bei 00C800 das Hexbyte am Anfang der Kanal - 1 (00 ist Kanal 1 und 0B ist Kanal 12) 
und das zweite Hexbyte der Zutand open oder close

Gruß Ralf


Hi Ralf, ich sehe an Status led von arduino dass die Sensoren nicht geschaltet werden, daher wird der  hm485 log keine Infos anzeigen. Nichtsdestotrotz würde ich gerne wissen wie ich an diese Logs komme. Bei mir sind in FHEM kein logfile zu sehen.
Gruß
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 18 August 2019, 20:15:59
Hi,

Das device sieht ganz gut aus... Bis auf die falsche Startadresse der config sehe ich nichts problematisches.

Start ist 0x07, nicht 13..
senCfg[NUMBER_OF_SEN_INPUT_CHAN]; // 0x13 -

Aktiviere mal das logging in HBWSenSC.h. Dann kannst du erst mal das device ans laufen bringen, dann weiter schauen wo es mit FHEM klemmt..

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 19 August 2019, 00:03:11
ZitatNichtsdestotrotz würde ich gerne wissen wie ich an diese Logs komme. Bei mir sind in FHEM kein logfile zu sehen.
dafür gibts die beiden Attribute

HM485d_logVerbose
If this is set to a nonzero value, then the output from the HM485d process goes into the main FHEM logfile or into the HM485d logfile, if the next attribute is set.

HM485d_logfile
The HM485d process can write an own log file with HM485d_logfile as filename.

Gruß Ralf
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 22 August 2019, 21:47:57
Hi habe HM485d_logVerbose auf 5 gestellt, ein logfile definiert und HM485d_logfile eingestellt. Die logs werden jedoch noch in fhem logfile geschriebem und nicht in HM485d_logfile. Mache ich was falsch?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 22 August 2019, 23:51:00
Hast Du ein fhem restart gemacht, damit der HM485d neu gestartet wird?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 24 August 2019, 00:03:18
Zitat von: aperoap am 10 August 2019, 23:48:30
Ich werde das mal ausprobieren, vielen Dank.

Hi,

hattest du die erweiterte Version, mit dem Sendepuffer mal ausprobiert? In meinen Tests hatte es funktioniert...

Hatte den Code noch etwas angepasst, um alle Nachrichten typen speichern zu können. D.h. im Prinzip wird die komplette Nachricht gespeichert, aber nur wenn die daten maximal 8 byte nicht überschreiten.

Ich muss das mal etwas ausgiebiger mit meinen Geräten testen...

static const uint8_t SEND_BUFFER_SIZE = 4; // amount of messages to store
static const uint8_t MAX_TX_BUFFER_FRAME_LENGTH = 8; // max frame size for the buffer

struct s_SendBuffer
{
uint32_t targetAddress;
uint8_t frameControlByte;
uint8_t frameDataLength;              // Laenge der Daten
uint8_t frameData[MAX_TX_BUFFER_FRAME_LENGTH]; // don't buffer large frames; frameDataLength < MAX_TX_BUFFER_FRAME_LENGTH
uint8_t reSendCounter;
};


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 24 August 2019, 21:00:37
Zitat von: aperoap am 22 August 2019, 21:47:57
Hi habe HM485d_logVerbose auf 5 gestellt, ein logfile definiert und HM485d_logfile eingestellt. Die logs werden jedoch noch in fhem logfile geschriebem und nicht in HM485d_logfile. Mache ich was falsch?
Hi,
die Syntax mit %Y etc. funktioniert hier wahrscheinlich nicht. Das ist kein FHEM-FileLog, sondern einfach eine normale Betriebssystemdatei. Lass das mit dem speziellen Logfile am besten, dann sollte alles im normalen FHEM-Log landen.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 25 August 2019, 12:39:46
Zitat von: loetmeister am 24 August 2019, 00:03:18
Hi,

hattest du die erweiterte Version, mit dem Sendepuffer mal ausprobiert? In meinen Tests hatte es funktioniert...

Hatte den Code noch etwas angepasst, um alle Nachrichten typen speichern zu können. D.h. im Prinzip wird die komplette Nachricht gespeichert, aber nur wenn die daten maximal 8 byte nicht überschreiten.

Ich muss das mal etwas ausgiebiger mit meinen Geräten testen...

static const uint8_t SEND_BUFFER_SIZE = 4; // amount of messages to store
static const uint8_t MAX_TX_BUFFER_FRAME_LENGTH = 8; // max frame size for the buffer

struct s_SendBuffer
{
uint32_t targetAddress;
uint8_t frameControlByte;
uint8_t frameDataLength;              // Laenge der Daten
uint8_t frameData[MAX_TX_BUFFER_FRAME_LENGTH]; // don't buffer large frames; frameDataLength < MAX_TX_BUFFER_FRAME_LENGTH
uint8_t reSendCounter;
};


Gruß,
Thomas
habe es nicht ausprobiert, werde ich demnächst machen. Die Idee finde ich super.

Zitat von: Thorsten Pferdekaemper am 24 August 2019, 21:00:37
Hi,
die Syntax mit %Y etc. funktioniert hier wahrscheinlich nicht. Das ist kein FHEM-FileLog, sondern einfach eine normale Betriebssystemdatei. Lass das mit dem speziellen Logfile am besten, dann sollte alles im normalen FHEM-Log landen.
Gruß,
   Thorsten
super vielen Dank, lag wirklich an Syntax.  ;D ;)

Gruß
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 28 August 2019, 23:48:43
Hallo,

habe die Änderungen für den Sendepuffer mal in GitHub geladen.
Um weniger Code zu belegen, habe ich die einzelnen Variablen zum senden eines Frames in einen struct (s_txFrame) übernommen, dann kann ich zwischen Puffer und dem aktuellen txFrame hin und her kopieren.

Das Verhalten für KeyEvent Nachrichten ist wie folgt:
Edit : habe der Funktion sendKeyEvent den "enqueue" Parameter hinzugefügt. So lässt sich das Puffern aus dem Kanal steuern und unterdrücken, wenn es nicht sinnvoll ist. Das ganz setup müsste man noch ausgiebig testen... Also wer Lust hat, immer los.  8)
Was noch nicht gut ist: Wiederholte long press füllen den Puffer. Am einfachsten könnte ich einen Parameter  sendKeyEvent hinzufügen, dann lässt sich das direkt aus dem Kanal steuern...

https://github.com/loetmeister/HBWired/commit/ed0e3a02acfa4a9186ca7c7c0d354b632450cd87#diff-340d6f8cfa01a00fa61bea3db56dfddfR719

Zum testen, am besten den ganzen "lib" Ordner aktualisieren:
https://github.com/loetmeister/HBWired/tree/master/libraries/src

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 29 September 2019, 12:50:07
Hallo Thomas,

ich wollte heute einmal deinen HBW-SC-10-Dim-6 auf den nano spielen und ausprobieren. Aktuell wird er von Fhem nicht erkannt. Das liegt wohl auch an der pm Datei da diese aus der xml nicht generiert wird. Die Rechte habe ich mir schon einmal angeschaut und überprüft.

Hast du noch eine Idee!


Hier noch der Bus aus Fhem
Zitat2019.09.29 12:42:24.629 0: HM485d: Server stopped ...
2019.09.29 12:42:41.895 3: HM485d: port 2000 opened
2019.09.29 12:42:41.895 3: HM485d: server waiting for client connection on port 2000
2019.09.29 12:42:41.897 3: Opening SERIAL device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6025BA0-if00-port0
2019.09.29 12:42:41.952 3: SERIAL device opened
2019.09.29 12:42:41.955 3: HM485d: SERIALbaudrate=19200, databits=8, parity=even, stopbits=1, handshake=none
2019.09.29 12:42:41.955 2: HM485d: SERIAL connected to device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6025BA0-if00-port0
2019.09.29 12:42:41.956 1: HM485d: Server started ...
2019.09.29 12:42:46.550 4: Connection accepted from HM485d_127.0.0.1_42308
2019.09.29 12:42:46.557 4: HM485d: Tx: H00,01,HMW-SOFT-GW,0.2.2,SGW0123456

2019.09.29 12:42:46.565 4: HM485d: Rx: FD3E30312C303030300D0A
2019.09.29 12:43:06.573 4: HM485d: Rx: FD02024B
2019.09.29 12:43:06.574 4: HM485d: Tx: FD03026100
2019.09.29 12:43:26.577 4: HM485d: Rx: FD02034B
2019.09.29 12:43:26.578 4: HM485d: Tx: FD03036100
2019.09.29 12:43:46.586 4: HM485d: Rx: FD02044B
2019.09.29 12:43:46.587 4: HM485d: Tx: FD03046100
2019.09.29 12:44:06.595 4: HM485d: Rx: FD02054B
2019.09.29 12:44:06.596 4: HM485d: Tx: FD03056100
2019.09.29 12:44:26.602 4: HM485d: Rx: FD02064B
2019.09.29 12:44:26.602 4: HM485d: Tx: FD03066100
2019.09.29 12:44:46.612 4: HM485d: Rx: FD02074B
2019.09.29 12:44:46.613 4: HM485d: Tx: FD03076100
2019.09.29 12:45:06.623 4: HM485d: Rx: FD02084B
2019.09.29 12:45:06.624 4: HM485d: Tx: FD03086100
2019.09.29 12:45:26.630 4: HM485d: Rx: FD02094B
2019.09.29 12:45:26.630 4: HM485d: Tx: FD03096100
2019.09.29 12:45:46.641 4: HM485d: Rx: FD020A4B
2019.09.29 12:45:46.641 4: HM485d: Tx: FD030A6100
2019.09.29 12:46:06.652 4: HM485d: Rx: FD020B4B
2019.09.29 12:46:06.652 4: HM485d: Tx: FD030B6100
2019.09.29 12:46:26.659 4: HM485d: Rx: FD020C4B
2019.09.29 12:46:26.660 4: HM485d: Tx: FD030C6100
2019.09.29 12:46:46.670 4: HM485d: Rx: FD020D4B
2019.09.29 12:46:46.671 4: HM485d: Tx: FD030D6100

Und hier noch der SerialMonitor vom Device:
Zitat2019.09.29 12:42:24.629 0: HM485d: Server stopped ...
2019.09.29 12:42:41.895 3: HM485d: port 2000 opened
2019.09.29 12:42:41.895 3: HM485d: server waiting for client connection on port 2000
2019.09.29 12:42:41.897 3: Opening SERIAL device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6025BA0-if00-port0
2019.09.29 12:42:41.952 3: SERIAL device opened
2019.09.29 12:42:41.955 3: HM485d: SERIALbaudrate=19200, databits=8, parity=even, stopbits=1, handshake=none
2019.09.29 12:42:41.955 2: HM485d: SERIAL connected to device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6025BA0-if00-port0
2019.09.29 12:42:41.956 1: HM485d: Server started ...
2019.09.29 12:42:46.550 4: Connection accepted from HM485d_127.0.0.1_42308
2019.09.29 12:42:46.557 4: HM485d: Tx: H00,01,HMW-SOFT-GW,0.2.2,SGW0123456

2019.09.29 12:42:46.565 4: HM485d: Rx: FD3E30312C303030300D0A
2019.09.29 12:43:06.573 4: HM485d: Rx: FD02024B
2019.09.29 12:43:06.574 4: HM485d: Tx: FD03026100
2019.09.29 12:43:26.577 4: HM485d: Rx: FD02034B
2019.09.29 12:43:26.578 4: HM485d: Tx: FD03036100
2019.09.29 12:43:46.586 4: HM485d: Rx: FD02044B
2019.09.29 12:43:46.587 4: HM485d: Tx: FD03046100
2019.09.29 12:44:06.595 4: HM485d: Rx: FD02054B
2019.09.29 12:44:06.596 4: HM485d: Tx: FD03056100
2019.09.29 12:44:26.602 4: HM485d: Rx: FD02064B
2019.09.29 12:44:26.602 4: HM485d: Tx: FD03066100
2019.09.29 12:44:46.612 4: HM485d: Rx: FD02074B
2019.09.29 12:44:46.613 4: HM485d: Tx: FD03076100
2019.09.29 12:45:06.623 4: HM485d: Rx: FD02084B
2019.09.29 12:45:06.624 4: HM485d: Tx: FD03086100
2019.09.29 12:45:26.630 4: HM485d: Rx: FD02094B
2019.09.29 12:45:26.630 4: HM485d: Tx: FD03096100
2019.09.29 12:45:46.641 4: HM485d: Rx: FD020A4B
2019.09.29 12:45:46.641 4: HM485d: Tx: FD030A6100
2019.09.29 12:46:06.652 4: HM485d: Rx: FD020B4B
2019.09.29 12:46:06.652 4: HM485d: Tx: FD030B6100
2019.09.29 12:46:26.659 4: HM485d: Rx: FD020C4B
2019.09.29 12:46:26.660 4: HM485d: Tx: FD030C6100
2019.09.29 12:46:46.670 4: HM485d: Rx: FD020D4B
2019.09.29 12:46:46.671 4: HM485d: Tx: FD030D6100
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 29 September 2019, 16:58:31
Hi,

Steht im fhem log etwas dazu? Bei jedem Start wird überprüft ob sich die xml Dateien geändert haben und eine neue pm Datei generiert. Ich wüsste jetzt nicht warum die xml bei dir nicht konvertiert wird.
Ohne passende pm sollte aber ein generic device angelegt werden....

Du hast, glaube ich auch versehentlich zweimal das selbe log in deinen Beitrag kopiert..

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 29 September 2019, 17:25:20
Das war in der tat der Falsche...
Hier der SerialMonitor vom Device:
B: 2A 367
VKey_ch:0 short
T: FD:FF:FF:FF:FB: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367


Und hier der Fhem Log:
Zitat019.09.29 17:24:03 3: Probing FRM device /dev/ttyUSB0
2019.09.29 17:24:08 1: usb create end
2019.09.29 17:24:08 0: Featurelevel: 5.9
2019.09.29 17:24:08 0: Server started with 11 defined entities (fhem.pl:20069/2019-08-27 perl:5.028001 os:linux user:fhem pid:635)
2019.09.29 17:24:08 3: hm485: Start HM485d with command line: ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000001 --serialNumber SGW0123456 --device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6025BA0-if00-port0 --localPort 2000 --logfile ./log/HM485-2019-37.log --verbose 4
2019.09.29 17:24:08 3: hm485: HM485d was started with PID:   645
2019.09.29 17:24:08 3: hm485: Connect to HM485d delayed for 5 seconds
2019.09.29 17:24:13 3: Opening hm485 device localhost:2000
2019.09.29 17:24:13 3: hm485: connected to device localhost:2000
2019.09.29 17:24:13 3: hm485 device opened
2019.09.29 17:24:13 3: hm485: Lan Device Information
2019.09.29 17:24:13 3: hm485: Protocol-Version: 01
2019.09.29 17:24:13 3: hm485: Interface-Type: HMW-SOFT-GW
2019.09.29 17:24:13 3: hm485: Firmware-Version: 0.2.2
2019.09.29 17:24:13 3: hm485: Serial-Number: SGW0123456
2019.09.29 17:24:13 5: hm485: HM485_LAN_Write TX: 1
2019.09.29 17:24:13 3: hm485: Initialize the interface
2019.09.29 17:24:13 5: SW: fd3e30312c303030300d0a
2019.09.29 17:24:17 2: AttrTemplates: got 102 entries
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 30 September 2019, 00:18:01
Zitat von: holzwurm83 am 29 September 2019, 17:25:20
Das war in der tat der Falsche...
Hier der SerialMonitor vom Device:
B: 2A 367
VKey_..


Hi,

Da stimmt was nicht. Der Arduino scheint in einer Schleife zu hängen...  "B: 2A " darf nur einmal beim Start des devices angezeigt werden.
Gab es Warnungen beim kompilieren?
Kannst du zur Sicherheit noch mal die aktuelle library runter laden?


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 04 Oktober 2019, 16:58:18
Zitat von: loetmeister am 30 September 2019, 00:18:01
Gab es Warnungen beim kompilieren?
Kannst du zur Sicherheit noch mal die aktuelle library runter laden?


Ja, dass die OneWire.h fehlt. Danach habe ich die HBWOneWireTempSensors aus dem lib Ordner gelöscht. Danach gab es keine Fehler mehr.

Habe gerade auch nochmal den ganzen Ordner hier geladen:

https://github.com/loetmeister/HBWired (https://github.com/loetmeister/HBWired)

Der Serialmonitor zeigt weiterhin das gleiche an.

Hast du noch eine andere Idee?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 05 Oktober 2019, 00:53:32
Hi,

Nicht so richtig...  Du kompilierst die exakte Version die im github liegt?
Ich hatte mal arge Probleme mit den Arduino Versionen ab 1.8.6. Die funktionierte nur, wenn ich auf die alten kompiler Version zurück gegangen bin (EDIT: Arduino IDE 1.8.9 + AVR Boards, Version 1.6.21).
welche Version nutzt du? In der aktuellen 1.8.10 Version soll das Problem behoben sein.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 05 Oktober 2019, 10:58:39
Ja, ich habe mir die wie oben im Link runter geladen. Ich habe auch die Arduino 1.8.9 Version.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 05 Oktober 2019, 12:11:18
Hallo Thomas,

habe es gerade mal auf einen anderen Nano gespielt und da sieht es im Serialmonitor schon mal gut aus.

LH⸮)⸮B: 2A 367
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 367
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 367
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 367
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C


Kann es gerade nur in meinem Testsystem nicht testen.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 06 Oktober 2019, 20:06:14
Hi,
sieht das wirklich gut aus? Ich denke mal, dass die A-Message eigentlich nur einmal beim Einschalten rausgehen sollte.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 06 Oktober 2019, 23:03:26
Hi,

ich vermute mal es ist ein ähnliches Problem, welches ich auch hatte (https://forum.fhem.de/index.php/topic,22952.msg876113.html#msg876113) und den Arduino in eine reboot Schleife bringt.
Seitdem hatte ich zwar neue Versionen der Arduino IDE genutzt, aber die alte Version (1.6.21) der Arduino AVR Boards. (habe mein vorherigen Post dahingehen korrigiert.

Ich habe mal einen kurzen Test mit der aktuellen IDE 1.8.10 und Arduino AVR Boards, Version 1.8.1 gemacht (die aktuelle Version, die bei der IDE dabei ist).
HBW-SC-10-Dim-6 meldet sich im Serial Monitor korrekt mit einer "B: 2A ..." Meldung und Announce Nachricht.

EDIT: Leider ist das Problem nicht ganz behoben.. es fehlen Teile des Codes... das Gerät funktioniert nicht richtig! Es ist noch immer Version (1.6.21) der Arduino AVR Boards nötig... (umstellen, unter "tools > board:... > boards manager...")

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 22 Oktober 2019, 21:54:34
Hallo,

ich habe mittlerweile eine neue Version der HBWSoftwareSerial.h erstellt:
https://github.com/loetmeister/HBWired/commit/088bcb3317f2354890d75f386acf8e8e3587d81c#diff-925406d5971dd3118e5d6b124e9f1f3a
Basis ist die aktuelle SoftwareSerial.h, mit den Anpassungen aus der alten HBWSoftwareSerial.h
Nach ersten Tests mit der Arduino IDE 1.8.10 und AVR Boards Version 1.8.1 (die aktuelle Version, die bei der IDE dabei ist) scheint das Problem gelöst... wer ein paar Geräte zum testen hat, immer zu!. Rückmeldungen sind willkommen...  ;D

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 05 November 2019, 12:56:47
Zitat von: loetmeister am 02 Mai 2019, 20:52:38
ok... danke. Habe, wie vorgeschlagen, ein "issue" festgehalten:
https://github.com/kc-GitHub/FHEM-HM485/issues/63
Das ist jetzt erledigt. Testen kann ich es allerdings momentan nicht. ...zumindest scheine ich aber nichts kaputt gemacht zu haben.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 09 November 2019, 13:24:28
Zitat von: holzwurm83 am 05 Oktober 2019, 12:11:18
Hallo Thomas,

habe es gerade mal auf einen anderen Nano gespielt und da sieht es im Serialmonitor schon mal gut aus.

LH⸮)⸮B: 2A 367
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 367
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 367
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 367
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C


Kann es gerade nur in meinem Testsystem nicht testen.

Hallo Thomas,

war leider einige Woche etwas verhindert. Jetzt kann ich mich wieder den Themen widmen. Ich bin immer noch am HBW-SC-10-Dim-6 dran.
Da sich hier ja einiges getan hat habe ich noch mal alle Daten neu geladen.
Mein Arduino ist auf der neuesten Version. Und Fhem inclusive hm485 auch.
Die xml habe ich neu eingespielt und Fhem hat auch die pm Datei erstellt.
Ich habe jetzt leider immer noch mein ursprungsproblem, das fhem das Modul nicht anlegt.

Hier ist mal ein LOG aus dem Serialmonitor:
B: 2A 339
B: 2A 339
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 339
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 339
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 339
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
:BA:FB:FB:FF:FF:FF:FF:FF:FF:FFE: MsgTooLong
:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:7B:FF:F2:FF:2B:7B:FF:FER: FD:FF:FBB: 2A 339
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 339
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 339
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
:FF:FF:FFT: FD:FF:FF:FF:FF:F8:42:00:00:18:06:4B:13:00:06:0D:04
T: FD:FF:FF:FF:FF:F8:42:00:00:18:06:4B:14:00:06:73:F6
T: FD:FF:FF:FF:FF:F8:42:00:00:18:06:4B:15:00:06:61:D0
:FF:FF

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 09 November 2019, 18:06:48
Hi,
also wenn das wirklich das ist, was auf dem Bus abgeht, dann ist da sowieso noch was faul. Im Prinzip braucht man da gar nicht in FHEM nachsehen.
Andererseits habe ich auch schonmal seltsame Sachen im serial monitor gesehen und in FHEM war's dann kein Problem. Kannst Du mal ein Log in FHEM machen? D.h. verbose 5 im hm485-Device.
Gruß,
  Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 09 November 2019, 20:48:13
Hallo Thorsten,

ich hatte mittlerweile alle ein und Ausgänge einmal gegen GND geschalten und jetzt wurde der auch im Fhem angelegt.

Hier ist der Fhem LOG:
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000002C
2019.11.09 15:03:57 5: SW: fd0d8553c8420000181a000000016e
2019.11.09 15:03:57 4: hm485: hm485: TX: (133) I[1](0,F,B)(1A) 00000001 -> 42000018 [3] 6E(n)
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 133
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 133 Cmd: 114
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Response: (133) 48425737323936323830
2019.11.09 15:03:57 5: hm485: Dispatch: FD0D85723848425737323936323830
2019.11.09 15:03:57 5: hm485: dispatch �\r�r8HBW7296280
2019.11.09 15:03:57 5: hm485: HM485_Parse: MsgId: 133
2019.11.09 15:03:57 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: msgData = 48425737323936323830
2019.11.09 15:03:57 4: hm485: Device 42000018 not defined yet. We need the firmware version for autocreate
2019.11.09 15:03:57 5: hm485: HM485_QueueCommand76
2019.11.09 15:03:57 5: hm485: HM485_QueueStart: Num: 1
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess: Entries: 0 Index: 0
2019.11.09 15:03:57 5: hm485: HM485_QueueProcessStep: HASH(0x26ba400)
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000002C
2019.11.09 15:03:57 5: hm485: HM485_LAN_Write TX: 134
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000002D
2019.11.09 15:03:57 5: SW: fd0d8653c8420000181c0000000176
2019.11.09 15:03:57 4: hm485: hm485: TX: (134) I[2](0,F,B)(1C) 00000001 -> 42000018 [3] 76(v)
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 134
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 134 Cmd: 114
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Response: (134) 0005
2019.11.09 15:03:57 5: hm485: Dispatch: FD058672580005
2019.11.09 15:03:57 5: hm485: dispatch �\005�rX\000\005
2019.11.09 15:03:57 5: hm485: HM485_Parse: MsgId: 134
2019.11.09 15:03:57 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: msgData = 0005
2019.11.09 15:03:57 2: autocreate: define HBW_SC_10_Dim_6_HBW7296280 HM485 42000018 hm485
2019.11.09 15:03:57 2: hm485: Assigned 42000018 as HBW_SC_10_Dim_6_HBW7296280
2019.11.09 15:03:57 2: autocreate: define FileLog_HBW_SC_10_Dim_6_HBW7296280 FileLog ./log/HBW_SC_10_Dim_6_HBW7296280-%Y.log HBW_SC_10_Dim_6_HBW7296280
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess: Entries: 0 Index: 0
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000002D
2019.11.09 15:03:57 5: hm485: HM485_GetNewMsgQueue
2019.11.09 15:03:57 3: hm485: Initialisierung von Modul 42000018
2019.11.09 15:03:57 5: hm485: HM485_LAN_Write TX: 135
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000002E
2019.11.09 15:03:57 5: SW: fd0d8753c8420000181e0000000168
2019.11.09 15:03:57 4: hm485: hm485: TX: (135) I[3](0,F,B)(1E) 00000001 -> 42000018 [3] 68(h)
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 135
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 135 Cmd: 114
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Response: (135) 9601
2019.11.09 15:03:57 5: hm485: Dispatch: FD058772789601
2019.11.09 15:03:57 5: hm485: dispatch �\005�rx�\001
2019.11.09 15:03:57 5: hm485: HM485_Parse: MsgId: 135
2019.11.09 15:03:57 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: msgData = 9601
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: deviceKey =  requestType = 68 requestData =  msgData = 9601
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess: Entries: 2 Index: 0
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000002E
2019.11.09 15:03:57 5: hm485: HM485_LAN_Write TX: 136
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000002F
2019.11.09 15:03:57 5: SW: fd0d8853c84200001818000000016e
2019.11.09 15:03:57 4: hm485: hm485: TX: (136) I[0](0,F,B)(18) 00000001 -> 42000018 [3] 6E(n)
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 136
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 136 Cmd: 114
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Response: (136) 48425737323936323830
2019.11.09 15:03:57 5: hm485: Dispatch: FD0D88721848425737323936323830
2019.11.09 15:03:57 5: hm485: dispatch �\r�r\030HBW7296280
2019.11.09 15:03:57 5: hm485: HM485_Parse: MsgId: 136
2019.11.09 15:03:57 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: msgData = 48425737323936323830
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: deviceKey =  requestType = 6E requestData =  msgData = 48425737323936323830
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess: Entries: 2 Index: 1
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000002F
2019.11.09 15:03:57 5: hm485: HM485_LAN_Write TX: 137
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000030
2019.11.09 15:03:57 5: SW: fd0d8953c8420000181a0000000176
2019.11.09 15:03:57 4: hm485: hm485: TX: (137) I[1](0,F,B)(1A) 00000001 -> 42000018 [3] 76(v)
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 137
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 137 Cmd: 114
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Response: (137) 0005
2019.11.09 15:03:57 5: hm485: Dispatch: FD058972380005
2019.11.09 15:03:57 5: hm485: dispatch �\005�r8\000\005
2019.11.09 15:03:57 5: hm485: HM485_Parse: MsgId: 137
2019.11.09 15:03:57 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: msgData = 0005
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: deviceKey =  requestType = 76 requestData =  msgData = 0005
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess: Entries: 2 Index: 2
2019.11.09 15:03:57 3: HBW_SC_10_Dim_6_HBW7296280: Request config for device 42000018
2019.11.09 15:03:57 3: HBW_SC_10_Dim_6_HBW7296280: Lese Eeprom 42000018
2019.11.09 15:03:57 5: hm485: HM485_GetNewMsgQueue
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000030
2019.11.09 15:03:57 5: hm485: HM485_LAN_Write TX: 138
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000031
2019.11.09 15:03:57 5: SW: fd108a53c8420000181c0000000152000010
2019.11.09 15:03:57 4: hm485: hm485: TX: (138) I[2](0,F,B)(1C) 00000001 -> 42000018 [6] 52(R) 000010
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 138
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 138 Cmd: 114
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Response: (138) FFFF00000001FFFF01000A005802FFFF
2019.11.09 15:03:57 5: hm485: Dispatch: FD138A7258FFFF00000001FFFF01000A005802FFFF
2019.11.09 15:03:57 5: hm485: dispatch �\023�rX��\000\000\000\001��\001\000\n\000X\002��
2019.11.09 15:03:57 5: hm485: HM485_Parse: MsgId: 138
2019.11.09 15:03:57 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: msgData = FFFF00000001FFFF01000A005802FFFF
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 0
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000031
2019.11.09 15:03:57 5: hm485: HM485_LAN_Write TX: 139
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000032
2019.11.09 15:03:57 5: SW: fd108b53c8420000181e0000000152001010
2019.11.09 15:03:57 4: hm485: hm485: TX: (139) I[3](0,F,B)(1E) 00000001 -> 42000018 [6] 52(R) 001010
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 139
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 139 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (139) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD138B7278FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�rx����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 139
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 1
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000032
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 140
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000033
2019.11.09 15:03:58 5: SW: fd108c53c842000018180000000152002010
2019.11.09 15:03:58 4: hm485: hm485: TX: (140) I[0](0,F,B)(18) 00000001 -> 42000018 [6] 52(R) 002010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 140
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 140 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (140) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD138C7218FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�r\030����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 140
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 2
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000033
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 141
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000034
2019.11.09 15:03:58 5: SW: fd108d53c8420000181a0000000152003010
2019.11.09 15:03:58 4: hm485: hm485: TX: (141) I[1](0,F,B)(1A) 00000001 -> 42000018 [6] 52(R) 003010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 141
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 141 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (141) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD138D7238FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�r8����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 141
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 3
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000034
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 142
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000035
2019.11.09 15:03:58 5: SW: fd108e53c8420000181c0000000152004010
2019.11.09 15:03:58 4: hm485: hm485: TX: (142) I[2](0,F,B)(1C) 00000001 -> 42000018 [6] 52(R) 004010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 142
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 142 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (142) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD138E7258FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�rX����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 142
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 4
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000035
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 143
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000036
2019.11.09 15:03:58 5: SW: fd108f53c8420000181e0000000152005010
2019.11.09 15:03:58 4: hm485: hm485: TX: (143) I[3](0,F,B)(1E) 00000001 -> 42000018 [6] 52(R) 005010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 143
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 143 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (143) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD138F7278FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�rx����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 143
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 5
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000036
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 144
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000037
2019.11.09 15:03:58 5: SW: fd109053c842000018180000000152006010
2019.11.09 15:03:58 4: hm485: hm485: TX: (144) I[0](0,F,B)(18) 00000001 -> 42000018 [6] 52(R) 006010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 144
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 144 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (144) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD13907218FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�r\030����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 144
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 6
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000037
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 145
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000038
2019.11.09 15:03:58 5: SW: fd109153c8420000181a0000000152007010
2019.11.09 15:03:58 4: hm485: hm485: TX: (145) I[1](0,F,B)(1A) 00000001 -> 42000018 [6] 52(R) 007010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 145
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 145 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (145) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD13917238FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�r8����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 145
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 7
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000038
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 146
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000039
2019.11.09 15:03:58 5: SW: fd109253c8420000181c0000000152008010
2019.11.09 15:03:58 4: hm485: hm485: TX: (146) I[2](0,F,B)(1C) 00000001 -> 42000018 [6] 52(R) 008010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 146
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 146 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (146) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD13927258FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�rX����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 146
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 8
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000039
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 147
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000003A
2019.11.09 15:03:58 5: SW: fd109353c8420000181e0000000152009010
2019.11.09 15:03:58 4: hm485: hm485: TX: (147) I[3](0,F,B)(1E) 00000001 -> 42000018 [6] 52(R) 009010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 147
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 147 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (147) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD13937278FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�rx����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 147
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 9
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000003A
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 148
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000003B
2019.11.09 15:03:58 5: SW: fd109453c84200001818000000015200a010
2019.11.09 15:03:58 4: hm485: hm485: TX: (148) I[0](0,F,B)(18) 00000001 -> 42000018 [6] 52(R) 00A010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 148
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 148 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (148) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD13947218FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�r\030����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 148
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 10
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000003B
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 149
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000003C
2019.11.09 15:03:58 5: SW: fd109553c8420000181a000000015200b010
2019.11.09 15:03:58 4: hm485: hm485: TX: (149) I[1](0,F,B)(1A) 00000001 -> 42000018 [6] 52(R) 00B010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 149
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 149 Cmd: 114
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Response: (149) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: Dispatch: FD13957238FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: dispatch �\023�r8����������������
2019.11.09 15:03:59 5: hm485: HM485_Parse: MsgId: 149
2019.11.09 15:03:59 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:59 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 11
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000003C
2019.11.09 15:03:59 5: hm485: HM485_LAN_Write TX: 150
2019.11.09 15:03:59 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000003D
2019.11.09 15:03:59 5: SW: fd109653c8420000181c000000015200c010
2019.11.09 15:03:59 4: hm485: hm485: TX: (150) I[2](0,F,B)(1C) 00000001 -> 42000018 [6] 52(R) 00C010
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId: Id: 150
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 150 Cmd: 114
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Response: (150) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: Dispatch: FD13967258FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: dispatch �\023�rX����������������
2019.11.09 15:03:59 5: hm485: HM485_Parse: MsgId: 150
2019.11.09 15:03:59 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:59 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 12
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000003D
2019.11.09 15:03:59 5: hm485: HM485_LAN_Write TX: 151
2019.11.09 15:03:59 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000003E
2019.11.09 15:03:59 5: SW: fd109753c8420000181e000000015200d010
2019.11.09 15:03:59 4: hm485: hm485: TX: (151) I[3](0,F,B)(1E) 00000001 -> 42000018 [6] 52(R) 00D010
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId: Id: 151
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 151 Cmd: 114
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Response: (151) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: Dispatch: FD13977278FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: dispatch �\023�rx����������������
2019.11.09 15:03:59 5: hm485: HM485_Parse: MsgId: 151
2019.11.09 15:03:59 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:59 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 13
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000003E
2019.11.09 15:03:59 5: hm485: HM485_LAN_Write TX: 152
2019.11.09 15:03:59 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000003F
2019.11.09 15:03:59 5: SW: fd109853c84200001818000000015200e010
2019.11.09 15:03:59 4: hm485: hm485: TX: (152) I[0](0,F,B)(18) 00000001 -> 42000018 [6] 52(R) 00E010
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId: Id: 152
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 152 Cmd: 114
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Response: (152) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: Dispatch: FD13987218FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: dispatch �\023�r\030����������������
2019.11.09 15:03:59 5: hm485: HM485_Parse: MsgId: 152
2019.11.09 15:03:59 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:59 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 14
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000003F
2019.11.09 15:03:59 5: hm485: HM485_LAN_Write TX: 153
2019.11.09 15:03:59 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000040
2019.11.09 15:03:59 5: SW: fd109953c8420000181a000000015200f010
2019.11.09 15:03:59 4: hm485: hm485: TX: (153) I[1](0,F,B)(1A) 00000001 -> 42000018 [6] 52(R) 00F010
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId: Id: 153
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 153 Cmd: 114
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Response: (153) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: Dispatch: FD13997238FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: dispatch �\023�r8����������������
2019.11.09 15:03:59 5: hm485: HM485_Parse: MsgId: 153
2019.11.09 15:03:59 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:59 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 15


2019.11.09 20:37:51.743 4: HM485d: Tx: FD03CE6100
2019.11.09 20:38:11.751 4: HM485d: Rx: FD02CF4B
2019.11.09 20:38:11.752 4: HM485d: Tx: FD03CF6100
2019.11.09 20:38:31.760 4: HM485d: Rx: FD02D04B
2019.11.09 20:38:31.760 4: HM485d: Tx: FD03D06100
2019.11.09 20:38:51.768 4: HM485d: Rx: FD02D14B
2019.11.09 20:38:51.768 4: HM485d: Tx: FD03D16100
2019.11.09 20:39:11.776 4: HM485d: Rx: FD02D24B
2019.11.09 20:39:11.777 4: HM485d: Tx: FD03D26100
2019.11.09 20:39:31.787 4: HM485d: Rx: FD02D34B
2019.11.09 20:39:31.788 4: HM485d: Tx: FD03D36100
2019.11.09 20:39:51.795 4: HM485d: Rx: FD02D44B
2019.11.09 20:39:51.795 4: HM485d: Tx: FD03D46100
2019.11.09 20:39:54.350 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14008E {72F6}
2019.11.09 20:39:54.351 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14008E
2019.11.09 20:39:56.827 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140092 {A2CC}
2019.11.09 20:39:56.828 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140092
2019.11.09 20:40:16.851 4: HM485d: Rx: FD02D54B
2019.11.09 20:40:16.852 4: HM485d: Tx: FD03D56100
2019.11.09 20:40:26.997 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140096 {E2C4}
2019.11.09 20:40:26.998 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140096
2019.11.09 20:40:29.490 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14009A {22DC}
2019.11.09 20:40:29.490 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14009A
2019.11.09 20:40:49.506 4: HM485d: Rx: FD02D64B
2019.11.09 20:40:49.507 4: HM485d: Tx: FD03D66100
2019.11.09 20:41:09.512 4: HM485d: Rx: FD02D74B
2019.11.09 20:41:09.513 4: HM485d: Tx: FD03D76100
2019.11.09 20:41:29.519 4: HM485d: Rx: FD02D84B
2019.11.09 20:41:29.519 4: HM485d: Tx: FD03D86100
2019.11.09 20:41:49.528 4: HM485d: Rx: FD02D94B
2019.11.09 20:41:49.529 4: HM485d: Tx: FD03D96100
2019.11.09 20:42:09.534 4: HM485d: Rx: FD02DA4B
2019.11.09 20:42:09.535 4: HM485d: Tx: FD03DA6100
2019.11.09 20:42:29.540 4: HM485d: Rx: FD02DB4B
2019.11.09 20:42:29.541 4: HM485d: Tx: FD03DB6100
2019.11.09 20:42:34.520 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14009E {62D4}
2019.11.09 20:42:34.520 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14009E
2019.11.09 20:42:36.997 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400A2 {92AA}
2019.11.09 20:42:36.998 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400A2
2019.11.09 20:42:57.011 4: HM485d: Rx: FD02DC4B
2019.11.09 20:42:57.012 4: HM485d: Tx: FD03DC6100
2019.11.09 20:43:10.253 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400A6 {D2A2}
2019.11.09 20:43:10.254 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400A6
2019.11.09 20:43:12.732 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400AA {12BA}
2019.11.09 20:43:12.733 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400AA
2019.11.09 20:43:32.747 4: HM485d: Rx: FD02DD4B
2019.11.09 20:43:32.748 4: HM485d: Tx: FD03DD6100
2019.11.09 20:43:52.756 4: HM485d: Rx: FD02DE4B
2019.11.09 20:43:52.757 4: HM485d: Tx: FD03DE6100
2019.11.09 20:44:12.766 4: HM485d: Rx: FD02DF4B
2019.11.09 20:44:12.766 4: HM485d: Tx: FD03DF6100
2019.11.09 20:44:23.730 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400AE {52B2}
2019.11.09 20:44:23.731 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400AE
2019.11.09 20:44:26.207 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400B2 {8288}
2019.11.09 20:44:26.208 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400B2
2019.11.09 20:44:40.047 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400B6 {C280}
2019.11.09 20:44:40.048 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400B6
2019.11.09 20:44:43.212 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400BA {0298}
2019.11.09 20:44:43.212 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400BA
2019.11.09 20:45:03.227 4: HM485d: Rx: FD02E04B
2019.11.09 20:45:03.228 4: HM485d: Tx: FD03E06100
2019.11.09 20:45:23.237 4: HM485d: Rx: FD02E14B
2019.11.09 20:45:23.238 4: HM485d: Tx: FD03E16100
2019.11.09 20:45:39.252 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400BE {4290}
2019.11.09 20:45:39.253 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400BE
2019.11.09 20:45:41.729 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400C2 {F266}
2019.11.09 20:45:41.730 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400C2
2019.11.09 20:45:49.591 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400C6 {B26E}
2019.11.09 20:45:49.591 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400C6
2019.11.09 20:45:52.245 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400CA {7276}
2019.11.09 20:45:52.246 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400CA
2019.11.09 20:46:03.780 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400CE {327E}
2019.11.09 20:46:03.780 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400CE
2019.11.09 20:46:06.259 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400D2 {E244}
2019.11.09 20:46:06.260 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400D2
2019.11.09 20:46:18.019 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400D6 {A24C}
2019.11.09 20:46:18.020 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400D6
2019.11.09 20:46:20.512 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400DA {6254}
2019.11.09 20:46:20.513 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400DA
2019.11.09 20:46:30.770 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400DE {225C}
2019.11.09 20:46:30.771 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400DE
2019.11.09 20:46:36.332 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400E2 {D222}
2019.11.09 20:46:36.333 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400E2
2019.11.09 20:46:41.877 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400E6 {922A}
2019.11.09 20:46:41.885 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400E6
2019.11.09 20:46:45.090 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400EA {5232}
2019.11.09 20:46:45.090 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400EA
2019.11.09 20:47:05.103 4: HM485d: Rx: FD02E24B
2019.11.09 20:47:05.104 4: HM485d: Tx: FD03E26100
2019.11.09 20:47:25.110 4: HM485d: Rx: FD02E34B
2019.11.09 20:47:25.111 4: HM485d: Tx: FD03E36100
2019.11.09 20:47:45.129 4: HM485d: Rx: FD02E44B
2019.11.09 20:47:45.130 4: HM485d: Tx: FD03E46100
2019.11.09 20:47:45.315 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400EE {123A}
2019.11.09 20:47:45.316 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400EE
2019.11.09 20:47:47.794 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400F2 {C200}
2019.11.09 20:47:47.795 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400F2
2019.11.09 20:48:07.808 4: HM485d: Rx: FD02E54B
2019.11.09 20:48:07.809 4: HM485d: Tx: FD03E56100
2019.11.09 20:48:14.354 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400F6 {8208}
2019.11.09 20:48:14.355 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400F6
2019.11.09 20:48:16.832 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400FA {4210}
2019.11.09 20:48:16.833 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400FA
2019.11.09 20:48:36.847 4: HM485d: Rx: FD02E64B
2019.11.09 20:48:36.848 4: HM485d: Tx: FD03E66100
2019.11.09 20:48:56.856 4: HM485d: Rx: FD02E74B
2019.11.09 20:48:56.857 4: HM485d: Tx: FD03E76100
2019.11.09 20:49:13.528 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400FE {0218}
2019.11.09 20:49:13.528 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400FE
2019.11.09 20:49:16.500 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140002 {33FE}
2019.11.09 20:49:16.501 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140002
2019.11.09 20:49:36.515 4: HM485d: Rx: FD02E84B
2019.11.09 20:49:36.516 4: HM485d: Tx: FD03E86100
2019.11.09 20:49:45.394 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140006 {73F6}
2019.11.09 20:49:45.395 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140006
2019.11.09 20:49:48.031 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14000A {B3EE}
2019.11.09 20:49:48.032 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14000A
2019.11.09 20:49:50.235 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14000E {F3E6}
2019.11.09 20:49:50.236 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14000E
2019.11.09 20:49:52.714 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140012 {23DC}
2019.11.09 20:49:52.714 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140012
2019.11.09 20:50:02.094 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140016 {63D4}
2019.11.09 20:50:02.094 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140016
2019.11.09 20:50:04.586 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14001A {A3CC}
2019.11.09 20:50:04.587 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14001A
2019.11.09 20:50:06.775 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14001E {E3C4}
2019.11.09 20:50:06.776 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14001E
2019.11.09 20:50:09.269 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140022 {13BA}
2019.11.09 20:50:09.270 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140022
2019.11.09 20:50:12.991 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140026 {53B2}
2019.11.09 20:50:12.992 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140026
2019.11.09 20:50:16.171 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14002A {93AA}
2019.11.09 20:50:16.172 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14002A
2019.11.09 20:50:36.187 4: HM485d: Rx: FD02E94B
2019.11.09 20:50:36.187 4: HM485d: Tx: FD03E96100
2019.11.09 20:50:38.959 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14002E {D3A2}
2019.11.09 20:50:38.960 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14002E
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 09 November 2019, 21:32:21
Dann ist ja erstmal alles ok, oder?
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 10 November 2019, 00:44:08
Hi,

HBW-SC-10-Dim-6  hat mit der sendewarteschlange etwas Probleme. Ich hatte da auch komische Effekte, bin dran...  :D
Bei dir scheint das device aber immer wieder neu gestartet zu sein... Da kann FHEM nichts machen, geschweige die konfig zu lesen.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 11 November 2019, 21:00:55
Hallo,

habe, neben ein paar anderen Änderungen, eine Korrektur für die Sendewarteschlange (sendBuffer) in mein repository hochgeladen: https://github.com/loetmeister/HBWired
Beim Kopieren des Frames in den Sendewarteschlange und wieder zurück in den Sendespeicher hatte ich jeweils ein Byte zu viel kopiert...   :-[
In HBWKey hatte ich auch vergessen die wiederholten long press von der Warteschlange auszuklammern.
Beides wird in HBW-SC-10-Dim-6 genutzt.


Generell müsste ich noch alle Devices mit Nutzung des sendBuffer (d.h. alle die Tastereingänge haben/sendKeyEvent nutzen) etwas mehr testen... :)
Im Moment bin ich auch noch etwas unschlüssig, ob ich die Sendewarteschlange immer nutze und Ausnahmen explizit setzten muss (so ist es aktuell) oder genau andersherum machen soll.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 12 November 2019, 12:25:16
Zitat von: loetmeister am 11 November 2019, 21:00:55
Im Moment bin ich auch noch etwas unschlüssig, ob ich die Sendewarteschlange immer nutze und Ausnahmen explizit setzten muss (so ist es aktuell) oder genau andersherum machen soll.
Ich denke, dass das erstmal egal ist, so lange man es im Coding einfach ändern kann.
Bekomme ich mal wieder ein pull-Request oder willst Du das erstmal etwas besser testen?
...oder beschränkt sich das auf "Deine" Devices?
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 12 November 2019, 18:13:34
Hi Thorsten,

Ich würde noch etwas testen bevor ich den pull request stelle.  :)
Vielleicht auch den Code noch etwas aufräumen oder versuchen in eigene Header Dateien zu verschieben, damit er nicht unnötig Speicher belegt.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 20 Dezember 2019, 17:26:47
Hi,

beim testen ist mir aufgefallen, das ich bei ein paar Geräten, bei denen ich den Speicher des Arduino relativ start beanspruche, mit der Sendewarteschlange wohl einen Überlauf erzeuge... Das jedenfalls ist meine Annahme.
Beim Start habe ich, z.B. 373 byte frei. In der Send Frame Funktion nur noch 328.... bis runter auf 288.
B: 2A 373
sFrame: 2A 328
processFrame: 335


Ich hatte zum testen einige der Variablen und Funktionen "static" definiert... das scheint aber das Verhalten nicht grundsätzlich zu verbessern sondern nur das Problem auf andere Funktionen zu verschieben.

Würde daher einen anderen Ansatz versuchen - ohne Warteschlange, dafür die Rückgabewerte der sendKeyEvent (für linkSender & Device) verbessern, so das im Kanal ein Wiederholung des Senden versucht werden kann. Bei den KeyEvents der Peerings, würde ich alle Frames hinter einander senden, wenn beim ersten der Bus frei war - die restlichen ohne wieder auf einen freien Bus zu warten (und immer nur ein Versuch retry = 1)
Das dürfte auch die Verzögerung bei mehreren peerings reduzieren...

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 21 Dezember 2019, 20:50:30
Zitat von: loetmeister am 20 Dezember 2019, 17:26:47Bei den KeyEvents der Peerings, würde ich alle Frames hinter einander senden, wenn beim ersten der Bus frei war - die restlichen ohne wieder auf einen freien Bus zu warten (und immer nur ein Versuch retry = 1)
Vielleicht verstehe ich da was falsch, aber musst Du nicht erstmal auf das ACK warten? Ansonsten müsste man sich ja merken, auf welche Bestätigungen wir noch warten.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 21 Dezember 2019, 23:12:54
Hi Thorsten,

ja, auf die ACKs muss ich warten... es wird ja HBWDevice::sendFrame genutzt, dort hänge ich dann in der Schleife, bis das ACK gekommen ist, oder einen timeout gab. An sendFrame() hatte ich nur geändert, das ich beim Aufruf die Anzahl der Sendeversuche mitgeben kann, sonst ist es wie gehabt.
Die peerings müssten nacheinander abgearbeitet werden, aber ob das nun im linkSender oder in meiner Sendewarteschlange passiert... müsste relativ egal sein, außer das letztes speicherintensiver ist.
Rückgabewert, müsste dann vom Broadcast sein (falls es keine peerings gibt), oder das vom letzten peering - du hattest schon mal so einen Vorschlag gemacht...  :D

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 22 Dezember 2019, 20:16:07
Ah jetzt ja...
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 05 Januar 2020, 00:17:49
Hallo,

wie erwähnt hat mir die Sendewarteschlange zu viel RAM gefressen. Daher habe ich es wieder ausgebaut.  :-\ Um das Problem mehrerer aufeinander folgender Peerings aber dennoch zu lösen habe ich ein paar kleine Änderungen in der sendKeyEvent von HBWDevice und HBWLinkSender gemacht. So kann der Kanal nun (etwas besser) feststellen ob etwas gesendet wurde oder nicht und darauf reagieren... oder auch nicht.. :) Z.b. bei einem Taster Eingang einfach warten das man den Taster noch mal betätigt.

Wenn jemand HBW-Sen-Key-12 oder ein Device nutzt, das HBWKey.cpp verwendet (edit: mit peerings/direktverknüpfungen), wäre es klasse die neue Version zu testen!  8)


https://github.com/ThorstenPferdekaemper/HBWired/pull/14

@Thorsten, danke fürs feedback. Ich stell den pull request von "draft" auf echt um... ;-)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 06 Januar 2020, 22:38:01
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 06 Januar 2020, 22:49:20
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 14 Januar 2020, 23:46:15
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 16 Januar 2020, 22:10:36
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Langerrenner am 16 Januar 2020, 22:51:35
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 17 Januar 2020, 00:38:01
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 17 Januar 2020, 20:26:06
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Langerrenner am 17 Januar 2020, 23:00:40
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Langerrenner am 24 Januar 2020, 19:39:00
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 24 Januar 2020, 20:17:50
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Langerrenner am 26 Januar 2020, 21:07:27
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 29 Januar 2020, 23:41:02
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 31 Januar 2020, 21:44:39
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
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 02 Februar 2020, 23:51:49
Danke!  8)

Ich habe mal einen Pull Request gestellt. https://github.com/ThorstenPferdekaemper/HBWired/pull/15
In der Hauptsache wäre drin:
Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Zeitisen am 13 März 2020, 21:58:52
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.


Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 14 März 2020, 19:46:51
Zitat von: Zeitisen am 13 März 2020, 21:58:52
Ist das Protokoll IP Wired dokumentiert?
Meines Wissens nach nicht.
Von eq3 habe ich bisher nur das hier gefunden, dass es mit IPv6 funktioniert und dass es deshalb "kompatibel" ist. (Siehe hier https://www.eq-3.de/Downloads/eq3/download%20bereich/produktbroschueren/94487_DE_HmIP_Wired_Broschuere_B2B_launch_062019.pdf
...auf Seite 4 unter "Kompatibel".)
Allerdings wüsste ich jetzt nicht so recht, was ich mit dieser Information anfangen sollte. Das ganze ist ja auch noch verschlüsselt und "authentisiert". Ich befürchte, dass man da nicht mitlesen kann und daher auch kaum eine Chance hat, das Protokoll zu verstehen.
D.h. es ist meiner Meinung nach im Endeffekt ein proprietäres Protokoll, bei dem man auf einen einzelnen Hersteller angewiesen ist. Damit fällt das ganze für mich flach.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 10 April 2020, 22:11:02
Zitat von: holzwurm83 am 09 November 2019, 20:48:13
Hallo Thorsten,

ich hatte mittlerweile alle ein und Ausgänge einmal gegen GND geschalten und jetzt wurde der auch im Fhem angelegt.

Hier ist der Fhem LOG:
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000002C
2019.11.09 15:03:57 5: SW: fd0d8553c8420000181a000000016e
2019.11.09 15:03:57 4: hm485: hm485: TX: (133) I[1](0,F,B)(1A) 00000001 -> 42000018 [3] 6E(n)
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 133
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 133 Cmd: 114
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Response: (133) 48425737323936323830
2019.11.09 15:03:57 5: hm485: Dispatch: FD0D85723848425737323936323830
2019.11.09 15:03:57 5: hm485: dispatch �\r�r8HBW7296280
2019.11.09 15:03:57 5: hm485: HM485_Parse: MsgId: 133
2019.11.09 15:03:57 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: msgData = 48425737323936323830
2019.11.09 15:03:57 4: hm485: Device 42000018 not defined yet. We need the firmware version for autocreate
2019.11.09 15:03:57 5: hm485: HM485_QueueCommand76
2019.11.09 15:03:57 5: hm485: HM485_QueueStart: Num: 1
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess: Entries: 0 Index: 0
2019.11.09 15:03:57 5: hm485: HM485_QueueProcessStep: HASH(0x26ba400)
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000002C
2019.11.09 15:03:57 5: hm485: HM485_LAN_Write TX: 134
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000002D
2019.11.09 15:03:57 5: SW: fd0d8653c8420000181c0000000176
2019.11.09 15:03:57 4: hm485: hm485: TX: (134) I[2](0,F,B)(1C) 00000001 -> 42000018 [3] 76(v)
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 134
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 134 Cmd: 114
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Response: (134) 0005
2019.11.09 15:03:57 5: hm485: Dispatch: FD058672580005
2019.11.09 15:03:57 5: hm485: dispatch �\005�rX\000\005
2019.11.09 15:03:57 5: hm485: HM485_Parse: MsgId: 134
2019.11.09 15:03:57 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: msgData = 0005
2019.11.09 15:03:57 2: autocreate: define HBW_SC_10_Dim_6_HBW7296280 HM485 42000018 hm485
2019.11.09 15:03:57 2: hm485: Assigned 42000018 as HBW_SC_10_Dim_6_HBW7296280
2019.11.09 15:03:57 2: autocreate: define FileLog_HBW_SC_10_Dim_6_HBW7296280 FileLog ./log/HBW_SC_10_Dim_6_HBW7296280-%Y.log HBW_SC_10_Dim_6_HBW7296280
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess: Entries: 0 Index: 0
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000002D
2019.11.09 15:03:57 5: hm485: HM485_GetNewMsgQueue
2019.11.09 15:03:57 3: hm485: Initialisierung von Modul 42000018
2019.11.09 15:03:57 5: hm485: HM485_LAN_Write TX: 135
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000002E
2019.11.09 15:03:57 5: SW: fd0d8753c8420000181e0000000168
2019.11.09 15:03:57 4: hm485: hm485: TX: (135) I[3](0,F,B)(1E) 00000001 -> 42000018 [3] 68(h)
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 135
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 135 Cmd: 114
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Response: (135) 9601
2019.11.09 15:03:57 5: hm485: Dispatch: FD058772789601
2019.11.09 15:03:57 5: hm485: dispatch �\005�rx�\001
2019.11.09 15:03:57 5: hm485: HM485_Parse: MsgId: 135
2019.11.09 15:03:57 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: msgData = 9601
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: deviceKey =  requestType = 68 requestData =  msgData = 9601
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess: Entries: 2 Index: 0
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000002E
2019.11.09 15:03:57 5: hm485: HM485_LAN_Write TX: 136
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000002F
2019.11.09 15:03:57 5: SW: fd0d8853c84200001818000000016e
2019.11.09 15:03:57 4: hm485: hm485: TX: (136) I[0](0,F,B)(18) 00000001 -> 42000018 [3] 6E(n)
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 136
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 136 Cmd: 114
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Response: (136) 48425737323936323830
2019.11.09 15:03:57 5: hm485: Dispatch: FD0D88721848425737323936323830
2019.11.09 15:03:57 5: hm485: dispatch �\r�r\030HBW7296280
2019.11.09 15:03:57 5: hm485: HM485_Parse: MsgId: 136
2019.11.09 15:03:57 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: msgData = 48425737323936323830
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: deviceKey =  requestType = 6E requestData =  msgData = 48425737323936323830
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess: Entries: 2 Index: 1
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000002F
2019.11.09 15:03:57 5: hm485: HM485_LAN_Write TX: 137
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000030
2019.11.09 15:03:57 5: SW: fd0d8953c8420000181a0000000176
2019.11.09 15:03:57 4: hm485: hm485: TX: (137) I[1](0,F,B)(1A) 00000001 -> 42000018 [3] 76(v)
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 137
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 137 Cmd: 114
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Response: (137) 0005
2019.11.09 15:03:57 5: hm485: Dispatch: FD058972380005
2019.11.09 15:03:57 5: hm485: dispatch �\005�r8\000\005
2019.11.09 15:03:57 5: hm485: HM485_Parse: MsgId: 137
2019.11.09 15:03:57 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: msgData = 0005
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: deviceKey =  requestType = 76 requestData =  msgData = 0005
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess: Entries: 2 Index: 2
2019.11.09 15:03:57 3: HBW_SC_10_Dim_6_HBW7296280: Request config for device 42000018
2019.11.09 15:03:57 3: HBW_SC_10_Dim_6_HBW7296280: Lese Eeprom 42000018
2019.11.09 15:03:57 5: hm485: HM485_GetNewMsgQueue
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000030
2019.11.09 15:03:57 5: hm485: HM485_LAN_Write TX: 138
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000031
2019.11.09 15:03:57 5: SW: fd108a53c8420000181c0000000152000010
2019.11.09 15:03:57 4: hm485: hm485: TX: (138) I[2](0,F,B)(1C) 00000001 -> 42000018 [6] 52(R) 000010
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 138
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 138 Cmd: 114
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Response: (138) FFFF00000001FFFF01000A005802FFFF
2019.11.09 15:03:57 5: hm485: Dispatch: FD138A7258FFFF00000001FFFF01000A005802FFFF
2019.11.09 15:03:57 5: hm485: dispatch �\023�rX��\000\000\000\001��\001\000\n\000X\002��
2019.11.09 15:03:57 5: hm485: HM485_Parse: MsgId: 138
2019.11.09 15:03:57 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:57 5: hm485: HM485_ProcessResponse: msgData = FFFF00000001FFFF01000A005802FFFF
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:57 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 0
2019.11.09 15:03:57 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000031
2019.11.09 15:03:57 5: hm485: HM485_LAN_Write TX: 139
2019.11.09 15:03:57 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000032
2019.11.09 15:03:57 5: SW: fd108b53c8420000181e0000000152001010
2019.11.09 15:03:57 4: hm485: hm485: TX: (139) I[3](0,F,B)(1E) 00000001 -> 42000018 [6] 52(R) 001010
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:57 5: hm485: HM485_QueueSetRequestId: Id: 139
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 139 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (139) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD138B7278FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�rx����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 139
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 1
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000032
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 140
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000033
2019.11.09 15:03:58 5: SW: fd108c53c842000018180000000152002010
2019.11.09 15:03:58 4: hm485: hm485: TX: (140) I[0](0,F,B)(18) 00000001 -> 42000018 [6] 52(R) 002010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 140
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 140 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (140) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD138C7218FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�r\030����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 140
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 2
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000033
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 141
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000034
2019.11.09 15:03:58 5: SW: fd108d53c8420000181a0000000152003010
2019.11.09 15:03:58 4: hm485: hm485: TX: (141) I[1](0,F,B)(1A) 00000001 -> 42000018 [6] 52(R) 003010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 141
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 141 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (141) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD138D7238FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�r8����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 141
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 3
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000034
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 142
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000035
2019.11.09 15:03:58 5: SW: fd108e53c8420000181c0000000152004010
2019.11.09 15:03:58 4: hm485: hm485: TX: (142) I[2](0,F,B)(1C) 00000001 -> 42000018 [6] 52(R) 004010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 142
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 142 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (142) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD138E7258FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�rX����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 142
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 4
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000035
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 143
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000036
2019.11.09 15:03:58 5: SW: fd108f53c8420000181e0000000152005010
2019.11.09 15:03:58 4: hm485: hm485: TX: (143) I[3](0,F,B)(1E) 00000001 -> 42000018 [6] 52(R) 005010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 143
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 143 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (143) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD138F7278FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�rx����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 143
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 5
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000036
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 144
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000037
2019.11.09 15:03:58 5: SW: fd109053c842000018180000000152006010
2019.11.09 15:03:58 4: hm485: hm485: TX: (144) I[0](0,F,B)(18) 00000001 -> 42000018 [6] 52(R) 006010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 144
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 144 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (144) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD13907218FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�r\030����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 144
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 6
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000037
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 145
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000038
2019.11.09 15:03:58 5: SW: fd109153c8420000181a0000000152007010
2019.11.09 15:03:58 4: hm485: hm485: TX: (145) I[1](0,F,B)(1A) 00000001 -> 42000018 [6] 52(R) 007010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 145
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 145 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (145) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD13917238FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�r8����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 145
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 7
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000038
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 146
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000039
2019.11.09 15:03:58 5: SW: fd109253c8420000181c0000000152008010
2019.11.09 15:03:58 4: hm485: hm485: TX: (146) I[2](0,F,B)(1C) 00000001 -> 42000018 [6] 52(R) 008010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 146
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 146 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (146) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD13927258FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�rX����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 146
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 8
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 00000039
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 147
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000003A
2019.11.09 15:03:58 5: SW: fd109353c8420000181e0000000152009010
2019.11.09 15:03:58 4: hm485: hm485: TX: (147) I[3](0,F,B)(1E) 00000001 -> 42000018 [6] 52(R) 009010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 147
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 147 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (147) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD13937278FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�rx����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 147
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 9
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000003A
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 148
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000003B
2019.11.09 15:03:58 5: SW: fd109453c84200001818000000015200a010
2019.11.09 15:03:58 4: hm485: hm485: TX: (148) I[0](0,F,B)(18) 00000001 -> 42000018 [6] 52(R) 00A010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 148
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 148 Cmd: 114
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Response: (148) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: Dispatch: FD13947218FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: dispatch �\023�r\030����������������
2019.11.09 15:03:58 5: hm485: HM485_Parse: MsgId: 148
2019.11.09 15:03:58 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:58 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:58 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 10
2019.11.09 15:03:58 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000003B
2019.11.09 15:03:58 5: hm485: HM485_LAN_Write TX: 149
2019.11.09 15:03:58 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000003C
2019.11.09 15:03:58 5: SW: fd109553c8420000181a000000015200b010
2019.11.09 15:03:58 4: hm485: hm485: TX: (149) I[1](0,F,B)(1A) 00000001 -> 42000018 [6] 52(R) 00B010
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:58 5: hm485: HM485_QueueSetRequestId: Id: 149
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 149 Cmd: 114
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Response: (149) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: Dispatch: FD13957238FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: dispatch �\023�r8����������������
2019.11.09 15:03:59 5: hm485: HM485_Parse: MsgId: 149
2019.11.09 15:03:59 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:59 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 11
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000003C
2019.11.09 15:03:59 5: hm485: HM485_LAN_Write TX: 150
2019.11.09 15:03:59 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000003D
2019.11.09 15:03:59 5: SW: fd109653c8420000181c000000015200c010
2019.11.09 15:03:59 4: hm485: hm485: TX: (150) I[2](0,F,B)(1C) 00000001 -> 42000018 [6] 52(R) 00C010
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId: Id: 150
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 150 Cmd: 114
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Response: (150) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: Dispatch: FD13967258FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: dispatch �\023�rX����������������
2019.11.09 15:03:59 5: hm485: HM485_Parse: MsgId: 150
2019.11.09 15:03:59 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:59 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 12
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000003D
2019.11.09 15:03:59 5: hm485: HM485_LAN_Write TX: 151
2019.11.09 15:03:59 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000003E
2019.11.09 15:03:59 5: SW: fd109753c8420000181e000000015200d010
2019.11.09 15:03:59 4: hm485: hm485: TX: (151) I[3](0,F,B)(1E) 00000001 -> 42000018 [6] 52(R) 00D010
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId: Id: 151
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 151 Cmd: 114
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Response: (151) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: Dispatch: FD13977278FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: dispatch �\023�rx����������������
2019.11.09 15:03:59 5: hm485: HM485_Parse: MsgId: 151
2019.11.09 15:03:59 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:59 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 13
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000003E
2019.11.09 15:03:59 5: hm485: HM485_LAN_Write TX: 152
2019.11.09 15:03:59 5: hm485: HM485_LAN_SendQueueNextItem: QID: 0000003F
2019.11.09 15:03:59 5: SW: fd109853c84200001818000000015200e010
2019.11.09 15:03:59 4: hm485: hm485: TX: (152) I[0](0,F,B)(18) 00000001 -> 42000018 [6] 52(R) 00E010
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId: Id: 152
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 152 Cmd: 114
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Response: (152) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: Dispatch: FD13987218FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: dispatch �\023�r\030����������������
2019.11.09 15:03:59 5: hm485: HM485_Parse: MsgId: 152
2019.11.09 15:03:59 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:59 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 14
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Removing Queue 0000003F
2019.11.09 15:03:59 5: hm485: HM485_LAN_Write TX: 153
2019.11.09 15:03:59 5: hm485: HM485_LAN_SendQueueNextItem: QID: 00000040
2019.11.09 15:03:59 5: SW: fd109953c8420000181a000000015200f010
2019.11.09 15:03:59 4: hm485: hm485: TX: (153) I[1](0,F,B)(1A) 00000001 -> 42000018 [6] 52(R) 00F010
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId start
2019.11.09 15:03:59 5: hm485: HM485_QueueSetRequestId: Id: 153
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 153 Cmd: 114
2019.11.09 15:03:59 5: hm485: HM485_LAN_parseIncommingCommand: Response: (153) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: Dispatch: FD13997238FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: dispatch �\023�r8����������������
2019.11.09 15:03:59 5: hm485: HM485_Parse: MsgId: 153
2019.11.09 15:03:59 5: hm485: HM485_Parse: ProcessResponse
2019.11.09 15:03:59 5: hm485: HM485_ProcessResponse: msgData = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess called
2019.11.09 15:03:59 5: hm485: HM485_QueueStepSuccess: Entries: 63 Index: 15


2019.11.09 20:37:51.743 4: HM485d: Tx: FD03CE6100
2019.11.09 20:38:11.751 4: HM485d: Rx: FD02CF4B
2019.11.09 20:38:11.752 4: HM485d: Tx: FD03CF6100
2019.11.09 20:38:31.760 4: HM485d: Rx: FD02D04B
2019.11.09 20:38:31.760 4: HM485d: Tx: FD03D06100
2019.11.09 20:38:51.768 4: HM485d: Rx: FD02D14B
2019.11.09 20:38:51.768 4: HM485d: Tx: FD03D16100
2019.11.09 20:39:11.776 4: HM485d: Rx: FD02D24B
2019.11.09 20:39:11.777 4: HM485d: Tx: FD03D26100
2019.11.09 20:39:31.787 4: HM485d: Rx: FD02D34B
2019.11.09 20:39:31.788 4: HM485d: Tx: FD03D36100
2019.11.09 20:39:51.795 4: HM485d: Rx: FD02D44B
2019.11.09 20:39:51.795 4: HM485d: Tx: FD03D46100
2019.11.09 20:39:54.350 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14008E {72F6}
2019.11.09 20:39:54.351 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14008E
2019.11.09 20:39:56.827 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140092 {A2CC}
2019.11.09 20:39:56.828 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140092
2019.11.09 20:40:16.851 4: HM485d: Rx: FD02D54B
2019.11.09 20:40:16.852 4: HM485d: Tx: FD03D56100
2019.11.09 20:40:26.997 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140096 {E2C4}
2019.11.09 20:40:26.998 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140096
2019.11.09 20:40:29.490 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14009A {22DC}
2019.11.09 20:40:29.490 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14009A
2019.11.09 20:40:49.506 4: HM485d: Rx: FD02D64B
2019.11.09 20:40:49.507 4: HM485d: Tx: FD03D66100
2019.11.09 20:41:09.512 4: HM485d: Rx: FD02D74B
2019.11.09 20:41:09.513 4: HM485d: Tx: FD03D76100
2019.11.09 20:41:29.519 4: HM485d: Rx: FD02D84B
2019.11.09 20:41:29.519 4: HM485d: Tx: FD03D86100
2019.11.09 20:41:49.528 4: HM485d: Rx: FD02D94B
2019.11.09 20:41:49.529 4: HM485d: Tx: FD03D96100
2019.11.09 20:42:09.534 4: HM485d: Rx: FD02DA4B
2019.11.09 20:42:09.535 4: HM485d: Tx: FD03DA6100
2019.11.09 20:42:29.540 4: HM485d: Rx: FD02DB4B
2019.11.09 20:42:29.541 4: HM485d: Tx: FD03DB6100
2019.11.09 20:42:34.520 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14009E {62D4}
2019.11.09 20:42:34.520 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14009E
2019.11.09 20:42:36.997 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400A2 {92AA}
2019.11.09 20:42:36.998 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400A2
2019.11.09 20:42:57.011 4: HM485d: Rx: FD02DC4B
2019.11.09 20:42:57.012 4: HM485d: Tx: FD03DC6100
2019.11.09 20:43:10.253 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400A6 {D2A2}
2019.11.09 20:43:10.254 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400A6
2019.11.09 20:43:12.732 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400AA {12BA}
2019.11.09 20:43:12.733 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400AA
2019.11.09 20:43:32.747 4: HM485d: Rx: FD02DD4B
2019.11.09 20:43:32.748 4: HM485d: Tx: FD03DD6100
2019.11.09 20:43:52.756 4: HM485d: Rx: FD02DE4B
2019.11.09 20:43:52.757 4: HM485d: Tx: FD03DE6100
2019.11.09 20:44:12.766 4: HM485d: Rx: FD02DF4B
2019.11.09 20:44:12.766 4: HM485d: Tx: FD03DF6100
2019.11.09 20:44:23.730 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400AE {52B2}
2019.11.09 20:44:23.731 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400AE
2019.11.09 20:44:26.207 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400B2 {8288}
2019.11.09 20:44:26.208 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400B2
2019.11.09 20:44:40.047 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400B6 {C280}
2019.11.09 20:44:40.048 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400B6
2019.11.09 20:44:43.212 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400BA {0298}
2019.11.09 20:44:43.212 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400BA
2019.11.09 20:45:03.227 4: HM485d: Rx: FD02E04B
2019.11.09 20:45:03.228 4: HM485d: Tx: FD03E06100
2019.11.09 20:45:23.237 4: HM485d: Rx: FD02E14B
2019.11.09 20:45:23.238 4: HM485d: Tx: FD03E16100
2019.11.09 20:45:39.252 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400BE {4290}
2019.11.09 20:45:39.253 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400BE
2019.11.09 20:45:41.729 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400C2 {F266}
2019.11.09 20:45:41.730 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400C2
2019.11.09 20:45:49.591 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400C6 {B26E}
2019.11.09 20:45:49.591 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400C6
2019.11.09 20:45:52.245 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400CA {7276}
2019.11.09 20:45:52.246 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400CA
2019.11.09 20:46:03.780 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400CE {327E}
2019.11.09 20:46:03.780 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400CE
2019.11.09 20:46:06.259 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400D2 {E244}
2019.11.09 20:46:06.260 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400D2
2019.11.09 20:46:18.019 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400D6 {A24C}
2019.11.09 20:46:18.020 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400D6
2019.11.09 20:46:20.512 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400DA {6254}
2019.11.09 20:46:20.513 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400DA
2019.11.09 20:46:30.770 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400DE {225C}
2019.11.09 20:46:30.771 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400DE
2019.11.09 20:46:36.332 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400E2 {D222}
2019.11.09 20:46:36.333 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400E2
2019.11.09 20:46:41.877 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400E6 {922A}
2019.11.09 20:46:41.885 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400E6
2019.11.09 20:46:45.090 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400EA {5232}
2019.11.09 20:46:45.090 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400EA
2019.11.09 20:47:05.103 4: HM485d: Rx: FD02E24B
2019.11.09 20:47:05.104 4: HM485d: Tx: FD03E26100
2019.11.09 20:47:25.110 4: HM485d: Rx: FD02E34B
2019.11.09 20:47:25.111 4: HM485d: Tx: FD03E36100
2019.11.09 20:47:45.129 4: HM485d: Rx: FD02E44B
2019.11.09 20:47:45.130 4: HM485d: Tx: FD03E46100
2019.11.09 20:47:45.315 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400EE {123A}
2019.11.09 20:47:45.316 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400EE
2019.11.09 20:47:47.794 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400F2 {C200}
2019.11.09 20:47:47.795 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400F2
2019.11.09 20:48:07.808 4: HM485d: Rx: FD02E54B
2019.11.09 20:48:07.809 4: HM485d: Tx: FD03E56100
2019.11.09 20:48:14.354 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400F6 {8208}
2019.11.09 20:48:14.355 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400F6
2019.11.09 20:48:16.832 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400FA {4210}
2019.11.09 20:48:16.833 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400FA
2019.11.09 20:48:36.847 4: HM485d: Rx: FD02E64B
2019.11.09 20:48:36.848 4: HM485d: Tx: FD03E66100
2019.11.09 20:48:56.856 4: HM485d: Rx: FD02E74B
2019.11.09 20:48:56.857 4: HM485d: Tx: FD03E76100
2019.11.09 20:49:13.528 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 1400FE {0218}
2019.11.09 20:49:13.528 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B1400FE
2019.11.09 20:49:16.500 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140002 {33FE}
2019.11.09 20:49:16.501 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140002
2019.11.09 20:49:36.515 4: HM485d: Rx: FD02E84B
2019.11.09 20:49:36.516 4: HM485d: Tx: FD03E86100
2019.11.09 20:49:45.394 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140006 {73F6}
2019.11.09 20:49:45.395 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140006
2019.11.09 20:49:48.031 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14000A {B3EE}
2019.11.09 20:49:48.032 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14000A
2019.11.09 20:49:50.235 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14000E {F3E6}
2019.11.09 20:49:50.236 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14000E
2019.11.09 20:49:52.714 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140012 {23DC}
2019.11.09 20:49:52.714 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140012
2019.11.09 20:50:02.094 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140016 {63D4}
2019.11.09 20:50:02.094 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140016
2019.11.09 20:50:04.586 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14001A {A3CC}
2019.11.09 20:50:04.587 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14001A
2019.11.09 20:50:06.775 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14001E {E3C4}
2019.11.09 20:50:06.776 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14001E
2019.11.09 20:50:09.269 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140022 {13BA}
2019.11.09 20:50:09.270 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140022
2019.11.09 20:50:12.991 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 140026 {53B2}
2019.11.09 20:50:12.992 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B140026
2019.11.09 20:50:16.171 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14002A {93AA}
2019.11.09 20:50:16.172 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14002A
2019.11.09 20:50:36.187 4: HM485d: Rx: FD02E94B
2019.11.09 20:50:36.187 4: HM485d: Tx: FD03E96100
2019.11.09 20:50:38.959 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 14002E {D3A2}
2019.11.09 20:50:38.960 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B14002E


Hallo zusammen,

ich mir mal erlaubt zu dem Modul hier

https://forum.fhem.de/index.php/topic,110058.msg1040737.html#msg1040737 (https://forum.fhem.de/index.php/topic,110058.msg1040737.html#msg1040737)

einen eigenen Thread auf zu machen.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 28 April 2020, 18:32:07
Hallo zusammen,

ich wollte mir mehrer Nano´s mit Analogen eingängigen, min einen Eingang, zusammen bauen um an diesem Bodenfeuchte Sensoren anschließen zu können. Allerdings habe ich dazu nichts gefunden, bzw. haben die Module keine Analogen Eingänge, die auf GitHub stehen.

Hat dafür einer schon mal einen Sketch erstellt, oder kann mir dabei helfen?



Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 28 April 2020, 23:30:02
Hi,

schau dir HBWAnalogIn.h mal an. Das sollte sich als Vorlage nutzen lassen... https://github.com/ThorstenPferdekaemper/HBWired/tree/master/libraries/src
In HBW-LC-BL-4 und HBW-LC-BL-8 nutze ich es zur Messung der Busspannung.

Ein Arduino Nano hat 6 Analoge Eingänge.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 30 April 2020, 19:19:09
Hallo Thomas,

ich habe das mal mit deinem HBW-LC-BL-4 testweise probiert, allerdings kommt da nichts an. Ist da noch was einzustellen?

VG
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 02 Mai 2020, 13:12:02
Hi,

Nimm es mir bitte nicht übel, aber da fehlen 95% der Informationen die es bräuchte um dir eine sinnvolle Antwort geben zu können.
Beschreibe doch bitte was du gebaut hast, was am analogen Port angeschlossen ist...
Dann erst mal debug Ausgabe einschalten und sehen was für den analogen Kanal dort zu sehen ist, bzw. zusätzliche Ausgabe hinzufügen.
Wenn das alles gut ist, dann in FHEM schauen was da ankommt oder nicht..

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 04 Mai 2020, 20:35:44
Hallo Thomas,

ich werde Dir bestimmt nichts übel nehmen! Ohne euch währe ich schließlich nie soweit gekommen. Sorry für meine mangelhafte Frage.

Ich habe auf einen Nano den Sketch vom HBW-LC-BL-4 gespielt und an den Analogen Ausgang (A7) diesen Bodenfeuchtemesser angeschlossen
https://www.amazon.de/AZDelivery-Bodenfeuchtesensor-Hygrometer-kapazitiv-Arduino/dp/B07HJ6N1S4/ref=sr_1_3?__mk_de_DE=ÅMÅŽÕÑ&dchild=1&keywords=bodenfeuchtesensor+1.2&qid=1588616981&sr=8-3 (https://www.amazon.de/AZDelivery-Bodenfeuchtesensor-Hygrometer-kapazitiv-Arduino/dp/B07HJ6N1S4/ref=sr_1_3?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=bodenfeuchtesensor+1.2&qid=1588616981&sr=8-3)

Am Kanal 5 in Fhem habe ich dann geschaut, ob da was ankommt. Ich habe gesehen, das dort auch mehrer Einstellung gibt, die ich probiert hatte, aber ohne erfolg.

Mit dem Debug musstest du mit bitte einmal helfen.

Aktuell kommt da nur folgendes im Serialmonitor an:
R: FD:42:FF:FF:FF:18:00:00:00:01:03:68:03:34
R: FD:42:FF:FF:FF:18:00:00:00:01:03:68:03:34
R: FD:42:FF:FF:FF:1A:00:00:00:01:03:68:AF:48
R: FD:42:FF:FF:FF:1A:00:00:00:01:03:68:AF:48
R: FD:42:FF:FF:FF:1A:00:00:00:01:03:68:AF:48
R: FD:42:FF:FF:FF:1C:00:00:00:01:03:68:4B:CE
R: FD:42:FF:FF:FF:1C:00:00:00:01:03:68:4B:CE
R: FD:42:FF:FF:FF:1C:00:00:00:01:03:68:4B:CE
R: FD:42:FF:FF:FF:1E:00:00:00:01:03:68:E7:B2
R: FD:42:FF:FF:FF:1E:00:00:00:01:03:68:E7:B2
R: FD:42:FF:FF:FF:1E:00:00:00:01:03:68:E7:B2
R: FD:42:FF:FF:FF:18:00:00:00:01:03:68:03:34
R: FD:42:FF:FF:FF:18:00:00:00:01:03:68:03:34
R: FD:42:FF:FF:FF:18:00:00:00:01:03:68:03:34
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 04 Mai 2020, 23:44:18
Hallo,

Danke, das sind ja einige hilfreiche Details...  ;)

Der Sensor sollte am Arduino funktionieren, er scheint eine Spannung von 0 bis 5 volt auszugeben.
Wenn du den Code von hbw-lc-bl-4 unverändert nutzt, dann müsstest du für deinen analogen sensor folgendes aus void setup() löschen :
  analogReference(INTERNAL);    // select internal 1.1 volt reference (to measure external bus voltage)

Um die log Ausgabe zu erhalten, muss du
#define DEBUG_OUTPUT
In https://github.com/ThorstenPferdekaemper/HBWired/blob/master/libraries/src/HBWAnalogIn.h ein kommentieren.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 08 Mai 2020, 17:35:24
Hallo Thomas,

das habe ich soweit erledigt.

Hier die Ausgabe im SerialMonitor:

R: ACK
R: FD:42:FF:FF:FF:1A:00:00:00:01:03:68:AF:48
R: FD:42:FF:FF:FF:1A:00:00:00:01:03:68:AF:48
R: FD:42:FF:FF:FF:1A:00:00:00:01:03:68:AF:48
R: FD:42:FF:FF:FF:1C:00:00:00:01:03:68:4B:CE
R: FD:42:FF:FF:FF:1C:00:00:00:01:03:68:4B:CE
R: FD:42:FF:FF:FF:1C:00:00:00:01:03:68:4B:CE
R: FD:FF:FF:FF:FF:F8:42:00:00:20:06:4B:13:00:9E:F7:B2
R: FD:FF:FF:FF:FF:F8:42:00:00:20:06:4B:14:00:52:88:C0
R: FD:42:FF:FF:FF:1E:00:00:00:01:03:68:E7:B2
R: FD:42:FF:FF:FF:1E:00:00:00:01:03:68:E7:B2
R: FD:42:FF:FF:FF:1E:00:00:00:01:03:68:E7:B2
R: FD:42:FF:FF:FF:18:00:00:00:01:03:68:03:34
R: FD:42:FF:FF:FF:18:00:00:00:01:03:68:03:34
R: FD:42:FF:FF:FF:18:00:00:00:01:03:68:03:34
R: FD:00:00:00:01:98:42:00:00:20:06:69:00:C8:00:27:86
R: FD:42:00:00:20:19:00:00:00:01:02:44:BA
R: FD:FF:FF:FF:FF:F8:42:00:00:20:06:4B:14:00:56:C8:C8
R: FD:42:FF:FF:FF:1A:00:00:00:01:03:68:AF:48
R: FD:42:FF:FF:FF:1A:00:00:00:01:03:68:AF:48
R: FD:42:FF:FF:FF:1A:00:00:00:01:03:68:AF:48
R: FD:42:FF:FF:FF:1C:00:00:00:01:03:68:4B:CE
R: FD:42:FF:FF:FF:1C:00:00:00:01:03:68:4B:CE
R: FD:42:FF:FF:FF:1C:00:00:00:01:03:68:4B:CE
R: FD:FF:FF:FF:FF:F8:42:00:00:20:06:4B:13:00:A2:07:CC
R: FD:FF:FF:FF:FF:F8:42:00:00:20:06:4B:14:00:5A:08:D0
R: FD:42:FF:FF:FF:1E:00:00:00:01:03:68:E7:B2
R: FD:42:FF:FF:FF:1E:00:00:00:01:03:68:E7:B2
R: FD:42:FF:FF:FF:1E:00:00:00:01:03:68:E7:B2
R: FD:42:FF:FF:FF:18:00:00:00:01:03:68:03:34
R: FD:42:FF:FF:FF:18:00:00:00:01:03:68:03:34
R: FD:42:FF:FF:FF:18:00:00:00:01:03:68:03:34
R: FD:00:00:00:01:98:42:00:00:20:06:69:00:00:20:DF:48
R: FD:42:00:00:20:19:00:00:00:01:02:44:BA


In Fhem kommen auf dem Kanal keine Werte an bzw. nur wenn ich ein get State ausführe.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 10 Mai 2020, 10:25:59
Hallo,

Ich sehe keine debug Ausgabe im seriellen Monitor... Ist der analog Kanal überhaupt aktiviert? Kannst Du in FHEM in den Kanal Einstellungen nachsehen und das Update interval auf 10 Sekunden stellen?

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 10 Mai 2020, 18:22:01
ZitatIch sehe keine debug Ausgabe im seriellen Monitor...
Habe ich so drin stehen in der HBWAnalogIn.h und habe auch Arduino-Software danach einmal neu gestartet.
#define DEBUG_OUTPUT   // extra debug output on serial/USB

ZitatKannst Du in FHEM in den Kanal Einstellungen nachsehen und das Update interval auf 10 Sekunden stellen?
Das hatte ich schon auf 10 Sekunden gestellt.


ZitatIst der analog Kanal überhaupt aktiviert?
Was meinst du damit genau?

Das habe ich aus dem Sketch des hbw-lc-bl-4 gelöscht
  analogReference(INTERNAL);    // select internal 1.1 volt reference (to measure external bus voltage)

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 10 Mai 2020, 23:37:04
Zitat von: holzwurm83 am 10 Mai 2020, 18:22:01
Was meinst du damit genau?
Es gibt eine Konfigurations Option INPUT_ENABLED, sie sollte auf "ja" stehen. Das musst du über FHEM setzen, da dieser Kanal Standard mäßig deaktiviert ist. Das scheint bei dir noch immer der Fall zu sein, da keine log Ausgaben vorhanden sind...

Gruß,.
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 13 Mai 2020, 13:51:34
Zitat von: loetmeister am 10 Mai 2020, 23:37:04
Es gibt eine Konfigurations Option INPUT_ENABLED, sie sollte auf "ja" stehen. Das musst du über FHEM setzen, da dieser Kanal Standard mäßig deaktiviert ist. Das scheint bei dir noch immer der Fall zu sein, da keine log Ausgaben vorhanden sind..

Habe das gerade nochmal überprüft, aber INPUT_ENABLED steht schon auf "ja". Die Option notify steht auf "off".

Internals:
   DEF        42000030_05
   FUUID      5eab0065-f33f-8b44-1e79-252d086d92d2051c
   NAME       HBW_LC_Bl_4_HBW7296304_05
   NR         41
   STATE      value_6.9830878
   TYPE       HM485
   chanNo     05
   device     HBW_LC_Bl_4_HBW7296304
   peerRole   none
   READINGS:
     2020-05-13 13   R-input_enabled yes
     2020-05-13 13   R-notify        off
     2020-05-13 13   R-update_interval 10.00
     2020-05-13 13   state           value_6.9830878
     2020-05-13 13   value           6.9830878
   devHash:
     DEF        42000030
     FUUID      5eab0063-f33f-8b44-3630-654768898b0ee04f
     FailedConfigReads 0
     IODev      hm485
     NAME       HBW_LC_Bl_4_HBW7296304
     NR         35
     RawDeviceType 130
     RawFwVersion 50
     STATE      ACK
     TYPE       HM485
     channel_01 HBW_LC_Bl_4_HBW7296304_01
     channel_02 HBW_LC_Bl_4_HBW7296304_02
     channel_03 HBW_LC_Bl_4_HBW7296304_03
     channel_04 HBW_LC_Bl_4_HBW7296304_04
     channel_05 HBW_LC_Bl_4_HBW7296304_05
     READINGS:
       2020-05-13 13   D-deviceKey     HBW_LC_BL_4
       2020-05-13 13   D-fwVersion     0.5
       2020-05-13 13   D-serialNr      HBW7296304
       2020-05-13 13   R-central_address 00000001
       2020-05-13 13   R-logging_time  5.00
       2020-05-13 13   configStatus    OK
       2020-05-13 13   state           ACK
     cache:
       sets       Unknown argument ?, choose one of  config getConfig raw reset 
       01:
         allowedSets level on off up down stop inhibit install_test
         sets       Unknown argument ?, choose one of  config down inhibit install_test level off on stop up  off-for-timer on-till on-for-timer on-till-overnight off-till off-till-overnight blink intervals
         peeredChannels:
       02:
         allowedSets level on off up down stop inhibit install_test
         sets       Unknown argument ?, choose one of  config down inhibit install_test level off on stop up  on-for-timer on-till on-till-overnight off-for-timer intervals blink off-till off-till-overnight
         peeredChannels:
       03:
         allowedSets level on off up down stop inhibit install_test
         sets       Unknown argument ?, choose one of  config down inhibit install_test level off on stop up  on-till-overnight on-till on-for-timer off-for-timer blink intervals off-till-overnight off-till
         peeredChannels:
       04:
         allowedSets level on off up down stop inhibit install_test
         sets       Unknown argument ?, choose one of  config down inhibit install_test level off on stop up  off-till off-till-overnight intervals blink off-for-timer on-till on-for-timer on-till-overnight
         peeredChannels:
       05:
         allowedSets
         sets       Unknown argument ?, choose one of  config 
         peeredChannels:
       linkParams:
         actuator:
         sensor:
           address_start 72
           address_step 9
           channel_param channel
           channels   01 02 03 04
           count      32
           peer_param sensor
           type       link
           parameter:
             HASH(0x25497f0)
             HASH(0x2549ac0)
             HASH(0x2549cf0)
             HASH(0x254a158)
             HASH(0x254a3b0)
             HASH(0x254a800)
             HASH(0x254aa58)
       peers:
         actuators:
         sensors:
Attributes:
   room       HM485
   subType    module bus voltage


Aktuell hängt kein sensor dran und nach get state gibt er einen Wert aus.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 13 Mai 2020, 14:36:12
Zitat von: holzwurm83 am 13 Mai 2020, 13:51:34
Habe das gerade nochmal überprüft, aber INPUT_ENABLED steht schon auf "ja". Die Option notify steht auf "off".

Aktuell hängt kein sensor dran und nach get state gibt er einen Wert aus.

Das ist ja ok. Wenn du automatisch den Wert bekommen willst, dann musst du die Option notify auf "on" stellen.


Im Serial Monitor sollte es nach dem Device start so aussehen:
B: 2A 1196
T: FD:FF:FF:FF:FF:F8:42:FF:FF:FF:12:41:00:82:01:00:32:48:42:57:34:30:37:33:34:37:31:EF:90
adc-ch:4 Val:948
adc-ch:4 Val:994

(+ weitere Nachrichten die vom Bus kommen)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 13 Mai 2020, 18:17:07
ZitatDas ist ja ok. Wenn du automatisch den Wert bekommen willst, dann musst du die Option notify auf "on" stellen.
Habe das auf "on" gesetzt, aber es kommt leider keine automatischen Werte.


ZitatIm Serial Monitor sollte es nach dem Device start so aussehen:

Da kommt auch was anderes an.
B: 2A 1198
T: FD:FF:FF:FF:FF:F8:42:00:00:30:12:41:00:82:01:00:32:48:42:57:37:32:39:36:33:30:34:A6:6A
R: FD:42:FF:FF:FF:1A:00:00:00:01:03:68:AF:48
R: FD:42:FF:FF:FF:1A:00:00:00:01:03:68:AF:48
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 16 Mai 2020, 09:40:08
Hi,

Habe mir den Code mal genau angeschaut... Habe wohl die notify Option eingebaut, nicht aber den Code der dann auch etwas sendet. Dachte ich hätte das schon drin gehabt. Ich checke Sonntag mal eine neue Version ins github ein..

Wenn die debug Ausgabe fehlt, scheint irgendwas mit dem "#define DEBUG_OUTPUT" nicht zu stimmen.


EDIT:
Habe HBWAnalogIn mal etwas erweitert, um (ähnlich wie bei Temperatur Kanälen) den Messwert regelmäßig oder bei einsprechender Änderung zu senden.
https://github.com/loetmeister/HBWired/commit/ebc669865c0d629e7c7f1f4d7e652a191bea6d7b#diff-7d4d7737950a1575e5aea081dcb1c4a8
Bitte einmal alles Komplett neu laden (Lib, Sketch und XML - nicht vergessen XML in FEHM zu aktualisieren. #define DEBUG_OUTPUT muss auch wieder neu aktiviert werden...)

Es gibt nun diese Konfig:
  send_delta_value;        // Differenz des Messwerts, ab dem gesendet wird
  send_max_interval;     // Maximum-Sendeintervall
  send_min_interval;     // Minimum-Sendeintervall
  update_interval;  // 0 = Kanal deaktiviert

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 18 Mai 2020, 20:13:12
Hallo,

habe heute mit FEHM getestet und noch ein paar kleine Korrekturen vorgenommen.
-> https://github.com/loetmeister/HBWired/tree/master/libraries

Für deinen Sensor muss du dann eine eigen XML mit den passenden Umrechnungsfaktoren erstellen, aber es sollte nun zumindest grundsätzlich funktionieren...  8)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 19 Mai 2020, 19:48:42
Hallo Thomas,

danke Dir! Ich habe das jetzt mal aufgespielt und auf den Nano. Die xml habe ich auch neu eingefügt und die pm-Datei neu generiert.

Leider stimmt da noch was nicht.

Habe auch einen Reset am Nano gemacht.

Hier mal der Serielmonitor:
⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮J⸮>⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮B: 2A 1196
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:1E:00:00:00:01:03:68:10:A6
T: HWVer,Typ
T: FD:00:00:00:01:78:42:00:00:30:04:82:01:F9:B0
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:FF:02:00:30:1E:00:00:00:01:03:68:10:A6E: CRC
T: FD:00:00:00:01:78:42:00:00:30:04:82:01:F9:B0
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00R: FD:04:00:00:01:03:68E: MsgTooLong
:10:A6T: FD:00:00:00:01:78:42:00:00:30:04:82:01:F9:B0
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:1C:00:00:00:01:03:68:56:BA
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:1C:00:00:00:01:03:68:56:BA
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:1C:00:00:00:01:03:68:56:BA
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38:01:22:1C:00:00:00:01:03:68:E1:00
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38:01:22:1C:00:00:00:01:03:68:E1:00
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38:01:22:1C:00:00:00:01:03:68:E1:00
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:FF:FF:1C:00:00:00:01:FFE: MsgTooLong
:4B:CER: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:FF:FF:1C:00:00:00:01:03:68:4B:EEE: CRC
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:FF:FF:1C:00:00:00:01:03:68:4B:CE
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:18:00:00:00:01:03:68:F4:20
T: HWVer,Typ
T: FD:00:00:00:01:18:42:00:00:30:04:82:01:A4:F4
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:18:00:00:00:01:03:68:F4:20
R: ACK
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:18:00:00:00:01:03:68:F4:20
T: HWVer,Typ
T: FD:00:00:00:01:18:42:00:00:30:04:82:01:A4:F4
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDT: FD:00:00:00:01:18:42:00:00:30:04:82:01:A4:F4
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDT: FD:00:00:00:01:18:42:00:00:30:04:82:01:A4:F4
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:1E:00:00:00:01:03:EA:C7R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:1E:00:00:00:01:03:68:FA:C6
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:1E:00:00:00:01:03:68:FA:C6
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38:01:22:1E:00:00:00:01:03:68:4D:7C
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38:01:22:1E:00:00:00:01:03:68:4D:7C
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38:01:22:1E:00:00:00:01:03:68:4D:7C
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:79:00:00:00:01:03:68:E7:B2R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:FF:FF:1E:FA:00:01:03:68E: MsgTooLong
:E7:B2R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:FF:FF:1E:00:00:00:81:FFE: MsgTooLong
:DB:C9:FFR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:1A:00:00:EA:01:68E: MsgTooLong
:58:5CR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:1A:00:00:00:01:03:E8:97R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:1A:00:00:00:01:03:68:58:5C
T: HWVer,Typ
T: FD:00:00:00:01:38:42:00:00:30:04:82:01:60:36
R: FDR: FD:42:00:00:30:FF:02:00:01:02:77E: MsgTooLong
:50R: FD:42:00:00:30:1C:00:00:00:01:03:6E:DC:D6
R: ACK
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:1C:00:00:00:01:03:6E:DC:D6
T: FD:00:00:00:01:58:42:00:00:30:0C:48:42:57:37:32:39:36:33:30:34:C3:96
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:1C:00:00:00:01:03:6E:DC:D6
R: ACK
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:18:00:00:00:01:03:68:1E:40
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:18:00:00:00:01:03:68:1E:40
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:18:00:00:00:01:03:68:1E:40
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: B: 2A 1196
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FA:60:1A:00:00:00:01:03R: FD:5CR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:1A:00:00:00:01:03:68:58:5C
T: HWVer,Typ
T: FD:00:00:00:01:38:42:00:00:30:04:82:01:60:36
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:48:00:30:1A:00:00:D4:40:1B:8D:F9R: FDR: FDT: FD:00:00:00:01:38:42:00:00:30:04:82:01:60:36
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDT: FD:00:00:00:01:38:42:00:00:30:04:82:01:60:36
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:E4:00:00:00:01:03:68:FA:EER: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:1E:00:FA:05:03:68E: MsgTooLong
:FA:C6R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:1E:00:00:00:01:03:68:FA:C6
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:67:22:1E:00:00:00:A9:6D:93:FFR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38R: FD:79:00:00:00:01:03:68R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38:01:22:1ER: FD:01:01:03:68:4D:7CR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:FF:FF:1E:00:00:80:FF:30:DB:2E:D6R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:79:00:00:00:01:03:FC:ACR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:FF:FF:5E:FF:08:01:03:68E: MsgTooLong
:E7:B2R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:D0:8C:0C:00:00:01:03:F8:FBR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:1C:00:00:00:01:03:68:BC:DA
T: HWVer,Typ
T: FD:00:00:00:01:58:42:00:00:30:04:82:01:3D:72
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:48:00:30:1C:00:00:00:01:03:68:BC:DAT: FD:00:00:00:01:58:42:00:00:30:04:82:01:3D:72
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDT: FD:00:00:00:01:58:42:00:00:30:04:82:01:3D:72
R: FD:42:00:00:30:19:00:FE:14:02:77E: MsgTooLong
:50R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:18:00:00:00:01:03:68:1E:40
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:18:00:00:00:01:03:68:1E:40
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:80:20:18:00:00:00:A9:CD:08:FFR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38:01:22:18:00:00:00:01:43E: MsgTooLong
:FF:CA:FFR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38:01:22:18:00:00:00:01:03:68:A9:FA
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38:01:22:18:00:EA:80:03:68E: MsgTooLong
:A9:FAR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:21:FF:FF:FF:18:00:00:00:01:03:68:03:34E: CRC
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:FF:FF:00:00:00:01:03:68:03:F5R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:FF:FF:18:00:00:00:01:03:68:03:34
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:FF:01:00:01:03:68E: MsgTooLong
:10:A6R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:1E:00:00:FA:03:68E: MsgTooLong
:10:A6R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42R: FD:04:E4:08:00:00:01:03E: CRC
R: FD:66R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:1A:00R: FD:0A:03:68:B2:3CR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:1A:00:00:00:01:03:68:B2:3C
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:20:1A:00:00:00:01:03:68:B2:3C
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38:01:22:1A:00:00:00:01:03:68:05:AEE: CRC
R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:38:01:22:1A:00:F4:01:03:68E: MsgTooLong
:05:86R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:E2:30:A4:0C:00:00:01:83:FF:90:F8R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:F7:FF:FF:1A:00:00:00:01:03:68:AF:48R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:FF:FF:00:00:00:01:03:68:AF:E8R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:FF:FF:FF:1A:00:A0:60:40:DBE: MsgTooLong
:15:F2R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:18:00:E8:80:03:68E: MsgTooLong
:F4:20R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:00:30:18:00:00:00:01:FFE: MsgTooLong
:A3:20R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:00:D0:86:00:00:01:03:68:F4:20R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FD:42:C0:32:1C:00:00:01:03:78:F7R: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR: FDR
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 19 Mai 2020, 20:11:57
Hi,

das sieht mir nach den Daten aus, die eigentlich auf dem Bus landen sollten. Womit testest du? HBW-LC-Bl-4 (https://github.com/loetmeister/HBWired/tree/master/HBW-LC-BL-4)?

Da muss //#define USE_HARDWARE_SERIAL in HBW-LC-Bl-4.ino deaktiviert sein.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 19 Mai 2020, 20:22:59
ZitatWomit testest du? HBW-LC-Bl-4 (https://github.com/loetmeister/HBWired/tree/master/HBW-LC-BL-4)?
ja, mit dem HBW-LC-Bl-4

ZitatDa muss //#define USE_HARDWARE_SERIAL in HBW-LC-Bl-4.ino deaktiviert sein.
ja, das ist deaktiviert.


Ich sehe gerade das du noch "Edit" in einem deiner Beiträge noch was ergänzt hast. ich habe die lib nicht neu rein gezogen. Das muss ich dann noch mal machen.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 30 Mai 2020, 09:44:23
Hallo,

Unabhängig von dem vorangegangenen Problem habe ich mal ein paar kleine Änderungen in einem pull request zusammengestellt.

U.a. Erweiterung an HBWAnalogIn den Messwert wie bei Temperatur Kanälen zu übermitteln. .
HBWKey wiederholt nun Nachrichten für motion sensor und door sensor type, wenn der bus blockiert war.

https://github.com/ThorstenPferdekaemper/HBWired/pull/17

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 05 Juni 2020, 22:12:52
Hallo,

seitdem ich mit "HBWOneWireTempSensors" das bestehende Modul HBW-1W-T10 auf die neue Lib portiert hatte, und dabei festgestellt habe das die Konfiguration dauerhaft im RAM landet (uint8_t* config; referenziert auf das hbw_config struct) wollte ich das versuchen zu verbessern...
Das unnötig Daten im RAM landen ist grade bei HBW-1W-T10 der Fall. Für die 10 Kanäle belegen alleine die 8 Byte großen OneWire Adressen 80 Byte.

Viele Atmel Prozessoren scheinen ein Option zu bieten, bei dem die Daten im EEPROM direkt angesprochen werden können, in dem z.B. ein passenden struct auf den EEPROM Speicherbereich gelegt wird  ("MAPPED_EERPOM_START").
Bei dem Arduino Nano (Atmel 328p) scheint es dies nicht zu geben...

Es lässt sich aber dennoch ähnlich eine Referenz zum EEPROM mit "EEMEM" erstellen. (https://www.avrfreaks.net/forum/tut-c-using-eeprom-memory-avr-gcc?name=PNphpBB2&file=viewtopic&t=38417)

Diese Referenz belegt keinen Speicher, es müssen aber um Daten aus dem EEPROM zu lesen natürlich Variablen erzeugt werden (z.B. als Teil einer Klasse oder Funktion). Das könnte aber selektiv erfolgen, statt den gesamten hbw_config struct im RAM zu halten. (oder auch die Peering parameter könnte in das "EEMEM struct" integriert werden - so ließen sich einzelne Parameter "mit namen" ansprechen)

Wie viel RAM das am Ende spart und wie groß der zusätzliche Aufwand (eventueller Anstieg vom Programmspeicherplatz) ist noch offen... was mich aber etwas unsicher macht:
So wie ich das verstanden habe, legt der Kompiler fest, wo im EEPROM das struct mit "EEMEM" deklariert landet. Es scheint (beim testen war es der Fall) bei 0x00 los zu gehen... worauf ich aber keinen Einfluss nehmen kann. Das ist natürlich schlecht, da in den zugehörigen Device XML die EEPROM Adressen hinterlegt werden müssen.

Hat jemand Erfahrung damit? Ein einziger struct, der den genutzten EEPROM Bereich "strukturiert" fängt zuverlässig an der ersten Speicheradressen an? :)

typedef struct {
  uint8_t reserved;          //0x0 - TODO: Geht es immer bei 0x0 los???
  uint8_t logging_time;     // 0x01
  uint32_t central_address;  // 0x02 - 0x05
  uint8_t direct_link_deactivate:1;   // 0x06:0
  uint8_t              :7;   // 0x06:1-7
  hbw_config_basic_flags_t hbw_config_basic_flags;
} hbwconfig_t;

hbwconfig_t hbwconfig EEMEM;
...
//Variable aus EEPROM gezielt lesen:
  uint8_t logging_time; 
  eeprom_read_block( &logging_time, &hbwconfig.logging_time, sizeof(hbwconfig.logging_time));
//oder
  logging_time = eeprom_read_byte(&hbwconfig.logging_time);




Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 25 Juni 2020, 22:23:19
Hallo,

unabhängig von dem vorangegangenen "Problem" ist mir aufgefallen, das mit der aktuellen HBWSoftwareSerial (SoftwareSerial) direkt nach dem Senden einer Nachricht "Müll" im Empfangspuffer zu sein scheint.
Ich nutze HBWSoftwareSerial nur während der Entwicklung, fürs Debugging, daher ist mir das nicht aufgefallen. Zumal ich auch der Meinung bin das dies nicht der Fall war, als ich die neue SoftwareSerial angepasst hatte...  ???
Aktuell sieht es z.B. so aus:
B: 2A 537
T: FD:FF:FF:FF:FF:F8:42:00:00:30:12:41:00:96:01:00:05:48:42:57:37:32:39:36:33:30:34:A9:62
:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF

Der RS485 Transceiver muss verbunden sein. Ohne gibt es dieses "Echo" nicht.

Nach dem senden einer Nachricht gibt HBWDevice::receive() die "FF"s aus, welche mit serial->read() gelesen wurden... d.h. irgenwie sind Daten in den Empfangspuffer gekommen. Es ist auch immer "FF:FF:FF..". Bei kürzeren Telegrammen ist aber auch etwas weniger im Puffer.

Wenn ich die alte Funktion HBWSoftwareSerial::flush() wieder einbaue, welche direkt nach dem senden ausgerufen wird und den HBWSoftwareSerial Empfangspuffer löscht, verschwindet der Müll - die Debug Ausgabe ist wieder sauber.

HBWSoftwareSerial nutzt zum empfangen Port Change Interrupts... während des Sendens sind Interrupts aber deaktiviert. Wie können da Daten empfangen werden?
flush() löst das Problem, aber es wurde aus der aktuellen SoftwareSerial entfernt, da es eigentlich nicht gebraucht wird...


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: holzwurm83 am 27 Juni 2020, 23:35:00
Hallo Thomas,

ich habe mir für meinen aktuell laufenden Umbau vor zwei Tagen hier nochmal alles Ordner gezogen und habe mir einen neuen HBW-LC-Sw-8_AdvancedPeering zusammengebaut.

Heißt das er davon auch betroffen ist und ich den noch mal bespielen sollte?
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 28 Juni 2020, 13:38:58
Hi,

ich hatte gestern noch ein wenig mit der Software getestet und festgestellt das die Daten über den Interrupt - also tatsächliche Pegeländerungen am Rx Pin kommen müssen.
Somit ist mit der HBWSoftwareSerial eigentlich alles ok. Die alte Version hat diesen Effekt für den Sender nur unterdrückt.

Nachdem ich nun wusste das es vom Bus kommen muss, habe ich Schritt für Schritt alle Geräte abgeklemmt und ein Gerät identifiziert, in dem ich test-weise ESD Schutzdioden (TSV-Dioden) an die Busleitung gelötet hatte.
Die Dioden sind PESD5V0S1BA
reverse stand-off voltage 5V
clamping voltage 10V (IPP = 1 A) 14V (IPP = 12 A)

Dachte das wäre ok, da auf dem Bus ca. 4,5V Pegel liegen. Aber vermutlich bin ich mit den 5V zu nah dran. RS485 erlaubt bis 12V.. muss mal schauen ob der Effekt mit anderen Schutzdioden weiterhin auftritt.
Zeit noch mal nach zu lesen, wie man es richtig macht  8) :
https://e2e.ti.com/blogs_/b/industrial_strength/archive/2017/11/13/how-to-choose-a-tvs-diode-for-rs-232-rs-485-and-can-based-on-voltage-ratings


EDIT:
Beim tauschen der ESD Schutzdioden von PESD5V0S1BA zu P6SMB6.8CA ist mir aufgefallen das eine der beiden Dioden defekt war. Sie hatte Druchgang, d.h. Leitung A oder B des Bus war mit Masse Verbunden. (hab erst nach dem Ausbau gemessen, daher weiß ich nicht in welcher der beiden Busleitung sie gesessen hat)
Nachdem ich die die defekte Diode ausgebaut hatte habe ich keine Störung mehr auf dem Bus, sowohl mit PESD5V0S1BA als auch P6SMB6.8CA.

Die Dioden P6SMB6.8CA wollte ich eigentlich nicht nehmen, da sie einen deutlich höheren Leckstrom und Kapazität haben.
Bei PESD5V0S1BA ist dafür die Spannung (reverse stand-off voltage) eventuell zu niedrig und die clamping voltage mit 14V zu hoch. Mein RS-485 Driver verträgt max. 12,5V.
P6SMB7.5CA oder P6KE7.5CA wäre vermutlich eine bessere Wahl... oder die SM712, welche in dem Ti Artikel erwähnt wurde und speziell für RS-485 und asymmetrische Spannungen geeignet ist. Müsste man sehen wo man die kaufen kann und zu welchem Preis.. bei Mouser sind es ca. 50 Cent... eventuell nimmt man besser einen RS-485 Driver mit eingebautem ESD Schutz. :)
ZitatThe SM712 TVS Diode Array is designed to protect RS-485 applications with asymmetrical working voltages (-7V to
12V) from damage due to electrostatic discharge (ESD), electrical fast transients (EFT), and lightning induced surges.
https://m.littelfuse.com/~/media/electronics/datasheets/tvs_diode_arrays/littelfuse_tvs_diode_array_sm712_datasheet.pdf.pdf

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 03 Juli 2020, 23:28:58
Hallo,

Habe mal für die letzten Änderungen an der library einen pull request gestellt. https://github.com/ThorstenPferdekaemper/HBWired/pull/18
Wirkliche Änderungen habe ich nur an HBW-CC-VD-8 (HBWPids) vorgenommen, dort ist nun die Zieltemperatur (DEFAULT_SET_POINT) konfigurierbar.
Eine weitere Ergänzung sind die feedback/logging Funktionen, die nun in der HBWChannel Klasse sind. Man muss sie nicht nutzen und belegen dann auch keinen Speicherplatz, aber bei Aktoren braucht man sie eigentlich immer und in diesem Fall muss man nun nicht mehr den ganzen Code hinzufügen, was auch die Lesbarkeit verbessert.

   setFeedback()  //  set feedback trigger (ruft man in channel set() auf)
   checkFeedback()  //  send sendInfoMessage, if feedback trigger is set (das kommt in den loop)
   clearFeedback()  //  reset/init feedback trigger values (das muss in den constructor)


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 08 Juli 2020, 07:12:40
Zitat von: loetmeister am 03 Juli 2020, 23:28:58

Habe mal für die letzten Änderungen an der library einen pull request gestellt. https://github.com/ThorstenPferdekaemper/HBWired/pull/18
...ist erledigt.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 06 Oktober 2020, 22:21:14
Hallo,

habe mal wieder einen Pull Request gestellt. https://github.com/ThorstenPferdekaemper/HBWired/pull/20
Neben ein paar Korrekturen ist ein weiteres Gerät hinzugekommen HBW-DIS-Key-4 https://forum.fhem.de/index.php/topic,112573.0.html
(https://github.com/loetmeister/HBWired/tree/master/HBW-DIS-Key-4)


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Banisa am 13 Dezember 2020, 13:40:41
Hallo,

ich habe ein Problem mit Homebrew Geräten und FHEM und eine Frage an die Experten. Ich habe mir einen RS485 Lan-Adapter mit WIZ108SR, HBW-LC-BL-4 und HBW-Sen-Key-12 gebaut. Ich kann Daten an die beiden Module senden, z.B. habe ich die Adressen von Standart auf 42001041 und 42001022 ändern, aber FEHM reagiert nicht auf Daten von den beiden Modulen. An was kann das liegen und was braucht ihr noch an Info's ?

Bernd
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 13 Dezember 2020, 23:24:57
Hallo Bernd,

Wurden die Geräte automatisch in FHEM mit der Standard Adresse angelegt? Oder wie hattest du die neue Adresse konfiguriert?
Siehst du im FHEM log die announce Nachricht, wenn du den konfig Taster drückst?

Es gab auch mal ein seltsames Problem mit dem WIZ108.. Da hat ein anderes LAN Kabel geholfen.  :)


Edit: Das Serielle log ist vom Gerät mit Adresse 42:00:10:41? FHEM sendet die Abfrage der Hardware Version (68), es kommt aber keine Antwort. Stelle auf jeden Falls einmal sicher das im log das Senden der announce Nachricht von 42001041 und 42001022 zu sehen ist..

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 17 Dezember 2020, 23:22:59
Zitat von: Banisa am 13 Dezember 2020, 13:40:41z.B. habe ich die Adressen von Standart auf 42001041 und 42001022 ändern,
Bist Du Dir da sicher, dass das geklappt hat?
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Banisa am 20 Dezember 2020, 12:44:12
Hallo Thomas und Thorsten,

mit der Antwort hat es leider etwas gedauert, aber ich musste mir erst einen neuen USB/RS232 Umsetzer kaufen um das Debug des Devices auf zu zeichnen.
Keines der Geräte wurde automatisch in FHEM angelegt. Ich habe beide nach einander angeschlossen und von Hand angelegt, mit der standart Adresse und diese habe ich dann per RAW Befehl geändert. Im FHEM Log taucht weder die announce Nachricht auf noch wenn ich eine andere Taste drücke. Ich sehe nur das die Module etwas senden auf dem RS485 Bus. Das Gerät 42:00:10:41 ist ein Arduino Uno mit der minmal Konfiguration der nur auf dem RS485 Bus "lauscht" und alles auf den PC sendet, wo ich es dann im seriellen Monitor der Arduini IDE sehe.
Laut der Aufzeichnung der Daten auf dem RS485 Bus denke ich schon das es mit der Änderung der Adressen geklappt hat.
Der 1. Anhang ist das Log des Arduino und der 2. das der Devices. Ich habe zuerst den Bus aufgebaut und die Config Taste gedrückt und dann erst FHEM gestartet um das so auf zu zeichnen.

Bernd 
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 20 Dezember 2020, 23:19:35
Hi,

Für mich sieht es so aus, als ob fhem bei dem Gerät in einer Schleife hängt um die Konfiguration zu lesen.
Was steht denn als konfig Status im device?

Bzgl. autocreate, hast du das abgeschaltet? In dem log ist die announce Nachricht zu sehen, also würde fhem auch das Gerät anlegen. .

42:42:00:14 ist die Adresse von welchem Gerät?

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Banisa am 26 Dezember 2020, 17:41:29
Hallo Thomas,

ich kann jetzt auch das Netzwerkkabel, als Fehlerquelle ausschliesen.
Die Adresse 42:42:00:14 ist der Arduino der auf dem RS485-Bus lauscht.
Autocreate ist eingeschaltet und funktioniert auch. Ich hatte kürzlich 2 Funk-Heizkörper Thermostate in Betrieb genommen. Diese wurden automatisch erkannt und angelegt.
Mich kommt es auch so vor als ob FHEM in einer schleife hängt, es kommen immer die gleichen Nachrichten auf dem Bus. Daher dachte ich auch an einen Fehler bei der FHEM Installation.
Ich habe dann die Komplette Installation auf einem 2. Raspberry Pi gemacht aber das Ergebnis ist das gleiche. Was nicht heißen soll das es nicht doch an der Installation aud dem Pi liegen soll und ich den gleichen Fehler 2 mal gemacht habe.
Im Device config steht folgendes:
{
".message":{
"input":"0",
"type":"text",
"value":"Device not completely loaded yet. Try again later."
}
}

Mfg Bernd
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 02 Januar 2021, 20:06:48
Hi,
ich weiß, es ist eine Weile her, aber bist Du inzwischen weiter gekommen?
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 22 Januar 2021, 10:59:28
Hallo in die Runde,

Ich habe, neben ein paar kleinen Verbesserungen an den zuletzt hinzugefügten Modulen, den reset Befehl hinzugefügt. (Er erlaubt einen Neustart des Mikrocontrollers. FHEM Raw Befehl "2121" ("!!"))
Zusätzlich noch eine weitere define Option um den watchdog zu aktivieren. Falls er aktiviert ist, wird er auch zum Modul reset / Neustart genutzt. Watchdog timeout habe ich auf eine Sekunde gesetzt, denke das ist lang genug. Wenn ich das richtig im Kopf habe sollte der loop (für empfangen /senden) mindestens alle 300ms aufgerufen werden um eine verlässliche Kommunikation sicher zu stellen.
Zunächst einmal sind beide Funktionen nicht aktiviert. In der HBWired.h kann man es aktivieren.
Da ich ein paar Module ohne einfach erreichbaren reset Taster gebaut habe ist der Neustart über FHEM nun ganz nützlich

https://github.com/loetmeister/HBWired/commit/34ca6bdafa0a7e9d8811e1445af029a212ea82c2

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 26 März 2021, 10:47:04
Hallo zusammen,

Ich habe Ende 2019 versucht mit hilfe von Thomas ein HMW-Sen-SC-12-DR auf die Beine zu bekommen. Aus privaten Problemen hatte ich leider andere Prioritäten. Jetzt wollte ich mich wieder um mein smarthome kümmern. Da das HMW-Sen-SC-12-DR damals nicht fertig geworden ist, wollte ich fragen ob in der Zeit jemand anders was ähnliches fertig gestellt hat?
Gruß
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 26 März 2021, 17:55:39
Hi,

willkommen zurück.  8)
Mir ist im Forum nicht untergekommen, das jemand HMW-Sen-SC-12-DR in der Zwischenzeit nachgebaut hätte...  ;D
Du musst vermutlich weitermachen wo du 2019 aufgehört hast. HBW-SC-10-Dim-6 als Vorlage zu nehmen halte ich immer noch für richtig  ;)
https://forum.fhem.de/index.php/topic,22952.msg967917/topicseen.html#msg967917

Am besten lädst du dir die aktuellen Dateien/Library runter, da hat sich hier und da etwas verändert.
https://github.com/loetmeister/HBW-Devices

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 26 März 2021, 22:04:34
Na super, Jetzt muss ich mich wieder einarbeiten :)  so werde mich am Sonntag darum kümmern test fhem installieren und starten. Freue mich schon darauf.
8)
Gruß
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 28 März 2021, 08:09:36
Hallo, hab noch eine Frage bevor ich die aktuellen Dateien/LIBs runterlade.

Ich habe seit 2019 dauerhaft mehrere HBW-LC-Sw8, HBW-Sen-SC8 und HBW-LC-Bl-8 im Einsatz. Was passiert mit den ganzen Einstellungen in dem (notify,..) und Peerings untereinander wenn ich die neues LIBs nehme? Sollte ich nicht lieber bei den alten bleiben die ich damals benutz habe oder bleibt alles erhält?

Gruß
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 28 März 2021, 13:48:54
Hi,

Peerings und Einstellungen bleiben erhalten, wenn nichts am EEPROM Layout geändert wurde (d.h. An dem struct für die Kanäle oder peerings). Ich bin mir relativ sicher, daß es da keine Veränderungen seit 2019 gegeben hat. Ich würde aber empfehlen die aktuelle Firmware zu sichern, dann kannst du wieder auf die alte Version, falls es Probleme gibt.

Ergänzung:
Du kannst auch zur Sicherheit die xml Dateien vergleichen. Wenn sich da EEPROM Adressen geändert haben musst du vorsichtig sein.  ;)

Der Hinweis die library zu aktualisieren bezog sich vor allem auf die Entwicklung der neuen Gerätes, du musst nicht zwangsläufig alle anderen Geräte aktualisieren.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Banisa am 24 Mai 2021, 14:32:40
Hallo Thorsten,

nach länger Zeit melde ich mich wieder zurück und kann Erfolg vermelden. Ich habe alle meine HBW Geräte noch mals aufgebaut und es hat immer noch nicht funktioniert. Dann habe ich mir einen gan billigen USB->RS485 umsetzter bestellt. In FHEM die CFG angepasst und plotzlich haben sich die Geräte ordnungsgemäs gemeldet. Mit dem WIZ108 scheint etwas nicht in Ordnung zu sein. Etwas ist noch komisch. Wenn ich ein neues Gerät zum ersten mal anschliese und den Config Taster drücke, erscheint das Gerät in FHEM. Dann ändere ich per RAW die Adresse und lösche es. Wenn ich jetzt die Config Taste drücke wird das Gerät nicht erkannt. Erst wenn ich FHEM neu starte wird es erkannt. Das ist jetzt nicht schlimm, nachdem ich herausgefunden habe was ich machen muss das die Geräte erkannt werden.
Jetzt bin ich dabei mit notify und/oder DOIF die Eingänge mit den Ausgängen zu verknüpfen. Was aber noch nicht zufreidenstellend funktioniert. Aber ich denke das gehört nicht hier hin.

Mfg Bernd
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 25 Mai 2021, 18:29:13
Zitat von: Banisa am 24 Mai 2021, 14:32:40Wenn ich ein neues Gerät zum ersten mal anschliese und den Config Taster drücke, erscheint das Gerät in FHEM. Dann ändere ich per RAW die Adresse und lösche es. Wenn ich jetzt die Config Taste drücke wird das Gerät nicht erkannt. Erst wenn ich FHEM neu starte wird es erkannt.
Leider kann ich das momentan nicht selbst ausprobieren, weil ich gerade keine Testumgebung habe. Vielleicht kann jemand anders das auch nachvollziehen und kann mal nachsehen, woran das liegt.
Ich werde mal ins Coding schauen, vielleicht fällt mir ja was auf.
Gruß,
  Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Funsailor am 26 Mai 2021, 15:04:06
Hallo Bansai,
ich habe die Tage nach einem Update der HBW Lib mit 2 dieser Devices getestet:
https://forum.fhem.de/index.php?topic=115333.new;topicseen#new
Dabei hatte ich 2 mal die gleiche Adresse vergeben  ::), (copy and paste), das gab natürlich Probleme auf dem Bus.

Nachdem ich die eine Adresse geändert hatte, konnte ich beide Devices mit der Config Taste in FHEM einfügen.
Ich nutze allerdings einen seriellen USB/RS485 Adapter.

Scheint also kein prinzipielles Problem vorzuliegen.
LG
Michael
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 01 Juli 2021, 21:08:43
Hi,

ab Nov 2020 wird eine neue Annonce Nachricht nach dem ändern der Device Adresse (RAW 4061...) geschickt, das betätigen des Konfig Tasters sollte nicht nötig sein. (gilt natürlich nur wenn das Anlegen generell (autocreate) nicht Klemmt  ;D)
https://github.com/ThorstenPferdekaemper/HBWired/commit/da56fe994632d5e239193f9d0326041a9ba75b53

Noch ein Anmerkung zur letzten Änderung. Da ich jetzt einige Monate meine Devices mit Watchdog habe laufen lassen, ist es nun standardmäßig aktiv (HBWired.h, #define Support_WDT).
Zum zweiten habe ich die einzige Verwendung von sprintf rausgenommen und durch ein wenig code ersetzt (von hausbus "geliehen") ..... das spart erheblich flash Speicher (über 1500 byte) und ein paar byte RAM. Die Funktion bleibt erhalten (die Berechnung der Seriennummer)
https://github.com/ThorstenPferdekaemper/HBWired/commit/834c460c715bf88c01bc1b3316666e865ac3d891

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 01 August 2021, 20:10:27
Hallo zusammen,
Hab die Tage versucht HMW-Sen-SC-12-DR im laufen zu bekommen. Als Vorlage habe ich wie Thomas wieder empfohlen hat, HBW-SC-10-Dim-6 genommen.
Device: Arduino mini pro

Arduino IDE
#define HARDWARE_VERSION 0x01
#define FIRMWARE_VERSION 0x003C
#define HMW_DEVICETYPE 0x98 //device ID (make sure to import hbw_io-10_dim-6.xml into FHEM)

#define NUMBER_OF_INPUT_CHAN 12   // input channel - pushbutton, key, other digital in
#define NUMBER_OF_SEN_INPUT_CHAN 12  // equal number of sensor channels, using same ports/IOs as INPUT_CHAN


#define NUM_LINKS_INPUT 24    // address step 6
#define LINKADDRESSSTART_INPUT 0x038   // ends @0x0C7


//#define USE_HARDWARE_SERIAL   // use hardware serial (USART) for final device - this disables debug output
/* Undefine "HBW_DEBUG" in 'HBWired.h' to remove code not needed. "HBW_DEBUG" also works as master switch,
* as hbwdebug() or hbwdebughex() used in channels will point to empty functions. */


// HB Wired protocol and module
#include <HBWired.h>
#include <HBWLinkKey.h>
#include <HBWKey.h>
#include <HBWSenSC.h>


// Pins

  #define RS485_RXD 4
  #define RS485_TXD 2
  #define RS485_TXEN 3  // Transmit-Enable
  #define BUTTON 8  // Button fuer Factory-Reset etc.

  #define IO1 A3
  #define IO2 10
  #define IO3 11
  #define IO4 A0
  #define IO5 A1
  #define IO6 A2
  #define IO7 A4
  #define IO8 A5
  #define IO9 9  // dummy pin to fill the array elements
  #define IO10 7  // dummy pin to fill the array elements
  #define IO11 6
  #define IO12 5

  #include "FreeRam.h"
  #include <HBWSoftwareSerial.h>
  HBWSoftwareSerial rs485(RS485_RXD, RS485_TXD); // RX, TX


#define LED LED_BUILTIN        // Signal-LED

#define NUMBER_OF_CHAN NUMBER_OF_INPUT_CHAN + NUMBER_OF_SEN_INPUT_CHAN


struct hbw_config {
  uint8_t logging_time;     // 0x01
  uint32_t central_address;  // 0x02 - 0x05
  uint8_t direct_link_deactivate:1;   // 0x06:0
  uint8_t              :7;   // 0x06:1-7

  hbw_config_senSC senCfg[NUMBER_OF_SEN_INPUT_CHAN]; // 0x07 - 0x12 (address step 1)
  hbw_config_key keyCfg[NUMBER_OF_INPUT_CHAN]; // 0x12 - 0x2A (address step 2)

} hbwconfig;


HBWChannel* channels[NUMBER_OF_CHAN];  // total number of channels for the device


class HBDimIODevice : public HBWDevice {
    public:
    HBDimIODevice(uint8_t _devicetype, uint8_t _hardware_version, uint16_t _firmware_version,
               Stream* _rs485, uint8_t _txen,
               uint8_t _configSize, void* _config,
               uint8_t _numChannels, HBWChannel** _channels,
               Stream* _debugstream, HBWLinkSender* linksender = NULL, HBWLinkReceiver* linkreceiver = NULL) :
    HBWDevice(_devicetype, _hardware_version, _firmware_version,
              _rs485, _txen, _configSize, _config, _numChannels, ((HBWChannel**)(_channels)),
              _debugstream, linksender, linkreceiver) {
    };
    virtual void afterReadConfig();
};

// device specific defaults
void HBDimIODevice::afterReadConfig() {
  if(hbwconfig.logging_time == 0xFF) hbwconfig.logging_time = 50;
};

HBDimIODevice* device = NULL;



void setup()
{
  //change from fast-PWM to phase-correct PWM
  // (This is the timer0 controlled PWM module. Do not change prescaler, it would impact millis() & delay() functions.)
  //TCCR0A = _BV(COM0A1) | _BV(COM0B1) | _BV(WGM00);
//  TCCR0A = B00000001; // phase-correct PWM @490Hz
// TODO: fixme - not working! millis() is running two times slower when not in fast-PWM! - interrupt 'issue'
 
 
  // create channels


#if NUMBER_OF_INPUT_CHAN == 12 && NUMBER_OF_SEN_INPUT_CHAN == 12
  static const uint8_t digitalInput[12] = {IO1, IO2, IO3, IO4, IO5, IO6, IO7, IO8, IO9, IO10, IO11, IO12};  // assing pins

  // input sensor and key channels
  for(uint8_t i = 0; i < NUMBER_OF_SEN_INPUT_CHAN; i++) {
    channels[i] = new HBWSenSC(digitalInput[i], &(hbwconfig.senCfg[i]));
    channels[i + NUMBER_OF_SEN_INPUT_CHAN] = new HBWKey(digitalInput[i], &(hbwconfig.keyCfg[i]));
  };
#else
  #error Input channel count and pin missmatch!
#endif



  Serial.begin(115200);  // Serial->USB for debug
  rs485.begin(19200);   // RS485 via SoftwareSerial, must use 19200 baud!
 
  device = new HBDimIODevice(HMW_DEVICETYPE, HARDWARE_VERSION, FIRMWARE_VERSION,
                             &rs485, RS485_TXEN, sizeof(hbwconfig), &hbwconfig,
                             NUMBER_OF_CHAN, (HBWChannel**)channels,
                             &Serial,
                             new HBWLinkKey<NUM_LINKS_INPUT, LINKADDRESSSTART_INPUT>(), NULL);
 
  device->setConfigPins(BUTTON, LED);  // 8 (button) and 13 (led) is the default
  //device->setStatusLEDPins(LED, LED); // Tx, Rx LEDs

  hbwdebug(F("B: 2A "));
  hbwdebug(freeRam());
  hbwdebug(F("\n"));
 
  // show timer register for debug purpose
//  hbwdebug(F("TCCR0A: "));
//  hbwdebug(TCCR0A);
//  hbwdebug(F("\n"));
//  hbwdebug(F("TCCR0B: "));
//  hbwdebug(TCCR0B);
//  hbwdebug(F("\n"));

}


void loop()
{
  device->loop();
  POWERSAVE();  // go sleep a bit
};


XML
<?xml version="1.0"?>
<device eep_size="1024" version="14">
<supported_types>
<type priority="2" id="HMW-Sen-SC-12-DR" name="RS485 12 Digital inputs">
<parameter const_value="0x98" size="1" index="0"/><!--HMW_DEVICETYPE-->
<parameter const_value="1" size="1" index="1"/><!--HARDWARE_VERSION-->
<parameter const_value="0x003C" size="2" cond_op="GE" index="2"/><!--Min. FIRMWARE_VERSION-->
</type>
</supported_types>

<paramset id="HMW-Sen-SC-12-DR_dev_master" type="MASTER">
<parameter id="LOGGING_TIME">
<logical type="float" unit="s" default="5.0" max="25.5" min="0.1"/>
<physical size="1.0" type="integer" interface="eeprom">
<address index="0x0001"/>
</physical>
<conversion type="float_integer_scale" offset="0.0" factor="10"/>
</parameter>
<parameter id="CENTRAL_ADDRESS" hidden="true">
<logical type="integer"/>
<physical size="4" type="integer" interface="eeprom">
<address index="0x0002"/>
</physical>
</parameter>
<parameter id="DIRECT_LINK_DEACTIVATE" hidden="true">
<logical type="boolean" default="false"/>
<physical interface="eeprom" size="0.1" type="integer">
<address index="0x0006"/>
</physical>
</parameter>
<enforce id="CENTRAL_ADDRESS" value="1"/>
<enforce id="DIRECT_LINK_DEACTIVATE" value="true"/>
</paramset>

<frames>
<frame id="LEVEL_SET" type="#x" channel_field="10" direction="to_device">
<parameter size="1.0" index="11.0" type="integer" param="LEVEL"/>
</frame>
<frame id="LEVEL_GET" type="#S" channel_field="10" direction="to_device"/>
<frame id="INFO_LEVEL" type="#i" channel_field="10" direction="from_device" event="true">
<parameter size="1.0" index="11.0" type="integer" param="LEVEL"/>
<parameter size="0.3" index="12.4" type="integer" param="STATE_FLAGS"/>
</frame>
<frame id="OLD_LEVEL" direction="to_device" type="#x" channel_field="10">
<parameter type="integer" index="11.0" size="1.0" const_value="201"/>
</frame>
<frame id="STATE_LEVEL" type="#i" channel_field="10" direction="from_device" event="true">
<parameter size="1.0" index="11.0" type="integer" param="STATE"/>
</frame>
<frame id="KEY_EVENT_SHORT" type="#K" channel_field="10" direction="from_device" event="true">
<parameter const_value="0" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="KEY_EVENT_LONG" type="#K" channel_field="10" direction="from_device" event="true">
<parameter const_value="1" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="KEY_SIM_SHORT" type="#K" channel_field="10" direction="from_device" receiver_channel_field="11">
<parameter const_value="0" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="KEY_SIM_LONG" type="#K" channel_field="10" direction="from_device" receiver_channel_field="11">
<parameter const_value="1" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="SET_LOCK" type="#l" channel_field="11" direction="to_device">
<parameter type="integer" index="12.0" size="1.0" param="INHIBIT"/>
</frame>
<frame id="TOGGLE_INSTALL_TEST" type="#x" channel_field="10" direction="to_device">
<parameter type="integer" index="11.0" size="1.0" param="TOGGLE_FLAG"/>
</frame>
</frames>

<channels>
<channel index="0" type="MAINTENANCE" count="1" class="maintenance" ui_flags="internal">
<paramset id="maint_ch_master" type="MASTER"/>
<paramset id="maint_ch_values" type="VALUES">
<parameter id="UNREACH" ui_flags="service" operations="read,event">
<logical type="boolean"/>
<physical type="integer" interface="internal" value_id="UNREACH"/>
</parameter>
<parameter id="STICKY_UNREACH" ui_flags="service" operations="read,write,event">
<logical type="boolean"/>
<physical type="integer" interface="internal" value_id="STICKY_UNREACH"/>
</parameter>
<parameter id="CONFIG_PENDING" ui_flags="service" operations="read,event">
<logical type="boolean"/>
<physical type="integer" interface="internal" value_id="CONFIG_PENDING"/>
</parameter>
</paramset>
</channel>



<channel index="1" physical_index_offset="-1" count="12" type="SENSOR"> <!-- input sensor contact chan -->
<paramset type="MASTER" id="hmw_sensor_ch_master" address_start="0x07" address_step="1">
    <parameter id="INPUT_LOCKED">
<logical type="boolean" default="false"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.0"/>
</physical>
<conversion type="boolean_integer" invert="true"/>
</parameter>
<parameter id="INVERTED">
<logical type="boolean" default="false"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.1"/>
</physical>
<conversion type="boolean_integer" invert="true"/>
</parameter>
<parameter id="NOTIFY">
<logical type="option">
<option id="ON"/>
<option id="OFF" default="true"/>
</logical>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.2"/>
</physical>
</parameter>
</paramset>

<paramset type="VALUES" id="hmw_sensor_ch_values">
<parameter id="SENSOR" operations="read,event" control="DOOR_SENSOR.STATE">
<logical type="boolean"/>
<physical type="integer" interface="command" value_id="STATE">
<event frame="STATE_LEVEL" auth_violate_policy="reject"/>
<get request="LEVEL_GET" response="STATE_LEVEL"/>
</physical>
</parameter>
<parameter id="INSTALL_TEST" operations="event" ui_flags="internal">
<logical type="action"/>
<physical type="integer" interface="command" value_id="TEST_COUNTER">
<event frame="STATE_LEVEL"/>
</physical>
</parameter>
</paramset>
</channel>

<channel index="13" type="KEY" count="12" physical_index_offset="-1"> <!-- input key chan -->
<link_roles>
<source name="SWITCH"/>
</link_roles>
<paramset id="hbw_input_ch_master" type="MASTER" address_start="0x13" address_step="2">
    <parameter id="INPUT_LOCKED">
<logical type="boolean" default="false"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.0"/>
</physical>
<conversion type="boolean_integer" invert="true"/>
</parameter>
<parameter id="INVERTED">
<logical type="boolean" default="false"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.1"/>
</physical>
<conversion type="boolean_integer" invert="true"/>
</parameter>
<!-- don't allow to change, cause using same IO pins as input sensor contact channels
<parameter id="PULLUP">
<logical type="boolean" default="true"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.2"/>
</physical>
<conversion type="boolean_integer" invert="false"/>
</parameter> -->
<parameter id="INPUT_TYPE">
<logical type="option">
<option id="DOORSENSOR"/>
<option id="MOTIONSENSOR"/>
<option id="SWITCH"/>
<option id="PUSHBUTTON" default="true"/>
</logical>
<physical size="0.2" type="integer" interface="eeprom">
<address index="+0.3"/>
</physical>
</parameter>
<parameter id="LONG_PRESS_TIME">
<logical type="float" unit="s" default="1.0" max="5.0" min="0.4"/>
<physical size="1.0" type="integer" interface="eeprom">
<address index="+1"/>
</physical>
<conversion type="float_integer_scale" factor="10"/>
<conversion type="integer_integer_map">
<value_map to_device="false" from_device="true" parameter_value="10" device_value="0xff"/>
</conversion>
</parameter>
</paramset>

<paramset id="hmw_input_ch_link" type="LINK" channel_param="CHANNEL" peer_param="ACTUATOR" count="20" address_start="0x380" address_step="6">
<parameter hidden="true" id="CHANNEL" operations="none">
<logical type="integer" default="255" max="255" min="0"/>
<physical size="1.0" type="integer" interface="eeprom">
<address index="+0"/>
</physical>
</parameter>
<parameter hidden="true" id="ACTUATOR" operations="none">
<logical type="address"/>
<physical type="array">
<physical size="4.0" type="integer" interface="eeprom">
<address index="+1"/>
</physical>
<physical size="1.0" type="integer" interface="eeprom">
<address index="+5"/>
</physical>
</physical>
</parameter>
</paramset>

<paramset type="VALUES" id="hbw_input_ch_values">
<parameter id="PRESS_SHORT" operations="event" loopback="true" control="BUTTON.SHORT">
<logical type="action"/>
<physical type="integer" interface="command" value_id="COUNTER">
<event frame="KEY_EVENT_SHORT"/>
</physical>
<conversion type="action_key_counter" counter_size="6" sim_counter="SIM_COUNTER"/>
</parameter>
<parameter id="PRESS_LONG" operations="event" loopback="true" control="BUTTON.LONG">
<logical type="action"/>
<physical type="integer" interface="command" value_id="COUNTER">
<event frame="KEY_EVENT_LONG"/>
</physical>
<conversion type="action_key_counter" counter_size="6" sim_counter="SIM_COUNTER"/>
</parameter>
<parameter id="SENSOR" operations="read,event" control="DOOR_SENSOR.STATE">
<logical type="boolean" default="false"/>
<physical type="integer" interface="command" value_id="LEVEL">
<get request="LEVEL_GET" response="INFO_LEVEL"/>
<event frame="INFO_LEVEL" auth_violate_policy="reject"/>
</physical>
<!--<conversion type="boolean_integer" threshold="1" false="0" true="200"/>-->
</parameter>
<!--<parameter id="SENSOR" operations="read,event" control="DOOR_SENSOR.STATE">
<logical type="boolean"/>
<physical type="integer" interface="command" value_id="STATE">
<event frame="STATE_LEVEL" auth_violate_policy="reject"/>
<get request="LEVEL_GET" response="STATE_LEVEL"/>
</physical>
</parameter>-->
<parameter id="INSTALL_TEST" operations="event" ui_flags="internal">
<logical type="action"/>
<physical type="integer" interface="command" value_id="TEST_COUNTER">
<event frame="KEY_EVENT_SHORT"/>
<event frame="KEY_EVENT_LONG"/>
<event frame="INFO_LEVEL"/>
</physical>
</parameter>
</paramset>
</channel>

</channels>
</device>



Die Files und das was in fhem generiert wird befinden sich auch in Anhang.
Sieht jemand den fehler? :)
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 01 August 2021, 20:35:33
Hi,
ist das pm-File generiert worden? Es sollte in /opt/fhem/FHEM/lib/HM485/Devices liegen und so heißen wie das xml, nur mit .pm am Ende. Wenn es nicht da ist, dann mal FHEM durchstarten und auf Meldungen achten. ...oder danach mal ins Logfile schauen.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 01 August 2021, 21:01:14
Ja wurde erstellt. Siehe Anhang
LG
Juri
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 02 August 2021, 20:30:17
Hi,
bei mir gibt es schon standardmäßig ein hmw_sen_sc_12_dr.pm (bzw. ...xml), welches den Eintrag HMW_SEN_SC_12_DR definiert. Der überschreibt wahrscheinlich Deinen. Benenne Dein Device mal um auf irgendwas mit HBW, und zwar vor Allem im XML. (Der Dateiname ist wahrscheinlich egal.)
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 02 August 2021, 21:23:48
Hi Thorsten,

Wurde tatsächlich überschrieben   ;D vielen dank.

Wie doll der nach deine Meinung genannt werden und welche id soll er bekommen?

LG
Juri
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 02 August 2021, 23:03:30
Hab jetzt hbw_sen_sc_12_dr genannt und ID 0x98 vergeben, da es in wiki noch frei steht.

Thorsten kannst du bitte prüfen und in HBW Sammlung mit aufnehmen ?

Gruß
Juri
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 02 August 2021, 23:27:46
Hi Juri,

die Liste im Wiki (https://wiki.fhem.de/wiki/HomeMatic_Wired#Aktoren_.2F_Sensoren) ist schon älter und auch nur eine eingeschränkte Referenz.
Ich hatte 0x98 für den Klingelsensor genommen... Denke man wird mit vielen verschiedenen Homebrew Geräten Konflikte nicht vermeiden können. :)

HBW-Sen-DB-4/HBW-Sen-DB-4.ino:#define HMW_DEVICETYPE 0x98


PS: LINKADDRESSSTART_INPUT und die Startadresse im XML stimmen nicht überein. (zumindest was post #675 betrifft)  ;)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 03 August 2021, 21:34:43
Hi Thomas,

und ich dachte endlich fehlerfreies Script fertig gestellt zu haben:) hab gerade korrigiert.

Welche ID ist frei? :)

Gruß
Juri
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 03 August 2021, 22:49:44
Hi,

gute Frage... wenn man das Wiki hier + die original Devices als nicht verfügbar annimmt, bleibt ja doch einiges frei.  ;)
https://ref.homegear.eu/family.html?familyLink=homematicwired&familyName=HomeMatic+Wired

Vielleicht ab 0xA6 bis 0xAF? Oder 0xC...  ;D

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 04 August 2021, 17:54:17
Super ich nehme. 0xA6 :-)

Was ich noch garnicht durchblicke ist peering, wäre echt super wenn jemand sich noch die Zeit nehmen wurde und das auch noch in Form von Tutorial bisschen detaillierter erklären würde. 😁✌

Gruß
Juri

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 04 August 2021, 19:37:17
Zitat von: aperoap am 03 August 2021, 21:34:43
Hi Thomas,

und ich dachte endlich fehlerfreies Script fertig gestellt zu haben:) hab gerade korrigiert.

Welche ID ist frei? :)

Gruß
Juri

Da stimmt was mit peering nicht, bei Sensoren "Channel configuration" zu sehen, "peering configuration" Button ist leider nicht da.  Unter get  ist "config, peerlist, state" zu sehen.

Stimmt was mit xml nicht ?

GrußJuri
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 04 August 2021, 21:01:00
Hi,

du sprichst von den Kanälen type="SENSOR", basierend auf HBWSenSC?
Wie in der .h Datei vermerkt gibt es kein Peering für diese Kanäle (was auch dem Standard entspricht - soweit mir bekannt). Du kannst auf "Notify" Nachrichten der SENSOR Kanäle reagieren oder die parallel vorhandenen Key Kanäle für Peerings nutzen (input type Doorsensor)

* HBWSenSC.h
*
* sensor/shutter contact
* Query to this type of channel will return "contact_closed" or "contact_open" (bool


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 04 August 2021, 21:21:06
Zitat von: loetmeister am 04 August 2021, 21:01:00
Hi,

du sprichst von den Kanälen type="SENSOR", basierend auf HBWSenSC?
Wie in der .h Datei vermerkt gibt es kein Peering für diese Kanäle (was auch dem Standard entspricht - soweit mir bekannt). Du kannst auf "Notify" Nachrichten der SENSOR Kanäle reagieren oder die parallel vorhandenen Key Kanäle für Peerings nutzen (input type Doorsensor)

* HBWSenSC.h
*
* sensor/shutter contact
* Query to this type of channel will return "contact_closed" or "contact_open" (bool


Gruß,
Thomas

So wie ich verstehe sollte dann bei den keys "peering configuration" vorhanden sein? siehe Anhang. Ist (input type Doorsensor) eingestellt.
Gruß
Juri

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 04 August 2021, 22:40:03
Ja, richtig. Bei "Key" Kanälen sollte Peering gehen. Bei deinem Apparatus Kanal 13 bis 2124, wenn ich das richtig sehe.
Damit der "peering configuration" Button erscheint muss es mindestens ein Peering geben. In der "set" Liste sollte "peer" dabei sein, um ein peering anzulegen.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 04 August 2021, 22:58:50
Hab 12 Kanäle also 13-24. In der SET ist bei mir leider nur config.

Gruß
Juri
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 04 August 2021, 23:07:16
Hi Juri,

in SET muss "peer" stehen. Vermutlich stimmt dann in der XML etwas nicht... so direkt fällt mir aber kein Fehler auf. Eventuell vergleichst du deine XML mit der Vorlagen? (vom Dimmer)
Verhalten sich alle 12 "Key" Kanäle gleich?


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 04 August 2021, 23:15:45
Ich vermute auch dass in xml was nicht stimmt. 13,14,17,20,22,23 haben in der set liste nur config, bei Rest ist die Liste ganz leer.
Gruß
Juri
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 07 August 2021, 09:54:04
Bin seit Tagen dran das peering von den keys hinzukriegen, finde den Fehler noch.

Kann bitte jemand mitschauen?

Aktuelle Fils

ino
//*******************************************************************
//
// hbw_sen_sc_12_dr
//
// DANKSAGUNG:
// Diese Arbeit basiert sich auf HBW-SC-10-Dim-6 und wurde mit Hilfe von Thomas (Mamber FHEM Forum "loetmeister") und
// Tutorial und Hilfe von Thorsten (Mamber FHEM Forum "Thorsten Pferdekaemper") fertiggestellt.
// Hiermit bedanke ich mich bei Thorsten und Thomas für die hervorragende Arbeit mit HomeBrewWired und das Tutorial.
//
// Homematic Wired Hombrew Hardware
// Arduino NANO als Homematic-Device
// 12 digitale Eingänge (Key/Taster & Sensor) & Sensorkontakte
// Diese Arbeit basiert sich auf HBW-SC-10-Dim-6 und wurde mit Hilfe von Thomas (Mamber FHEM Forum "loetmeister") und
// Tutorial und Hilfe von Thorsten (Mamber FHEM Forum "Thorsten Pferdekaemper")
//
// Juri - JARA Armenia


#define HARDWARE_VERSION 0x01
#define FIRMWARE_VERSION 0x003C
#define HMW_DEVICETYPE 0xA6 //device ID (make sure to import hbw_sen_sc_12_dr.xml into FHEM)

#define NUMBER_OF_INPUT_CHAN 12   // input channel - pushbutton, key, other digital in
#define NUMBER_OF_SEN_INPUT_CHAN 12  // equal number of sensor channels, using same ports/IOs as INPUT_CHAN


#define NUM_LINKS_INPUT 20    // address step 6
#define LINKADDRESSSTART_INPUT 0x038   // ends @0x0C7


//#define USE_HARDWARE_SERIAL   // use hardware serial (USART) for final device - this disables debug output
/* Undefine "HBW_DEBUG" in 'HBWired.h' to remove code not needed. "HBW_DEBUG" also works as master switch,
* as hbwdebug() or hbwdebughex() used in channels will point to empty functions. */


// HB Wired protocol and module
#include <HBWired.h>
#include <HBWLinkKey.h>
#include <HBWKey.h>
#include <HBWSenSC.h>


// Pins

  #define RS485_RXD 4
  #define RS485_TXD 2
  #define RS485_TXEN 3  // Transmit-Enable
  #define BUTTON 8  // Button fuer Factory-Reset etc.

  #define IO1 A3
  #define IO2 10
  #define IO3 11
  #define IO4 A0
  #define IO5 A1
  #define IO6 A2
  #define IO7 A4
  #define IO8 A5
  #define IO9 9  // dummy pin to fill the array elements
  #define IO10 7  // dummy pin to fill the array elements
  #define IO11 6
  #define IO12 5

  #include "FreeRam.h"
  #include <HBWSoftwareSerial.h>
  HBWSoftwareSerial rs485(RS485_RXD, RS485_TXD); // RX, TX


#define LED LED_BUILTIN        // Signal-LED

#define NUMBER_OF_CHAN NUMBER_OF_INPUT_CHAN + NUMBER_OF_SEN_INPUT_CHAN


struct hbw_config {
  uint8_t logging_time;     // 0x01
  uint32_t central_address;  // 0x02 - 0x05
  uint8_t direct_link_deactivate:1;   // 0x06:0
  uint8_t              :7;   // 0x06:1-7

  hbw_config_senSC senCfg[NUMBER_OF_SEN_INPUT_CHAN]; // 0x07 - 0x12 (address step 1)
  hbw_config_key keyCfg[NUMBER_OF_INPUT_CHAN]; // 0x13 - 0x2A (address step 2)

} hbwconfig;


HBWChannel* channels[NUMBER_OF_CHAN];  // total number of channels for the device


class HBDimIODevice : public HBWDevice {
    public:
    HBDimIODevice(uint8_t _devicetype, uint8_t _hardware_version, uint16_t _firmware_version,
               Stream* _rs485, uint8_t _txen,
               uint8_t _configSize, void* _config,
               uint8_t _numChannels, HBWChannel** _channels,
               Stream* _debugstream, HBWLinkSender* linksender = NULL, HBWLinkReceiver* linkreceiver = NULL) :
    HBWDevice(_devicetype, _hardware_version, _firmware_version,
              _rs485, _txen, _configSize, _config, _numChannels, ((HBWChannel**)(_channels)),
              _debugstream, linksender, linkreceiver) {
    };
    virtual void afterReadConfig();
};

// device specific defaults
void HBDimIODevice::afterReadConfig() {
  if(hbwconfig.logging_time == 0xFF) hbwconfig.logging_time = 50;
};

HBDimIODevice* device = NULL;



void setup()
{
  //change from fast-PWM to phase-correct PWM
  // (This is the timer0 controlled PWM module. Do not change prescaler, it would impact millis() & delay() functions.)
  //TCCR0A = _BV(COM0A1) | _BV(COM0B1) | _BV(WGM00);
//  TCCR0A = B00000001; // phase-correct PWM @490Hz
// TODO: fixme - not working! millis() is running two times slower when not in fast-PWM! - interrupt 'issue'
 
 
  // create channels


#if NUMBER_OF_INPUT_CHAN == 12 && NUMBER_OF_SEN_INPUT_CHAN == 12
  static const uint8_t digitalInput[12] = {IO1, IO2, IO3, IO4, IO5, IO6, IO7, IO8, IO9, IO10, IO11, IO12};  // assing pins

  // input sensor and key channels
  for(uint8_t i = 0; i < NUMBER_OF_SEN_INPUT_CHAN; i++) {
    channels[i] = new HBWSenSC(digitalInput[i], &(hbwconfig.senCfg[i]));
    channels[i + NUMBER_OF_SEN_INPUT_CHAN] = new HBWKey(digitalInput[i], &(hbwconfig.keyCfg[i]));
  };
#else
  #error Input channel count and pin missmatch!
#endif



  Serial.begin(115200);  // Serial->USB for debug
  rs485.begin(19200);   // RS485 via SoftwareSerial, must use 19200 baud!
 
  device = new HBDimIODevice(HMW_DEVICETYPE, HARDWARE_VERSION, FIRMWARE_VERSION,
                             &rs485, RS485_TXEN, sizeof(hbwconfig), &hbwconfig,
                             NUMBER_OF_CHAN, (HBWChannel**)channels,
                             &Serial,
                             new HBWLinkKey<NUM_LINKS_INPUT, LINKADDRESSSTART_INPUT>(), NULL);
 
  device->setConfigPins(BUTTON, LED);  // 8 (button) and 13 (led) is the default
  //device->setStatusLEDPins(LED, LED); // Tx, Rx LEDs

  hbwdebug(F("B: 2A "));
  hbwdebug(freeRam());
  hbwdebug(F("\n"));
 
  // show timer register for debug purpose
//  hbwdebug(F("TCCR0A: "));
//  hbwdebug(TCCR0A);
//  hbwdebug(F("\n"));
//  hbwdebug(F("TCCR0B: "));
//  hbwdebug(TCCR0B);
//  hbwdebug(F("\n"));

}


void loop()
{
  device->loop();
  POWERSAVE();  // go sleep a bit
};


Xml
<?xml version="1.0"?>
<device eep_size="1024" version="14">
<supported_types>
<type priority="2" id="hbw_sen_sc_12_dr" name="RS485 12 Digital inputs">
<parameter const_value="0xA6" size="1" index="0"/><!--HMW_DEVICETYPE-->
<parameter const_value="1" size="1" index="1"/><!--HARDWARE_VERSION-->
<parameter const_value="0x003C" size="2" cond_op="GE" index="2"/><!--Min. FIRMWARE_VERSION-->
</type>
</supported_types>

<paramset id="HMW-Sen-SC-12-DR_dev_master" type="MASTER">
<parameter id="LOGGING_TIME">
<logical type="float" unit="s" default="5.0" max="25.5" min="0.1"/>
<physical size="1.0" type="integer" interface="eeprom">
<address index="0x0001"/>
</physical>
<conversion type="float_integer_scale" offset="0.0" factor="10"/>
</parameter>
<parameter id="CENTRAL_ADDRESS" hidden="true">
<logical type="integer"/>
<physical size="4" type="integer" interface="eeprom">
<address index="0x0002"/>
</physical>
</parameter>
<parameter id="DIRECT_LINK_DEACTIVATE" hidden="true">
<logical type="boolean" default="false"/>
<physical interface="eeprom" size="0.1" type="integer">
<address index="0x0006"/>
</physical>
</parameter>
<enforce id="CENTRAL_ADDRESS" value="1"/>
<enforce id="DIRECT_LINK_DEACTIVATE" value="true"/>
</paramset>

<frames>
<frame id="LEVEL_SET" type="#x" channel_field="10" direction="to_device">
<parameter size="1.0" index="11.0" type="integer" param="LEVEL"/>
</frame>
<frame id="LEVEL_GET" type="#S" channel_field="10" direction="to_device"/>
<frame id="INFO_LEVEL" type="#i" channel_field="10" direction="from_device" event="true">
<parameter size="1.0" index="11.0" type="integer" param="LEVEL"/>
<parameter size="0.3" index="12.4" type="integer" param="STATE_FLAGS"/>
</frame>
<frame id="OLD_LEVEL" direction="to_device" type="#x" channel_field="10">
<parameter type="integer" index="11.0" size="1.0" const_value="201"/>
</frame>
<frame id="STATE_LEVEL" type="#i" channel_field="10" direction="from_device" event="true">
<parameter size="1.0" index="11.0" type="integer" param="STATE"/>
</frame>
<frame id="KEY_EVENT_SHORT" type="#K" channel_field="10" direction="from_device" event="true">
<parameter const_value="0" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="KEY_EVENT_LONG" type="#K" channel_field="10" direction="from_device" event="true">
<parameter const_value="1" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="KEY_SIM_SHORT" type="#K" channel_field="10" direction="from_device" receiver_channel_field="11">
<parameter const_value="0" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="KEY_SIM_LONG" type="#K" channel_field="10" direction="from_device" receiver_channel_field="11">
<parameter const_value="1" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="SET_LOCK" type="#l" channel_field="11" direction="to_device">
<parameter type="integer" index="12.0" size="1.0" param="INHIBIT"/>
</frame>
<frame id="TOGGLE_INSTALL_TEST" type="#x" channel_field="10" direction="to_device">
<parameter type="integer" index="11.0" size="1.0" param="TOGGLE_FLAG"/>
</frame>
</frames>

<channels>
<channel index="0" type="MAINTENANCE" count="1" class="maintenance" ui_flags="internal">
<paramset id="maint_ch_master" type="MASTER"/>
<paramset id="maint_ch_values" type="VALUES">
<parameter id="UNREACH" ui_flags="service" operations="read,event">
<logical type="boolean"/>
<physical type="integer" interface="internal" value_id="UNREACH"/>
</parameter>
<parameter id="STICKY_UNREACH" ui_flags="service" operations="read,write,event">
<logical type="boolean"/>
<physical type="integer" interface="internal" value_id="STICKY_UNREACH"/>
</parameter>
<parameter id="CONFIG_PENDING" ui_flags="service" operations="read,event">
<logical type="boolean"/>
<physical type="integer" interface="internal" value_id="CONFIG_PENDING"/>
</parameter>
</paramset>
</channel>

<channel index="1" type="SENSOR" count="12" physical_index_offset="-1"> <!-- input sensor contact chan -->
<paramset type="MASTER" id="hmw_sensor_ch_master" address_start="0x07" address_step="1">
    <parameter id="INPUT_LOCKED">
<logical type="boolean" default="false"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.0"/>
</physical>
<conversion type="boolean_integer" invert="true"/>
</parameter>
<parameter id="INVERTED">
<logical type="boolean" default="false"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.1"/>
</physical>
<conversion type="boolean_integer" invert="true"/>
</parameter>
<parameter id="NOTIFY">
<logical type="option">
<option id="ON"/>
<option id="OFF" default="true"/>
</logical>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.2"/>
</physical>
</parameter>
</paramset>

<paramset type="VALUES" id="hmw_sensor_ch_values">
<parameter id="SENSOR" operations="read,event" control="DOOR_SENSOR.STATE">
<logical type="boolean"/>
<physical type="integer" interface="command" value_id="STATE">
<event frame="STATE_LEVEL" auth_violate_policy="reject"/>
<get request="LEVEL_GET" response="STATE_LEVEL"/>
</physical>
</parameter>
<parameter id="INSTALL_TEST" operations="event" ui_flags="internal">
<logical type="action"/>
<physical type="integer" interface="command" value_id="TEST_COUNTER">
<event frame="STATE_LEVEL"/>
</physical>
</parameter>
</paramset>
</channel>

<channel index="13" type="KEY" count="12" physical_index_offset="-1"> <!-- input key chan -->
<link_roles>
<source name="SWITCH"/>
</link_roles>
<paramset id="hbw_input_ch_master" type="MASTER" address_start="0x13" address_step="2">
    <parameter id="INPUT_LOCKED">
<logical type="boolean" default="false"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.0"/>
</physical>
<conversion type="boolean_integer" invert="true"/>
</parameter>
<parameter id="INVERTED">
<logical type="boolean" default="false"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.1"/>
</physical>
<conversion type="boolean_integer" invert="true"/>
</parameter>

<parameter id="INPUT_TYPE">
<logical type="option">
<option id="DOORSENSOR"/>
<option id="MOTIONSENSOR"/>
<option id="SWITCH"/>
<option id="PUSHBUTTON" default="true"/>
</logical>
<physical size="0.2" type="integer" interface="eeprom">
<address index="+0.3"/>
</physical>
</parameter>
<parameter id="LONG_PRESS_TIME">
<logical type="float" unit="s" default="1.0" max="5.0" min="0.4"/>
<physical size="1.0" type="integer" interface="eeprom">
<address index="+1"/>
</physical>
<conversion type="float_integer_scale" factor="10"/>
<conversion type="integer_integer_map">
<value_map to_device="false" from_device="true" parameter_value="10" device_value="0xff"/>
</conversion>
</parameter>
</paramset>

<paramset id="hmw_input_ch_link" type="LINK" channel_param="CHANNEL" peer_param="ACTUATOR" count="20" address_start="0x38" address_step="6">
<parameter hidden="true" id="CHANNEL" operations="none">
<logical type="integer" default="255" max="255" min="0"/>
<physical size="1.0" type="integer" interface="eeprom">
<address index="+0"/>
</physical>
</parameter>
<parameter hidden="true" id="ACTUATOR" operations="none">
<logical type="address"/>
<physical type="array">
<physical size="4.0" type="integer" interface="eeprom">
<address index="+1"/>
</physical>
<physical size="1.0" type="integer" interface="eeprom">
<address index="+5"/>
</physical>
</physical>
</parameter>
</paramset>

<paramset type="VALUES" id="hbw_input_ch_values">
<parameter id="PRESS_SHORT" operations="event" loopback="true" control="BUTTON.SHORT">
<logical type="action"/>
<physical type="integer" interface="command" value_id="COUNTER">
<event frame="KEY_EVENT_SHORT"/>
</physical>
<conversion type="action_key_counter" counter_size="6" sim_counter="SIM_COUNTER"/>
</parameter>
<parameter id="PRESS_LONG" operations="event" loopback="true" control="BUTTON.LONG">
<logical type="action"/>
<physical type="integer" interface="command" value_id="COUNTER">
<event frame="KEY_EVENT_LONG"/>
</physical>
<conversion type="action_key_counter" counter_size="6" sim_counter="SIM_COUNTER"/>
</parameter>
<parameter id="SENSOR" operations="read,event" control="DOOR_SENSOR.STATE">
<logical type="boolean" default="false"/>
<physical type="integer" interface="command" value_id="LEVEL">
<get request="LEVEL_GET" response="INFO_LEVEL"/>
<event frame="INFO_LEVEL" auth_violate_policy="reject"/>
</physical>

</parameter>

<parameter id="INSTALL_TEST" operations="event" ui_flags="internal">
<logical type="action"/>
<physical type="integer" interface="command" value_id="TEST_COUNTER">
<event frame="KEY_EVENT_SHORT"/>
<event frame="KEY_EVENT_LONG"/>
<event frame="INFO_LEVEL"/>
</physical>
</parameter>
</paramset>
</channel>


</channels>
</device>


Gruß
Juri
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: aperoap am 08 August 2021, 17:44:21
Hallo zusammen, hab den Fehler gefunden. Es lag daran dass der hbw_sen_sc_12_d als einziger device in rs485 Netzwerk war. Das peering wird in fhem nur angezeigt, wenn ein Aktor, Welches paaringfähig ist rs485 vorhanden ist.
Somit ist der hbw_sen_sc_12_d komplett funktionsfähig.
Die funktionierenden files noch mal in Abhang.

Gruß
Juri
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 08 August 2021, 21:38:05
Hi Juri,

schön das es nun Funktioniert (und gar kein Problem mit dem Device war)  8)

"LOGGING_TIME" könntest du komplett raus nehmen, das wird nur bei Aktoren genutzt.
Ansonsten würde ich das Device mit ins Github aufnehmen, wenns ok ist?

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 10 August 2021, 22:43:28
Hi,

habe dein Device hinzugefügt.
https://github.com/loetmeister/HBWired/tree/master/HBW-Sen-SC-12-DR

LOGGING_TIME hab ich rausgenommen... dann kann man die Standard "HBWDevice" Klasse verwenden und es wird etwas übersichtlicher.
Damit es konsistent zu den anderen Devices ist, habe ich die hardware serial Option hinzugefügt (USE_HARDWARE_SERIAL). Pins habe ich so gelassen, weiß nicht warum zwei als "dummy pin" bezeichnet sind? Ist das nur ein alter Kommentar? (IO9, IO10)

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 31 Oktober 2021, 18:19:48
Hallo in die Runde...

Nachdem ich nun (endlich) meine Geräte im täglichen Einsatz habe, ist mir ein grundsätzliches Problem (bzw. Gedankenfehler) mit den keyPressNum (Tastendruckzähler) aufgefallen, welcher in den Aktoren genutzt wird um wiederholte lange Tastendrücke zu behandeln.

Ich habe zwei Tasten eines 12-fach Tasters mit Rollo auf/ab belegt (peering). Ein langer Tastendruck startet die Fahrt in die entsprechende Richtung, ein kurzer stoppt den Rollo. Gelegentlich wurden Tastendrücke ignoriert. Im FHEM Event Monitor offenbarte sich, immer wenn die selbe keyPressNum geschickt wurde, wurde der Tastendruck ignoriert, auch wenn es eigentlich eine andere Taste (also ein anderer Kanal) war....  :o
Das Problem könnte auch in anderen Situationen auftreten, wenn z.B. ein Licht von verschiedenen Stellen geschaltet wird oder generell mit mehreren Tastern verknüpft ist.
Eventuell hat jemand anderes dies ebenfalls Beobachtetet?

Darauf hin habe ich die HBWLink... receiveKeyEvent Funktion erweitert, die letzte Absenderadresse und den Quellkanal zu speichern. In dem Fall das nun der selbe Tastendruckzähler / keyPressNum empfangen wird, kann festgestellt werden ob es der vorherige, oder ein anderer Absender war.
So wird im Grunde keyPressNum ignoriert, wenn der Kanal oder das Device gewechselt hat. Für wiederholte lange Tastendrücke kann weiterhin keyPressNum genutzt werden, da der Absender ja gleich bleibt.
So hoffe ich mit wenig zusätzlichem Speicher (vor allem RAM) das Problem gelöst zu haben...
Wenn ich die Devices soweit getestet habe werde ich die Änderungen im Github einchecken.


void HBWLink..xy<numLinks, eepromStart>::receiveKeyEvent(HBWDevice* device, uint32_t senderAddress, uint8_t senderChannel,
                                          uint8_t targetChannel, uint8_t keyPressNum, boolean longPress) {
 
  uint32_t sndAddrEEPROM;
  uint8_t channelEEPROM;
  uint8_t actionType;
  uint8_t data[NUM_PEER_PARAMS +2];  // store all peer parameter (use extra element for keyPressNum & sameLastSender)
 
  data[NUM_PEER_PARAMS] = keyPressNum;
  data[NUM_PEER_PARAMS +1] = false;
 
  if (senderAddress == lastSenderAddress && senderChannel == lastSenderChannel) {
    data[NUM_PEER_PARAMS +1] = true;  // true, as this was the same sender (source device & channel) - sameLastSender
  }
  lastSenderAddress = senderAddress;
  lastSenderChannel = senderChannel;
[...]


Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 31 Oktober 2021, 20:43:31
Hi,
ich habe das nicht beobachtet, aber ich habe auch den Fall nicht, dass ich mehrere Tasten mit demselben Kanal gepeert habe und dann auch noch auf lange Tastendrücke reagiere. Was Du schreibst klingt allerdings plausibel.
Man könnte sich höchstens noch überlegen, ob man den Fall, dass man auf zwei Tasten gleichzeitig drückt, auch beachten muss. Unabhängig davon, ob mit oder ohne Deiner Änderung (oder zumindest fast unabhängig davon) müsste das ja dann so interpretiert werden, als ob immer wieder abwechselnd auf die Tasten gedrückt wird.
...wahrscheinlich ist das dann aber auch wieder ein bisschen pathologisch.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 01 November 2021, 22:00:21
Hi Thorsten,

Danke fürs Feedback.
"auf zwei Tasten gleichzeitig drückt" - bin mir nicht sicher wie und was ich da beachten sollte... der Aktor setzt die Befehle um, die er bekommt - Tasten oder FHEM... da zusätzliche Logik einzubauen scheint mir nicht banal zu sein :)
Was aktuell beim Rollo Aktor passiert: Ich drücke (und halte) Rollo Ab, Rollo fährt. Ein kurzer Druck auf den Zweiten Taster stoppt den Rollo, fährt aber sofort wieder weiter, da Rollo Ab Taste noch gedrückt ist. Wenn man nun Taster Rollo Auf ebenfalls drückt (und hält) kommt im Wechsel Ab und Auf beim Aktor an... man hört die Relais im Wechsel schalten - da meine Motoren eine Anfahrtverzögerung haben fahren sie gar nicht, ist aber in jedem Fall für die Relais ungesund. ;)

Habe die Änderungen mal im Rollo- (Blind), Dimmer- und Schaltaktor (Sw-12 / Sw-8_AdvancedPeering) eingebaut und getestet... funktioniert soweit wie erhofft.
https://github.com/loetmeister/HBWired/commit/c6bcf764ba61370510461c8fcfcccda9872e8917
Pull in dein Repo mache ich die Tage...

Edit: Änderungen sind nun im Master Repository: https://github.com/ThorstenPferdekaemper/HBWired/pull/27

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Thorsten Pferdekaemper am 05 November 2021, 17:57:24
...wie gesagt, der Fall ist wahrscheinlich sowieso ein bisschen pathologisch.
Gruß,
   Thorsten
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusHiba am 05 Februar 2022, 09:15:37
Hallo,

ich wollte HBW-DIS-Key-4 aus https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-DIS-Key-4 (https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-DIS-Key-4) auf meinen Arduino Nano unter der neusten Arduino IDE laden.
Leider kommt folgende Fehlermeldung

Arduino: 1.8.19 (Windows 10), Board: "Arduino Nano, ATmega328P"

HBW-DIS-Key-4:232:2: error: #error enable/define Support_HBWLink_InfoEvent in HBWired.h

#error enable/define Support_HBWLink_InfoEvent in HBWired.h

  ^~~~~

exit status 1

#error enable/define Support_HBWLink_InfoEvent in HBWired.h



Wo liegt der Fehler?

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 05 Februar 2022, 10:29:32
Hallo,

Du müsstest für diese Device einmal die HBWired.h Editieren und das define Support_HBWLink_InfoEvent aktivieren. Also (EDIT "//" vor der) Raute (#) am Anfang der Zeile löschen.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusHiba am 05 Februar 2022, 10:48:37
Ok danke im voraus.
doch leider kommt die Fehlermeldung weiterhin.

Ausschnitt aus HBWired.h


/*
* HBWired.h
*
*  Created on: 19.11.2016
*      Author: Thorsten Pferdekaemper
*/

#ifndef HBWired_h
#define HBWired_h

#include "Arduino.h"
#include "hardware.h"
#include "avr/wdt.h"

#define HBW_DEBUG  // reduce code size, if no serial output is needed (hbwdebug() will be replaced by an emtpy template!)

/* enable the below to allow peering with HBWLinkInfoEventActuator/HBWLinkInfoEventSensor
* sendInfoEvent() will send data to the peered channel (locally or remote) calling setInfo() */
define Support_HBWLink_InfoEvent

// #define Support_ModuleReset  // enable reset comand, to restart module "!!" (hexstring 2121)
#define Support_WDT  // enable 1 second watchdog timer

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 06 Februar 2022, 12:20:37
Hi,

bist du sicher, dass du die richtige HBWired.h Datei geändert hast? Der Standard Arduino Pfad sollte %USERPROFILE%\Documents\Arduino\libraries\HBWired\src sein.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusHiba am 06 Februar 2022, 12:28:15
Ja dort habe ich diese geändert
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 06 Februar 2022, 12:44:31
Hi,

sorry, sehe grad das ich weiter oben geschrieben hatte die Raute zu löschen.... ist natürlich quatsch....  :) War da wohl versehentlich in Bash/Shell Syntax, statt C.  ::)
Es muss
#define Support_HBWLink_InfoEvent
statt
// #define Support_HBWLink_InfoEvent
in HBWired.h stehen.

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusHiba am 06 Februar 2022, 12:54:39
Habe ich auch gemacht da kommen auch Fehlermeldungen in einer anderen Datei von lcd.h
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 06 Februar 2022, 15:58:13
Was für Fehler kommen denn?
Eine "lcd.h" habe ich eigentlich nicht eingebunden. Ich nutze "LiquidCrystal.h". Nutzt du eine andere LCD Bibliothek?

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusHiba am 06 Februar 2022, 16:04:39
sorry falschen Dateinamen.
Im Auszug die Fehlermeldung von der Arduino IDE.


Arduino: 1.8.19 (Windows 10), Board: "Arduino Nano, ATmega328P"





















HBWDisplayLCD.cpp:1:1: error: stray '\357' in program

/*

^

HBWDisplayLCD.cpp:1:2: error: stray '\273' in program

/*

  ^

HBWDisplayLCD.cpp:1:3: error: stray '\277' in program

/*

   ^

In file included from C:\Users\marku\Downloads\HBWired-master\HBWired-master\HBW-DIS-Key-4\HBWDisplayLCD.cpp:9:0:

HBWDisplayLCD.h:1:1: error: stray '\357' in program

/*

^

HBWDisplayLCD.h:1:2: error: stray '\273' in program

/*

  ^

HBWDisplayLCD.h:1:3: error: stray '\277' in program

/*

   ^

In file included from C:\Users\marku\Downloads\HBWired-master\HBWired-master\HBW-DIS-Key-4\HBW-DIS-Key-4.ino:51:0:

HBWDisplayLCD.h:1:1: error: stray '\357' in program

/*

^

HBWDisplayLCD.h:1:2: error: stray '\273' in program

/*

  ^

HBWDisplayLCD.h:1:3: error: stray '\277' in program

/*

   ^

exit status 1

stray '\357' in program



Dieser Bericht wäre detaillierter, wenn die Option
"Ausführliche Ausgabe während der Kompilierung"
in Datei -> Voreinstellungen aktiviert wäre.

Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 06 Februar 2022, 16:31:18
Ok, mit der aktuellen Arduino IDE kann ich das reproduzieren... keine Ahnung was da für ein Zeichen am Dateianfang steht und warum das jetzt ein Problem ist, kann ich nicht nachvollziehen. :)
Lösche mal das erste Zeichen in der ersten Zeile... (vor /*) oder den ganzen Kommentarblock in HBWDisplayLCD.h und HBWDisplayLCD.cpp
Hab eine Änderung eingecheckt, so klappt es auch mit Arduino 1.8.19
https://github.com/loetmeister/HBWired/tree/master/HBW-DIS-Key-4

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: MarkusHiba am 06 Februar 2022, 16:35:22
super vielen Dank für die Hilfe.
Jetzt geht es.
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: loetmeister am 22 Januar 2023, 11:42:21
Hallo,

durch die, zuletzt etwas schwierige Liefersituation von elektronischen Bauteilen, wie z.B. Mikrocontroller, habe ich die Homebrew Lib etwas angepasst, um den ATMEGA 328PB nutzen zu können.
https://github.com/ThorstenPferdekaemper/HBWired
Arduino IDE Boards sind z.B. https://github.com/watterott/Arduino-Boards / https://github.com/MCUdude/MiniCore
Es gibt auch einige Clone mit ATMEGA 328PB welche als Entwicklungsboard genutzt werden können. Bei eigenen Platinen muss das Layout angepasst werden, da der 328PB Zwei zusätzliche IO ports hat.

Edit: Der 328PB scheint auch durch eine Änderung bei den Oszillator Optionen nicht mehr so einfach mit Quarzoszillatoren betreibar zu sein. Die 16 MHz Quarze die am 328P funktioniert haben, waren beim 328PB instabil. Mit 12 MHz Quarzen laufen sie nun bisher ohne reset. Eine neue Funktion CFD - Clock Failure Detection sollte für weitere Sicherheit sorgen... (1 MHz Notfallfrequenz, auch wenn dann der Code zu langsam läuft  ;D )

Gruß,
Thomas
Titel: Antw:Homematic Wired - Homebrew Devices
Beitrag von: Ralf9 am 23 Januar 2023, 11:52:10
Den Mega 2560pro finde ich interessanter, der hat genügend IOs und Speicher.
Ich bau mir damit z.Zt. ein Modul mit 16 key und 8 switch.

Gruß Ralf