Homematic Wired - Homebrew Devices

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

Vorheriges Thema - Nächstes Thema

stephan-221

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

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

stephan-221

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


Thorsten Pferdekaemper

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.
FUIP

stephan-221

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

Thorsten Pferdekaemper

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...
FUIP

stephan-221

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

Thorsten Pferdekaemper

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 (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.
FUIP

stephan-221

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

Ralf9

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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Thorsten Pferdekaemper

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
Könnten wir das dort diskutieren?
Danke&Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

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.
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.
FUIP

BrainHunter

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

stephan-221

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

Thorsten Pferdekaemper

Hi,
es gibt jetzt wieder mal eine neue Version der Lib. Siehe wie üblich hier: 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
FUIP

Thorsten Pferdekaemper

#329
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. 
FUIP