Homematic Wired - Homebrew Devices

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

Vorheriges Thema - Nächstes Thema

loetmeister

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

Thorsten Pferdekaemper

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

FUIP

loetmeister

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

loetmeister

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:

  • Open Collector PWM Ausgang (12V)
  • 1-10V Analogausgang
  • 0-10V Analogausgang
  • ? 0-20mA / 4-20mA Analogausgang ? [optional]
  • ? 10 Eingänge Digital IN  ?

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

loetmeister

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

Thorsten Pferdekaemper

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
FUIP

holzwurm83

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

loetmeister

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

Thorsten Pferdekaemper

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
FUIP

holzwurm83

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

loetmeister

#505
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

loetmeister

#506
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

loetmeister

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

Thorsten Pferdekaemper

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


FUIP

Thorsten Pferdekaemper

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
FUIP