FHEM Forum

Hallo zusammen.

dieser Thread sollte die Fortsetzung aus diesem Homematic Wired-Thread (http://forum.fhem.de/index.php?topic=10607.0) werden.
Hier sollten die Punkte zur Integration des HomeMatic Wired - HMW-LAN-Gateway fortgeführt werden.

Gruß
Dirk

Hallo crazystone,

ich bereite auch grade die Anbindung von 10_HM485.pm an dein 00_HM585_LAN.pm vor.

Dazu bräuchte ich von dir noch ein paar Informationen:

H11,01,eQ3-HMW-LGW,1.0.4,KEQ0360763Sendet das HMW-LGW wenn man es Anspricht, quasi als Begrüßung?
Kannst du mir mal die Infos aus dem Beginn der Telnetsession schicken?

Kommt eine Antwort auf ein "K"?

Gruß
Dirk

Hallo Dirk,

also dann machen wir mal hier weiter, wäre schön, wenn Martin alle Beiträge hierhin umhängt.

Voraussetzung ist eine per Netfinder abgeschaltete LAN-seitige AES-Verschlüsselung. Mein HMW-LGW schickt nur ein


H11,01,eQ3-HMW-LGW,1.0.4,KEQ0360763
S12


Die "11" hinter dem 'H' ist dabei die Sequenznummer, die dann mit dem S hochgezählt wird und beim ersten Befehl denselben Wert wie nach dem 'S' haben muss. Das geht aus mgernoths pcap hervor.

Die "01" steht für Status 'ok'.

Das "eQ3-HMW-LGW" ist offensichtlich der Name.

Das "1.0.4" ist die Version im Auslieferungszustand. Ich weiß inzwischen, dass mit der CCU2 eine 1.0.5 mitgeliefert wird. Die habe ich mittlerweile auch per Netfinder upgegradet. Jetzt meldet es die "1.0.5".

Danach kommt offensichtlich das Serial. In meinem Code habe ich das gleich als hmPairSerial Attribut übernommen, genau auch wie die restliche Information.

In meinem Code von HM485_LAN, habe ich danach analog zum pcap von mgernoth einen Transparenzbefehl gesendet:


>12 ,0000


Der wird auch bei mgernoth nicht acknowledged.

Danach wird in meinem Modul das KeepAlive geschrieben, identisch zu HMLAN. martinp876 gebührt hier die Ehre des Protokollverstehers:


HMLAN_SimpleWrite($hash,sprintf('%c%c%c%s',0xfd,length($msg)+1,$hash->{msgNo}++,$msg));


also "fd <length> <msgNo> <msg>" danach wird dann noch die Checksumme automatisch ergänzt. Wenn ich dann als KeepAlive ein "K" sende, sieht das Ergebnis im sniff identisch aus zu der Kommunikation aus dem pcap von mgernoth zwischen CCU2 und HMW-LGW.

Leider bekomme ich bei mir keine Antwort 0x61 0x00 (="a.") wie im pcap von mgernoth. Ehrlich gesagt, kommt bei mir aus dem HMW-LGW gar nichts mehr zu diesem Zeitpunkt. Der TCP Port wird aber nicht geschlossen. Auf TCP Ebene sieht man, dass die Meldungen bestätigt werden. Es kommen aber keine Meldungen mehr mit tcp.flags.push == 1 vom HMW-LGW.

Hier nochmal letztes pcap und das Modul HM485_LAN.pm

Viele Grüße
Thorsten

ZitatDie "01" steht für Status 'ok'.

Hast du noch einen anderen Status gesehen?

ZitatDas "eQ3-HMW-LGW" ist offensichtlich der Name.

Das ist der Interface-Name. der HMLAN heist hier "HHM-LAN-IF"

ZitatDanach kommt offensichtlich das Serial. In meinem Code habe ich das gleich als hmPairSerial Attribut übernommen, genau auch wie die restliche Information.

Das ist "nur" die Text-Seriennummer.
Die wird für das Pairing nicht verwendet. Die HMW-Geräte werden nur mit der 8-stellingen HEX Seriennummer mit einander gepeert. Die Zentrale (CCU) hat die 00000001 als Seriennummer ich Vermute das HMW-LGW hat keine eigene HW-Seriennummer, oder wir sehen die hier noch nicht. Ich denke das wird nur die Software setzen. Meinem Kenntnisstand zufolge können die "Zentralen" die ersten 255 Seriennummern verwenden. Also 00000001 - 0000000FF

Da man eine Installation von einer CCU1 zu einer CCU2 wohl ohne Probleme umziehen kann, wird das HMW-LGW wohl auch mit 00000001 als HW-Seriennummer Nachrichten versenden und beantworten.

Gruß
Dirk

Kleinen Fehler habe ich gerade noch gesehen und behoben (neues letztes pcap anbei). In der Transparenzmeldung hatte ich noch ein überflüssiges Leerzeichen kodiert. Trotzdem keine ACK Rückmeldung.

Danke Dirk für Deine Rückmeldung. Ich bin momentan immer noch am Ende meines Lateins. Ich werde mal versuchen irgendwelche Kommandos zu senden, einfach um irgendeine Reaktion zu sehen. Vorschläge?

Viele Grüße
Thorsten

Achso und noch zum Status: ich habe noch keinen anderen Status gesehen, die Information ist aber deckungsgleich (bis auf die IP-Adressen und Gateway-Info) wie das was Netfinder über den UPD Service Port 43439 liefert. Und da wird unter "Erreichbarkeit" "Ok" angezeigt.

Gruß

Hi,

Zitat von: crazystone schrieb am Mo, 02 September 2013 22:45Kleinen Fehler habe ich gerade noch gesehen und behoben (neues letztes pcap anbei). In der Transparenzmeldung hatte ich noch ein überflüssiges Leerzeichen kodiert. Trotzdem keine ACK Rückmeldung.

Ja, das gehörte da nicht hin. Dir fehlt noch das CRNL (0x0d 0x0a -> \r\n) nach dem Transparenzbefehl, ich schätze, dass das Gateway noch auf das Ende des Transparenzbefehls wartet.

Gruß
  Michael

Hi Michael,

danke für den Hinweis. Zu dem 0x0d 0x0a wollte ich auch gerade Dirk fragen, ob er eine CRC16 Perl Funktion hat. Man braucht ja die Checksumme am Ende jedes RS-485 Busbefehls. Auf die Schnelle habe ich das nicht im 10_HM485.pm gefunden?!

Das CRNL hatte ich ehrlich gesagt rausgenommen, weil ich es im alten pcap nicht gesehen hatte. martinp876 hatte das ja zerlegt. Wo siehst Du das im pcap?

Viele Grüße
Thorsten

ZitatZu dem 0x0d 0x0a wollte ich auch gerade Dirk fragen, ob er eine CRC16 Perl Funktion hat.

Ja, schau mal in das Modul was ich dir geschickt habe.

Ich vermute aber das die CRC-Berechnung das HMW-GW selber macht. Daher denke ich nicht, dass man die hier mitsenden muss.
Ich denke die CRC geht nur über den Bus. Zumindestens ist das bei allen Implementationen so, die ich bisher gesehen habe.

Gruß
Dirk

HEUREKA!!!

Es redet mit mir! Die Checksumme (oder bzw. das 0x0d 0x0a) am Ende jedes KeepAlive haben gefehlt. Das wars! Anbei das aktuelle pcap. Das "/r/n" muss ich tatsächlich weglassen.

Es geht weiter! Sorry, wenn ich hier etwas länger brauche und so manchen Nachtritt...

Hi,

Glückwunsch :-)

0x0d 0x0a ist einfach ein Zeilenumbruch (Enter), keine Checksumme.

Gruß
  Michael

Cool,

Dann schau doch mal ob ein Telnet die ein Paar Messages auswirft wenn auf dem Bus was los ist.

Jetzt bräuchte ich mal wieder einen Tipp von martinp876: das HMLAN_Parse wird leider nicht mit jedem Acknowledge aufgerufen, warum? Ist das, was das HMW-LGW da sendet aus irgendeiner Syntax Sicht unvollständig?

Danke!
Thorsten

Mir scheint das HMLAN Modul wartet in der HMLAN_ReadAnswer Funktion darauf, dass das Gerät eine Meldung sendet, die mit "\r\n" endet. Das ist leider nicht der Fall beim HMW-LGW (siehe pcap).

Morgen geht's weiter. Gute Nacht!
Thorsten

Nochmals zur Zusammenfassung. Das HMW-LGW sendet zuverlässig Antworten auf das KeepAlive, wenn man die Kommandos im Transparenzmode mit "\r\n" abscließt. Es schickt aber selbst kein "\r\n". Anbei nochmals ein aktuelles pcap, mit der Kommunikation, gefiltert auf IP und tcp.flags-push==1.

Aus eigener Dummheit gelernt habe ich jetzt auch das "\r\n" an das Transparenzkommando gehängt. Und siehe da, ich sehe RS-485 Busverkehr (siehe pcap). Ich habe einen Jalousieaktor HMW-LC-Bl1-DR, den habe ich ein paar mal hoch und runter gedrückt. Die Messages sind enthalten, zuordnen kann ich sie leider nicht. Aber Dirk, vielleicht kannst Du ja was damit anfangen (P.S.: wenn du noch wired Jalousieaktoren brauchst, ich habe voraussichtlich zwei übrig, denn ich werde stattdessen ein IO Modul brauchen).

Ich muss mich jetzt dringend an das Parse machen. Jede Hilfe oder Empfehlung ist dabei willkommen. Problem ist, dass der HMW-LGW nicht wirklich ein Ende-Zeichen sendet, so dass die Lesefunktion kein Abbruchkriterium hat, bevor Parse aufgerufen wird.

Naja, ich versuch mal weiter.
VG
Thorsten

Hi Thorsten,

Könntest du die Messages auch mal in der Telnet mitschneiden.
Das lesen der der pcap-Dateien per Wireshark finde ich irgendwie antrengend, und ich habe her ausser der "Welcome Message" nix weiter gefunden.

ZitatIch muss mich jetzt dringend an das Parse machen.

Das musst du nicht mal. Das HM485_LAN-Modul muss nur mit dem Gateway sprechen und die Nachrichten an HM485 weiterreichen. Das Verarbeiten wird dann darin passieren. Es reicht hier aus, wenn du sinnvolle RAW-Nachrichten bekommst und diese auch über das Gateway versenden kannst, so dass das Device hier auch was macht.

Zitat(P.S.: wenn du noch wired Jalousieaktoren brauchst, ich habe voraussichtlich zwei übrig, denn ich werde stattdessen ein IO Modul brauchen).

Danke für das Angebot. Ich habe hier aber auch einen Jalousieaktor stehen.

Gruß
Dirk

Hallo zusammen,

vielleicht kann mir jemand helfen - wäre sehr dankbar!

Ich habe in jedes Zimmer 2 Cat Kabel als Signalkabel gelegt.
Ausserdem ist jedes Gerät, welches ich schalten will, direkt
im Schaltkasten aufgelegt.

Geräte sind derzeit elektrische Rollläden, Lampen und Steckdosen.
Später evtl. noch Heizungssteuererung.
Es soll die Fritz!Box zum Einsatz kommen.

Könnte mir jemand nun eine "Einkaufsliste" mailen, was ich alles
bestellen soll / muss? Wäre super, denn ich blicke nicht mehr
durch, welche Hardware nun sinnig ist und welche Stromversorgung,
Abschluss etc. etc.

Wie auch immer: danke!

Gruss,
Tomili

Hallo Tomili,

Für Lampen, sofern die zusammen nicht mehr als 16A verbrauchen: HMW-IO-12-Sw7-DR (//www.elv.de/homematic-wired-rs485-i-o-modul-12-eingaenge-7-schaltausgaenge-1.html)
Für Steckdosen empfiehlt sich ein HMW-LC-Sw2-DR (//www.elv.de/homematic-wired-hmw-lc-sw2-dr-rs485-schaltaktor-2fach.html). Aber auch hier die Max. Anschlußleistung beachten.
Für Rolläden kann man ein HMW-LC-Bl1-DR (//www.elv.de/homematic-wired-hmw-lc-bl1-dr-wired-rs485-rollladenaktor-1fach.html) verwenden.

Bei der Heizung muss man schauen was für ein Heizungstyp das ist. Fussbodenheizung oder "normal".
Ggf. muss man hier auf die Homematic-Funk Lösung zurück greifen. Bei einer Fußbodenheizung kann man zumindest die Ventile mit dem oben genannten HMW-IO-12-Sw7-DR schalten.

Als Schnittstelle zu Fritzbox funktioniert z.B. so was:
http://www.reichelt.de/USB-Konverter/DIGITUS-DA-70157/3//index.html?ARTICLE=122187 (//www.reichelt.de/USB-Konverter/DIGITUS-DA-70157/3//index.html?ARTICLE=122187)
oder Link (http://forum.fhem.de/index.php?topic=14096.0)
oder später auch das Wired RS485 LAN Gateway (//www.elv.de/homematic-rs485-gateway-1.html). Hier ist die Integration aber noch in Arbeit.

Als Hutschinennetzteil geht z.B. sowas hier (//www.elv.de/mean-well-hutschienennetzteil-dr-60-24-24v.html).
Evtl. Noch ein Überspannungsschutz mit integrierten Busabschluss (//www.elv.de/homematic-wired-rs485-ueberspannungsschutz.html)

Gruß
Dirk

Hi Thorsten,

Kannst dm mal folgendes machen:

- FHEM mit deinem Modul starten (wegen der Initialisierungssequenz für das HMW-LAN-GW)
- FHEM wieder beenden
- Bissl Verkehr auf dem Bus erzeugen: mit den Eingänge von HMW-Geräten spielen.
- in der Konsole folgendes eingeben:
echo  K | nc <IP-DEINES-HMW-LAN-GW> 1000
- die Ausgabe hier posten :)

Gruß
Dirk

Update: ein Punkt in der Liste vergessen

Hallo Dirk,

du stellst mich da vor physische Herausforderungen. Wenn ich das Gerät aus FHEM lösche und damit keine KeepAlive gesendet werden, dann wird mE nach 30s der TCP Port geschlossen. In dieser Zeit in den Keller laufen, den Busverkehr erzeugen, wieder hochlaufen und den screenshot sichern, überfordert mich etwas. ZUdem ist mir nicht klar, wie du aus der 'telnet' Konsolenausgabe die Hex-Sequenz sehen kannst?

Lieber kopiere ich Dir nochmals aus obigem pcap die Daten, die nicht dem KeepAlive zuzuordnen sind heraus. Es waren 4 zusätzliche Messages, alle durch wildes Herumdrücken am Jalousie-Aktor erzeugt:


fd:0f:04:65:ff:ff:ff:ff:fe:00:00:9d:bd:69:02:15:10
fd:0f:05:65:ff:ff:ff:ff:f8:00:00:9d:bd:69:02:12:20
fd:0f:06:65:ff:ff:ff:ff:fa:00:00:9d:bd:69:02:00:20
fd:0f:08:65:ff:ff:ff:ff:fe:00:00:9d:bd:69:02:00:00


Hoffe das hilft!
Viele Grüße
Thorsten

Hi Thorsten,

Wenn das HMW-LAN-GW wie das HMLAN arbeitet, dann sollte es den Busverkehr buffern wenn keine Gegenstelle die Nachrichten "abholt".
Also sollte es klappen, dass du FHEM kurz startest, wieder stoppst, gemütlich in den Keller gehst, bissl "rumdrückst" und nach dem wieder nach oben kommen den obrigen Befehl ausführst.

Währ nur interessant zu wissen was wirklich als "Text" ankommt.

Gruß
Dirk

So ich habe es jetzt! Dank martinp876 habe ich jetzt doch deutlich mehr vom HMLAN verstanden und nochmals einiges umgeschmissen und deutlich vereinfacht. Ich nutze bisher nur die Funktionen


sub HMLAN_DoInit($);
sub HMLAN_Read($);
sub HMLAN_485Write($$);
sub HMLAN_SimpleWrite(@);
sub HMLAN_Parse($$);
sub HMLAN_KeepAlive($);
sub HMLAN_KeepAliveCheck($);


Die Read-Funktion hat fast keinerlei Prüfung mehr, fängt nur noch incomplete messages ab. Die Funktion Parse unterscheidet zwischen der Initialisierungssequenz "H<xx>..S<xx+1>\r\n" und den transparenten Hex-Messages mit flag "fd" (oder "fe"). Das KeepAlive wird richtig initialisiert und gesendet, das entsprechende ACK abgefangen und richtig interpretiert.

Sollte eine andere RS-485 Busmessage daherkommen, wird diese als Hex-String ausgegeben. Kurzer Auszug mit loglevel 1:


2013.09.04 21:26:04 3: Opening HM485LAN device 192.168.178.37:1000
2013.09.04 21:26:04 3: HM485LAN device opened
2013.09.04 21:26:04 1: HM485_Parse: SeqNo: 3d   Type:eQ3-HMW-LGW,  Serial:KEQ0360763   Version:1.0.5
2013.09.04 21:26:04 1: HM485_Parse: SeqNo: 3e   Send: >3e,0000
2013.09.04 21:26:29 1: HM485_KeepAlive: msgNo: 0
2013.09.04 21:26:29 1: HM485_Parse: HM485LAN ACK response to KeepAlive msgNo: 0
2013.09.04 21:26:54 1: HM485_KeepAlive: msgNo: 1
2013.09.04 21:26:54 1: HM485_Parse: HM485LAN ACK response to KeepAlive msgNo: 1
2013.09.04 21:27:19 1: HM485_KeepAlive: msgNo: 2
2013.09.04 21:27:19 1: HM485_Parse: HM485LAN ACK response to KeepAlive msgNo: 2
2013.09.04 21:27:35 1: HM485_Parse: HM485LAN unknown msgNo: >>fd0f0965fffffffff800009dbd69020810<<
2013.09.04 21:27:44 1: HM485_KeepAlive: msgNo: 3
2013.09.04 21:27:44 1: HM485_Parse: HM485LAN ACK response to KeepAlive msgNo: 3
2013.09.04 21:27:58 1: HM485_Parse: HM485LAN unknown msgNo: >>fd0f0a65fffffffffa00009dbd69020400<<
2013.09.04 21:28:09 1: HM485_KeepAlive: msgNo: 4
2013.09.04 21:28:09 1: HM485_Parse: HM485LAN ACK response to KeepAlive msgNo: 4
2013.09.04 21:28:34 1: HM485_KeepAlive: msgNo: 5
2013.09.04 21:28:34 1: HM485_Parse: HM485LAN ACK response to KeepAlive msgNo: 5


Alles getestet und funktioniert mit meinem LGW ganz gut und stabil. Zerhackte Messages habe ich noch nicht wirklich testen können. Re-Synch dürfte kaum funktionieren. Beim Abklemmen der LAN-Verbindung schließt KeepAliveCheck die Verbindung. Ein reappear funkioniert momentan allerdings noch nicht.

@Dirk, wie geht es jetzt weiter? Welche Funktion muss ich implementieren, damit Du vom HM485 Device das HM485_LAN mit Raw Messages aufrufen kannst? Wo und wie muss ich die empfangenen Busmessages ablegen, damit ein entsprechendes Device es sieht?

Viele Grüße
Thorsten

Zitatwie geht es jetzt weiter?

Wenn das was du vorhin geschickt hast, wirklich die reine Textnachricht ist, dann sieht die Zuordnung so aus:


Startzeichen
|  ???
|  |  Vielleicht irgendein Counter
|  |  |  e ???
|  |  |  |      Zieladresse
|  |  |  |       |      Kontrollzeichen
|  |  |  |       |      |       Absenderadresse
|  |  |  |       |      |       |          Nutzdaten
|  |  |  |       |      |       |          |
-- -- -- -- ----------- -- ----------- -----------
fd:0f:04:65:ff:ff:ff:ff:fe:00:00:9d:bd:69:02:15:10

Keine Ahnung warum die einzelnen Bestandteile der Nachricht von der Reihenfolge nach von den Nachrichten wie sie über den Bus gehen abweichen.
Als Zieladresse ist hier FFFFFFFF angegeben. Ich vermute deine Rolladenaktoren sin noch nicht gepeert. Dann werden alle Informationen an die Broadcastadresse gesendet Diese ist FFFFFFFF.
Das erte Byte 69 aus den Daten ist der "Befehl". 69 ist ein I. (Info).

Ich baue Gerade die Schnittstelle zu HM485_SERIAL neu. Und da hätte ich gerne die selbe Schnittstelle verpasst.
Daher müssen wir noch ein Paar Informationen herausbekommen.
Vor allem was für "Befehle" an das GW gesendet werden müssen

Deine Aufgabe könnte es jetzt erstmal sein, das Modul soweit zu bauen, dass das HM485-Modul mit diesem "sprechen" kann.
Das einfachste sollte erstmal sein, das die Plaintext Nachrichten im Logfile von FHEM landen.

Gruß
Dirk

Ok, Dirk, ich habs wirklich versucht, bin aber gescheitert (und das war auch genug Sport für heute :-).

Habe Folgendes gemacht
- define HM485LAN HMLAN 192.168.178.37:1000 in FHEM
- Abwarten der Initialisierungssequenz (geht quasi sofort)
- delete HM485LAN in FHEM, damit TCP Port 1000 freigegeben wird
- putty auf 192.168.178.37:1000 --> Initialisierungssequenz
- in den Keller gerannt und gedrückt
- beim wieder Hochkommen war das Fenster schon wieder zu, bzw. beim zweiten Mal ("Close window on exit: Never") die TCP-Verbindung beendet ohne dass ich noch zusätzlichen Inhalt sehen konnte, das heißt auch keine Befehlseingabe mehr möglich

Aber was erhoffst Du Dir davon? Die Darstellung der Hex-Sequenz oben als ASCII Zeichen? Das kannst Du doch nicht mehr interpretieren?

Ich muss wohl noch viel lernen...

Ok, noch kurze Interpretation aus dem bisher Gelernten. Die Nachrichten gehen so als Byte Messages rein, weswegen eine Darstellung als String immer schwierig ist. WireShark zeigt also genau auch diese Byte-Sequenz. Zu den Inhalten:


Startzeichen FD (hab noch kein FE gesehen)
|  Länge der Nachricht inkl. MessageCounter
|  |  MessageCounter, wird mit jedem KeepAlive oder anderer Message hochgezählt, rollover bei ff --> 00, startet nach Transparenzbefehl mit 00
|  |  |  e ???
|  |  |  |      Zieladresse
|  |  |  |       |      Kontrollzeichen
|  |  |  |       |      |       Absenderadresse
|  |  |  |       |      |       |          Nutzdaten, könnte das der Jalousie-Aktor-Status sein?
|  |  |  |       |      |       |          |
-- -- -- -- ----------- -- ----------- -----------
fd:0f:04:65:ff:ff:ff:ff:fe:00:00:9d:bd:69:02:15:10


Also Schreiben der RS-485 Bus-Messages ins fhem-Log ist quasi schon fertig. Soll ich es als Byte-Sequenz reinschreiben oder als Hex-String? Da schreiben natürlich aber auch noch andere Module rein, fängst Du das ab? Wie machen ander Module die Übergabe (z.B. CUL --> CUL_HM)?

Gruß
Thorsten
Gruß

ZitatAber was erhoffst Du Dir davon?

Zu verstehen wie das Teil kommuniziert.
Die Kommunikation mit dem HMLAN erfolgt über Textnachrichten

Und die hätte ich gerne mal gesehen damit ich die Schnittstelle zum HM485_SERIAL genau so bauen kann.

Damit Putty nicht zu geht kannst du unter "Session" "Close Window on exit" z.B. auf "Never" stellen.

Gruß
Dirk

ZitatLänge der Nachricht inkl. MessageCounter

Die Nachricht währ aber 16 Zeichen lang. Also sollte hier 10 stehen.
Oder wird das Startzeichen nicht mit gezählt? Hast du noch Messages von anderen Geräten? ein 12-7-IO vielleicht. Zumindest dieser Sendet ungepeer noch mehr Informationen.

Ich habe mir das das Pcap-File im Wireshark noch mal angesehen. Da habe ich deine Nachrichten auch gefunden.
Die Werden also binär gesendet. Dann werde ich meine Schnittstelle mal entsprechend anpassen.

Du könntest auch mal ein set RAW oder so einbauen. Dazu kannst du dir mal mein HM485_SERIAL ansehen.
Dann könnte man mal versuchen auch Nachrichten auf den Bus zu senden.

Das 0x65 (e) ist vermutlich das "Steuerzeichen" für die Kommunikation Zwischen GW und Zentrale
e könnte hier für "Empfangen" stehen. Beim HMLAN ist das ein E.
Befehle würde ich dann also im selben Messageformat schicken. an der Stalle vom e dann ein s (0x73)

Gruß
Dirk

Hatte ich beim zweiten Versuch gemacht, aber trotzdem nicht geschafft. Der Socket geht ohne KeepAlive einfach zu.

Aber die Byte-Messages sehen so aus wie oben, ich kann die jetzt entweder als Text (nicht entzifferbare Zeichenfolge) oder als Hex-String ins Log schreiben, kein Problem.

Kannst Du bitte noch ein wenig die geplante weitere Vorgehensweise erläutern? Soll das HM485_LAN noch ein discovery auslösen, damit du mit HM485 autocreate dann die sich meldenden Geräte anlegen kannst? Wie würde eine Raw Message dafür aussehen?

Welche Funktionen werden dann benötigt für die bidirektionale raw Kommunikation?

Gruß
Thorsten

ZitatDer Socket geht ohne KeepAlive einfach zu.

Ja, das ist klar.
Ich hatte gehofft die "gespeicherten" Nachrichten zu sehen.

Zitatich kann die jetzt entweder als Text (nicht entzifferbare Zeichenfolge) oder als Hex-String ins Log schreiben, kein Problem.

Für das Log ist Hex sicher besser zu lesen.

ZitatKannst Du bitte noch ein wenig die geplante weitere Vorgehensweise erläutern?

Zuerst würde ich auf deiner Seite eine einfache RAW-Kommunikation bauen.
Z.B. ein Set RAW 0a0b0c0d... sendet die entsprechenden binärdaten an das GW. Anders herum wird das erstmal als Hexwerte ins Logfile geschrieben.

ZitatSoll das HM485_LAN noch ein discovery auslösen

Ich vermute das GW macht den Discovery selber. Das das ganze recht Zeitintensiv ist. Ich vermute muss ein spezieller Befehl ans GW geschickt werden. Das GW wird dann die gefundenen Informationen zurück senden.

Der erste Schritt sollte aber sein erst einmal RAW Nachrichten senden zu können. Damit kann man dann weiter experimentieren.

Wenn das klappt, kommt das Modul HM485 ins Spiel. Das wird dann die Gerätespezifischen Funktionen abhandeln. Incl. autocreate usw.
HM485_LAN und HM485_SERIAL sind also nur die Kommunikationsschnittstelle zur Hardware.

Gruß
Dirk

Das Startzeichen wurde auch beim KeepAlive und anderen Kommandos im alten pcap von mgernoth nicht mitgezählt.

Andere Geräte habe ich leider (noch) nicht.

Bei den geloggten Messages hätte ich jetzt eher die transparenten und unveränderten Messages vom Jalousie-Aktor gesehen. Erklären kann ich sie aber natürlich nicht.

Im alten pcap von mgernoth wird "S" zum Senden verwendet (0x53).

Gruß
Thorsten

ZitatIm alten pcap von mgernoth wird "S" zum Senden verwendet (0x53).

Ja und E für Empfangene Nachrichten. Da es hier aber noch ein uneklärtes kleines "e" gibt, würde ich anstelle des e ein kleines s für zu sendende Nachrichten vermuten.

Daher Baue mal das set RAW ein, damit man Nachrichten senden kann.

Hallo Dirk,

also ich habe mit meiner "set raw" Funktion den Befehl "01" (also binär und voll kodiert fd:02:xx:01:0d:0a mit xx aktueller msgNo) an den HMW-LGW gesendet. Der meldet sich darauf hin mit binär "61 02" (also fd:03:xx:61:02). Das scheint so eine Art Acknowledge (oder vielleicht Reject?) auf den Befehl zu sein. Eine discovery (also Meldung der Seriennummer oder Adresse) kommt aber auch nach längerem Warten nicht.

Auf die 0x64 bzw. (weil ich nicht sicher war) auch dezimal 64 = 0x40 kommt auch jeweils nur die "0x61 0x02" zurück.

Alle Versuche mit FE als Startbyte haben keinerlei Antwort geliefert.

Die direkten Steuerbefehle fd:0e:FF:00:xx:xx:xx:xx:98:00:00:00:00:78:0C:01 konnte ich nicht ausprobieren, weil ich die Adresse meines Jalousieaktors ja noch nicht kenne.

Viele Grüße

Zitatweil ich die Adresse meines Jalousieaktors ja noch nicht kenne.

Drücke mal die Tasten am Aktor bzw. mal einen Taster an einem der Eingänge und schick mir die Nachricht vom Bus. Darin sollte die Adresse vom Aktor sein.

Gruß
Dirk

Schau mal weiter oben im Thread, da hatte ich ja die Messages schon gepostet. Ist 00:00:9d:bd die Adresse, oder? Der Befehl war an einen IO, ich habe aber nur den Jalousieaktor. Hast Du da auch mal noch einen Befehl zum testen?

Gruß
Thorsten

Also hier noch etwas für die Befehlsbibliothek:

Wenn ich am Jalousie-Aktor (HMW-LC-Bl1-DR) den Knopf "runter" drücke, erscheint erst die erste, zeitlich verzögert dann die zweite Meldung auf dem Bus, gefühlt eine "ich fahre runter" --> "ich bin unten" Abfolge. Während des runterfahrens blinkt dabei die LED am Aktor


2013.09.14 13:28:00 1: HM485_Parse: >>fd0f1465fffffffffe00009dbd69020020<<
2013.09.14 13:28:06 1: HM485_Parse: >>fd0f1565fffffffff800009dbd69020000<<


Beim Knopf-Kommando "nach oben" erscheint auf dem Bus:


2013.09.14 13:30:37 1: HM485_Parse: >>fd0f1665fffffffffa00009dbd69020810<<
2013.09.14 13:31:32 1: HM485_Parse: >>fd0f1765fffffffffc7c00009dbd6902c800<<


Mit der letzten Meldung hab ich so meine Probleme, mir scheint es desöfteren vorzukommen, dass Byte-Längen nicht stimmen. Kann das mit einer Umkodierung des Byte-Protokolls zusammenhängen? Da war doch irgendetwas "wenn ein FD im Message-Inhalt steht, dann wird das kodiert als ...". Denn mir scheint ehrlich gesagt das "...fc7c..." etwas deplaziert. Könnte das ein "...fd..." gewesen sein?

Bei einer Versuchswiederholung sah das Ganze dann so aus:


2013.09.14 13:44:37 1: HM485_Parse: HM485LAN unknown msgNo: >>fd0f1865fffffffffe00009dbd6902c810<<
2013.09.14 13:44:43 1: HM485_Parse: HM485LAN unknown msgNo: >>fd0f1965fffffffff800009dbd6902c800<<


Gruß
Thorsten

Gefunden:

ZitatStartzeichen
Das Startzeichen ist immer 0xFD. Es ist ein Steuerzeichen und darf in den restlichen Daten der Nachricht nicht mehr vorkommen. Neben 0xFD gibt  es noch 0xFE als weiteres Steuerzeichen. Dieses spielt bei der normalen Kommunikation keine Rolle, darf aber ebenfalls nicht im Datenstrom enthalten sein. Falls diese Steuerzeichen in den Daten enthalten sind, wird ein weiteres Steuerzeichen (0xFC) eingefügt, das vor ein Steuerzeichen zu setzen ist und selbstverständlich ebenfalls nicht im Datenstrom vorkommen darf. Dieses Steuerzeichen wird als Escape-Zeichen bezeichnet.
Muss jetzt der Sender innerhalb der Daten eines dieser drei Steuerzeichen übertragen, wird das Steuerzeichen durch zwei Bytes ersetzt, und zwar durch das Escape-Zeichen, gefolgt von dem zu sendenden Steuerzeichen, bei dem das höchstwertige Bit gelöscht ist.
Beispiel:
Es sollen die Datenbytes 0x05 0xFD und 0xFA übertragen werden. Das erste Byte wird einfach übertragen, das zweite Byte entspricht einem Steuerzeichen und wird entsprechend ersetzt und das dritte Byte wird wieder normal übertragen. Die Daten: 0x05 0xFD 0xFA werden also gesendet als 0x05 0xFC 0x7D 0xFA

Das heißt, dass das "...fc7c..." wohl ein "...fc..." hätte sein sollen. Saublöd beim dekodieren. Und vor allem hebelt es die Längenüberprüfung auf unterster Ebene aus.

Dirk, Du musst sagen, ob ich solche Dinge gleich abfangen soll, also die Escape+Steuerzeichen wieder durch nur die Steuerzeichen ersetzen soll. Ich denke es macht Sinn.

Viele Grüße
Thorsten

Das sieht schon mal gut aus:

sz le c  e  Broadcast__ cb Sender_____ Bus-Daten__
fd 0f 14 65 ff ff ff ff fe 00 00 9d bd 69 02 00 20


sz: Startzeichen
le: ist wohl die Länge der Nachricht (alles ausser die ersten beiden bytes
c: Ist wohl der Message-Counte.
e: ist wohl der "Identifyer" für Empfangen (beim senden steht hier s)
cb: Kontrollzeichen

Aber das hatten wir ja oben schon alles.

ZitatDas heißt, dass das "...fc7c..." wohl ein "...fc..." hätte sein sollen. Saublöd beim dekodieren.

Du musst "nur" die Nachrichten an das GW weiterleiten und vom GW an das HM485.pm dann. Um die Codieung und die Decodierug kümmert sich HM485.pm. Somit musst du auch  nix parsen.

Mann Dirk! Riesen Schritte jeden Tag! Dieser Post dient mehr als Erinnerungsstütze:

Also mit CCU2 Image im QEMU gestartet, int der QEMU console (strg+alt+2) webserver und telnet port nach aussen gelegt:


hostfwd_add tcp::8080-:80
hostfwd_add tcp::22-:22


Dann in der telnet console (user: root, pw: homematic) das image schreibbar gemounted und den Kommunikations-Daemon manuell gestartet


mount -o remount,rw /
hs485d -l 5 -g -h 192.168.178.37 -p 1000 -s KEQ0123456 -c -i 0 &


dann kann man zwischen dem eigenen Rechner als CCU und dem HMW-LGW sniffen. Mein allererstes sofort ein Erfolg.


LGW>>48:37:39:2c:30:31:2c:65:51:33:2d:48:4d:57:2d:4c:47:57:2c:31:2e:30:2e:35:2c:4b:45:51:30:33:36:30:37:36:33:0d:0a:53:37:61:0d:0a
CCU>>3e:37:61:2c:30:30:30:30:0d:0a
CCU>>fd:02:01:4b
LGW>>fd:03:01:61:00
CCU>>fd:02:02:4b
LGW>>fd:03:02:61:00


Wie schon zuvor richtig analysiert, empfängt auch die CCU Emulation die Begrüßungsnachricht und die CCU schickt den Transparenzbefehl. Der Transparenzbefehl wird noch mit "\r\n" beendet.

Danach kommen KeepAlive, FD.<lenght>.<seqNo>."K", die acknowledged werden mit FD.<length>.<seqNo>."a".<0x00> Alles ohne "\r\n". Das ist merkwürdig, weil das hat manuell nicht funktioniert, muss ich in meinem Modul nochmals testen.

Löst man dann über das WebGui ein "systemsteuerung" --> "Geräte anlernen" --> "Geräte suchen aus" passiert folgendes:


1. CCU>>fd:0d:04:53:00:ff:ff:ff:ff:98:00:00:00:01:7a
2. CCU>>fd:0d:05:53:00:ff:ff:ff:ff:9c:00:00:00:01:7a
3. CCU>>fd:04:06:44:00:ff
4. LGW>>fd:06:1a:64:00:00:9d:bd
5. LGW>>fd:05:1b:63:00:00:01
6. CCU>>fd:0d:07:53:00:ff:ff:ff:ff:9e:00:00:00:01:5a
7. CCU>>fd:0d:08:53:00:ff:ff:ff:ff:98:00:00:00:01:5a
8. CCU>>fd:0d:09:53:c8:00:00:9d:bd:98:00:00:00:01:68
9. LGW>>fd:05:09:72:9a:15:00
10.CCU>>fd:0d:0a:53:c8:00:00:9d:bd:1c:00:00:00:01:76
11.LGW>>fd:05:0a:72:5c:03:06
12.CCU>>fd:0d:0b:53:c8:00:00:9d:bd:1e:00:00:00:01:6e
13.LGW>>fd:0d:0b:72:7e:4a:45:51:30:32:37:31:39:31:33
14.CCU>>fd:10:0c:53:c8:00:00:9d:bd:18:00:00:00:01:52:00:00:10
15.LGW>>fd:13:0c:72:18:ff:14:ff:ff:ff:ff:fe:ff:ff:ff:ff:ff:05:00:f4:01
16.CCU>>fd:20:0d:53:c8:00:00:9d:bd:1a:00:00:00:01:57:00:00:10:ff:14:00:00:00:01:ff:ff:ff:ff:ff:ff:05:00:f4:01
17.LGW>>fd:03:0d:72:39
18.CCU>>fd:11:0e:53:c8:00:00:9d:bd:1c:00:00:00:01:45:00:00:10:40
19.LGW>>fd:0f:0e:72:5a:65:00:00:10:03:00:00:00:00:00:00:00


Das dürfte die komplette Initialisierungssequenz für meinen Jalousie-Aktor sein. Ich erkenne auf Anhieb:

4. Rückmeldung der Adresse 00:00:9d:bd
10. gezielte Statusabfrage
12. Abfrage der Seriennummer
13. Antwort mit Seriennummer

Over to you Dirk, für den Rest!

Hallo Dirk,

Nur nochmals als Achtungszeichen: Die Message-Länge in den übergebenen Messages entspricht nicht der Länge, wenn ein FC, FD oder FE in der Nachricht enthalten ist. Die extra Escape Zeichen werden nicht mitgezählt.

Viele Grüße
Thorsten

Hallo Dirk,

wie Rufe ich jetzt vom HM485_LAN aus die Funktionen des HM485 auf? Ich denke Mal, dass ich da jetzt weiter machen sollte, oder? Eine entity für meinen Jalousie-Aktor anlegen und dann Bus-Nachrichten an die Entity weitergeben, oder? Wie mache ich das?

Gruß
Thorsten

Zitatwie Rufe ich jetzt vom HM485_LAN aus die Funktionen des HM485 auf? Ich denke Mal, dass ich da jetzt weiter machen sollte, oder?

Ich denke so viel ist von dir gar nicht mehr zu tun.
Die Entity für das einzelne Device ist Aufgabe von HM485.pm da bin ich im Moment schon dran.
Ggf. kannst du eine set raw in dein Modul einbauen. Analog von der aktuellen Implementation in HM485_Serial. Dann kannst du zumindestens schon mal über FHEM schalten.

Gruß
Dirk

Hi Dirk,

hier auf Deine Bitte hin nochmals ein NACK:


CCU>>fd:0d:8e:53:c8:00:00:9d:cd:1c:00:00:00:01:76
LGW>>fd:03:8e:61:01


Ich habe also eine Statusabfrage an Adresse "9d:cd" geschickt, die es bei mir nicht gibt. Das LGW antwortet mit 'a' aber dahinter nicht 0x00 sondern 0x01. Davor steht nur FD, Länge und Sequenznummer.

VG

Hallo Thorsten,

danke erstmal noch für die Infos.
Ich habe in den letzten Tagen noch einiges Entwickelt.
Wie besprochen habe ich unsere beiden Module zusammengelegt.
Das Ergebnisse ist derzeit noch hier zu finden:
https://github.com/kc-GitHub/FHEM-HM485 (//github.com/kc-GitHub/FHEM-HM485)

Das Modul heißt jetzt HM485_LAN, da es sowohl mit dem HM-LAN-GW zusammenarbeiten sollte, als auch mit meinem HM485d.pl, welcher das Protokoll für "dumme" serielle Interfaces (USB/Rs232->RS485 oder auch Netzwerk->RS485 Adapter) implementiert.

Das Modul HM485 implementiert die Device-Entities im FHEM.
Discovery sollte auch beim HM-LAN-GW schon funktionieren und alle gefunden Geräte und ihre zugehörigen Channels anlegen. Die Channels, welche vom Subtype Switch sind, können auch schon geschaltet werden.

Gruß
Dirk

Moin Dirk,

kann man die Dateien auch als unregistrierter User laden? Ich bekomme nur die html-Inhalte der .pm-Dateien zu sehen, egal auf welche Weise ich den Download versuche.

Danke und Gruß
Uwe

Ja, unten rechts, "Download Zip" :)

Gruß
Dirk

Verdammt...als DAU geoutet ;-)

Danke, hab's gefunden :)

Hallo Dirk,

ich habe mir vor ca. 2 Wochen vollkommen unbedarft einige Artikel der Homematic Serie angeschafft und dabei hübsch Funk und Wired Komponenten gemischt.
Ich bin ziemlich naiv einfach mal davon ausgegangen, dass das kein Problem sein wird. Dann musste ich (selbstverständlich) feststellen, dass das sehr wohl ein Problem sein kann. Du kannst Dir vielleicht meine Erleichterung vorstellen, als ich dieses Projekt zum LAN-Gateway entdeckt habe.
Also flugs, das Modul heruntergeladen, installiert, LAN-Gateway erfolgreich in meine FHEM Installation eingebunden. Alles ohne Probleme.

Dann habe ich das LAN-Gateway in den Discovery-Modus versetzt und damit fingen die Probleme an. Das Gateway verlässt den Discovery-Modus nicht mehr. Auch wenn ich ihn für 2 Tage am Stück laufen lasse. Abgesehen davon findet das Gateway leider auch den installierten HMW-IO-12-Sw7-DR nicht.

Wenn ich das LAN Gateway per Telnet auf Port 1000 ansteuere erhalte ich eine Antwort. Alles scheint gut zu sein. Allerdings scheint beim Schalten des HMW-IO-12-Sw7-DR nichts beim Gateway anzukommen.

Momentan habe ich im Wired Bereich folgende Teile verbaut:
1. HMW-IO-12-Sw7-DR (//www.elv.de/homematic-wired-rs485-i-o-modul-12-eingaenge-7-schaltausgaenge-1.html)
2. LAN Gateway (//www.elv.de/homematic-rs485-gateway-1.html)
3. Überspannungsschutz  (//www.elv.de/homematic-wired-rs485-ueberspannungsschutz.html)
4. Busabschlusswiderstand (//www.elv.de/homematic-wired-rs485-busabschluss-widerstand-hutschienenmontage-1.html)

Den Busabschlusswiderstand habe ich lediglich installiert, um erkennen zu können, ob Verkehr auf dem Bus ist.

Der FHEM Server läuft auf einem Raspberry Pi.

Ich habe mittlerweile den Verdacht, dass evtl. eines der Teile defekt ist, weil das Gateway so gar nichts findet.

Hast Du einen Tipp, wie ich hier weiter vorgehen kann?

Vielen Dank für Deine Hilfe!
Jan

Hallo Jan,

ZitatIch habe mittlerweile den Verdacht, dass evtl. eines der Teile defekt ist, weil das Gateway so gar nichts findet.

Das glaube ich erstmal nicht.
Hast du die AES-Verschlüsselung vom HMW-LAN-GW ausgeschaltet?
Mit Verschlüsselung die standardmäßig aktiviert ist, kann FHEM mit dem Modul nicht kommunizieren.

Leider ist die Implementierung des HMW-Lan-GW noch nicht abschließend mit den HM485 Modulen getestet. Die Implementation beruht auf den Forschungen von Thorsten (crazystone).
Übrigens nochmal danke für deine Unterstützung hier.

Einen Abschließenden Test gab es aber noch nicht.
Und da ich selber kein HMW-LAN-GW habe, bin ich hier dann auf Hilfe angewiesen.

ZitatWenn ich das LAN Gateway per Telnet auf Port 1000 ansteuere erhalte ich eine Antwort. Alles scheint gut zu sein. Allerdings scheint beim Schalten des HMW-IO-12-Sw7-DR nichts beim Gateway anzukommen.

Kannst du mir mal deine Konfig schicken?
Gibt es Ausgaben im Log?

Gruß
Dirk

Oh man, seit fast 4 Wochen schon überhaupt keine Zeit mehr. Ich hoffe es wird ab dem Wochenende mal wieder besser.

Was Jan sagt, macht mich total neugierig, endlich deine Module zu testen. Zum Starten meines RPi, der die CCU2 simulieren soll, bin ich auch noch nicht gekommen, wobei die SD Card schon erstellt ist.

Meines Erachtens war doch der Discovery Befehl nur ein Kommando, dass dann alle devices auffordert sich zu melden. Jan, sagst du, dass dieser Befehl immer wieder geschickt wird? Kannst Du ein pcap posten?

Wird Zeit, dass Weihnachten wird...

Viele Grüße noch von der Dienstreise

Hallo Dirk, hallo crazystone,

vielen Dank für die schnelle Antwort!

Die Verschlüsselung habe ich über den eq-3 Netfinder abgeschaltet.

Meine Config kann ich leider erst heute Abend schicken. Brauchst Du die gesamte config oder nur den HM485 Teil? Der ist nämlich sehr übersichtlich.

Im Log finde ich den erfolgreichen Verbindungsaufbau des FHEM zum Gateway und die keepalive Nachrichten, die versendet werden. Allerdings sehe ich keine einzige Antwort des Gateways.

Das Senden des Discovery Befehls kann ich selbst bei verbose 5 im Log nicht sehen.

Ihr müsst verzeihen, aber ich bin was FHEM angeht ein absoluter Neuling. Ich programmiere zwar auch, aber Perl ist gefühlte hundert Jahre her. Mit pcap etc. kenne ich mich leider auch so gar nicht aus. Von daher bräuchte ich eine kurze Einweisung, was ich tun soll, um Euch am besten helfen zu können.

Viele Grüße
Jan

Hi Jan,

ZitatBrauchst Du die gesamte config oder nur den HM485 Teil?

Ja, der reicht.

ZitatIm Log finde ich den erfolgreichen Verbindungsaufbau des FHEM zum Gateway und die keepalive Nachrichten, die versendet werden.

Ich fürchte ich habe für das HMW-LAN-GW noch zu wenig Logging-Informationen eingebaut. Das werde ich nachholen. Da kome ich aber frühestens heute abend dazu.
Der HM485d den ich derzeit Hauptsächlich zusammen mit dem Netzwerk-RS485-Adapter (http://forum.fhem.de/index.php?topic=14096.0) benutze übernimmt das Logging hier.

Gruß
Dirk

Hallo Dirk,

die Config-Einträge:
define HM485_LAN HM485_LAN 192.168.5.218:1000
attr HM485_LAN hmwId 00000001
attr HM485_LAN verbose 5

und die Log-Einträge zum HM485:
2013.10.11 22:16:35 3: Opening HM485_LAN device 192.168.5.218:1000
2013.10.11 22:16:35 3: HM485_LAN device opened
2013.10.11 22:16:35 3: HM485_LAN connected to device 192.168.5.218:1000
2013.10.11 22:16:36 3: HM485_LAN keepalive msgNo: 1
2013.10.11 22:16:36 5: SW: <FD>^B^BK

Ich hoffe, das hilft!?

Grüße
Jan

Hi Jan,

Zitatdie Config-Einträge

Sieht erstmal gut aus.
Ich baue grade noch ein Paar Debugging-Infos ein.

Melde mich nachher nochmal.

Gruß
Dirk

Hallo crazystone,

ich habe mich mal mit pcapdump versucht. Anbei zwei pcap Dateien.
In der ersten Datei (eth0-1000.dump) habe ich den FHEM Server gestartet und nach kurzer Zeit den discovery Befehl abgeschickt.
In der zweiten (eth0-1000.2.dump) haben ich zusätzlich noch ein wenig auf dem IO Modul "herumgetastet" also ein paar Taster gedrückt.

Bringt Dich das irgendwie weiter?

Grüße
Jan

Hi Jan,

so, du kannst nochmal aktualisieren.
Debuglevel auf 4 stellen, dann siehst du die in- und out messages im log.
Hoffentlich.

Gruß
Dirk

Hallo Dirk,

ich habe das Update eingespielt. Leider hat sich im Log-Verhalten gar nichts verändert. Also weiterhin lediglich Verbindungsaufbau und keepAlive, aber keine Antwort vom GW.

Grüße
Jan

Hallo,

ich habe das gleiche Problem.

Da aber gestern auch mein USB<=>RS485 Adapter von Kmtronic eingetrudelt ist, habe ich diesen heute ausprobiert.

http://sigma-shop.com/product/68/usb-to-rs485-ftdi-interface-board-pcb.html (http://sigma-shop.com/product/68/usb-to-rs485-ftdi-interface-board-pcb.html)

Es gibt schon beim Start Fehlermeldungen auf der Konsole:

Zitatroot@RASP-FHEM1:/opt/fhem# 2013.10.12 17:37:47.744 3: SERVER: port 2000 opened
2013.10.12 17:37:47.749 3: server waiting for client connection on port 2000
2013.10.12 17:37:47.753 3: Opening SERIAL device 192.168.1.117:5000
2013.10.12 17:37:47.807 3: Can't connect to 192.168.1.117:5000: Verbindungsaufbau abgelehnt
2013.10.12 17:37:47.811 1: Server started ...

Der HM485d lauscht offensichtlich auf Port 2000, obwohl in der Konfig Port 5000 angegeben ist. Ändere ich die Konfig, sieht es schon besser aus:

ZitatStarting fhem...
root@RASP-FHEM1:/opt/fhem# 2013.10.12 17:43:08.372 3: SERVER: port 2000 opened
2013.10.12 17:43:08.377 3: server waiting for client connection on port 2000
2013.10.12 17:43:08.380 3: Opening SERIAL device 192.168.1.117:2000
2013.10.12 17:43:08.432 3: SERIAL device opened
2013.10.12 17:43:08.436 2: SERIAL connected to device 192.168.1.117:2000
2013.10.12 17:43:08.439 1: Server started ...
2013.10.12 17:43:08.446 4: Connection accepted from telnet:192.168.1.117:53500

Ein Discovery sieht im Log so aus:

Zitat2013.10.12 17:51:19 4: HTTP FHEMWEB:192.168.1.106:57794 GET /fhem?cmd.HM485_LAN=set%20HM485_LAN%20discovery%20start&room=HM485
2013.10.12 17:51:19 4: HM485_LAN: TX: (2) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2013.10.12 17:51:19 4: HM485_LAN: TX: (3) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)

Ein HM485_LAN: RX taucht nicht auf, auch nicht wenn ich die Eingänge meines Moduls (hab nur das 4er-RS485-I/O Modul) schalte. Die RX-LED auf dem Board flackert und mit Putty unter Windows sehe ich Hieroglyphen eintrudeln. Das Modul sendet also auf den Bus.

Meine Konfig auf einem auschließich für Experimente genutzen Raspberry entspricht im wesentlichen der Beispielkonfiguration:

Zitat### HM485 Interface (WIZ108SR)
#
define HM485_LAN HM485_LAN /dev/ttyUSB0@19200
attr HM485_LAN HM485d_device 192.168.1.117:2000
attr HM485_LAN hmwId 00000001
attr HM485_LAN HM485d_bind 1

# on slow servers like fritzbox or raspberry pi it should necessarry to increase this value
attr HM485_LAN HM485d_startTimeout 5

attr HM485_LAN room HM485
attr HM485_LAN HM485d_logVerbose 4

Was kann ich tun um zur weiteren Fehlersuche bei zu tragen?

Grüße,

Manfred

Zitat von: jkrogma am 12 Oktober 2013, 13:44:06
ich habe das Update eingespielt. Leider hat sich im Log-Verhalten gar nichts verändert. Also weiterhin lediglich Verbindungsaufbau und keepAlive, aber keine Antwort vom GW.

Dann muss ich mal schauen was da noch fehlt.

Zitat von: ManfredC am 12 Oktober 2013, 17:57:29
Der HM485d lauscht offensichtlich auf Port 2000, obwohl in der Konfig Port 5000 angegeben ist. Ändere ich die Konfig, sieht es schon besser aus:
Ein Discovery sieht im Log so aus:

Also, Standardmässig lauscht der hm485d auf Port 2000. Der Port 5000 währ z.B. für den
WIZ108SR Netzwerk zu RS485 Adapter (http://forum.fhem.de/index.php/topic,14096.msg88557.html#msg88557).

Bei deinem USB-RS485 Adapter musst du das serielle Device angeben. Also z.B.
attr HM485_LAN HM485d_device /dev/ttyUSB1

Deine Configuration muss also so aussehen:

define HM485_LAN HM485_LAN localhost:2000
attr HM485_LAN hmwId 00000001
attr HM485_LAN HM485d_bind 1
attr HM485_LAN HM485d_device /dev/ttyUSB0
attr HM485_LAN HM485d_logVerbose 4


Gruß
Dirk

Hallo Dirk,

super, jetzt gehts.


dann ist die Konfig fhem_SERIAL.cfg nicht für Serial/USB Adapter?


Grüße,

Manfred

Hi Manfred,

Zitatdann ist die Konfig fhem_SERIAL.cfg nicht für Serial/USB Adapter?

Doch, das ist das richtige Beispiel. Aber ich sehe grade dass da ein Fehler drinn ist.

Hab ich hier schon korrigiert.

Gruß
Dirk

Hallo Dirk,

mit dem Lan-Gateway komme ich nicht weiter.

Per Telnet kann ich das Gerät erreichen:

Zitatroot@RASP-FHEM1:~# telnet 192.168.1.118 1000
Trying 192.168.1.118...
Connected to 192.168.1.118.
Escape character is '^]'.
H07,01,eQ3-HMW-LGW,1.0.4,KEQ0360896
S08

Config:

Zitat
#### HM485 Interface (HMW-LAN-GW)##
define HM485_LAN HM485_LAN 192.168.1.118:1000
attr HM485_LAN hmwId 00000001
attr HM485_LAN room HM485

discovery sieht im log so aus:

Zitat
2013.10.12 22:11:37 4: HM485_LAN: TX: (4) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2013.10.12 22:11:37 4: HM485_LAN: TX: (5) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)

Kein RX:

Gruß,

Manfred

Hi Jan, hi Dirk,

ich habe mir die dumps mit Wireshark angeschaut. Die Begrüßungssequenz ist wie bei meinem HMW-LGW. Allerdings fehlt danach der Transparenzschaltbefehl ">,0000" (Dirk?!). Die KeepAlive werden richtig gesendet, aber nicht beantwortet. Es werden auch isngesamt noch drei andere Kommandos gesendet, alle aber nicht acknowledged (alle immer nur auf TCP Ebene bestätigt).


0s:  HMW>>48:31:33:2c:30:31:2c:65:51:33:2d:48:4d:57:2d:4c:47:57:2c:31:2e:30:2e:34:2c:4b:45:51:30:33:36:31:30:36:39:0d:0a:53:31:34:0d:0a
1s:  FHEM>>fd:02:02:4b                                                    --> KeepAlive
25s:FHEM>>fd:0d:03:53:c8:ff:ff:ff:ff:98:00:00:00:01:7a   
25s:FHEM>>fd:0d:04:53:c8:ff:ff:ff:ff:98:00:00:00:01:7a   --> Warum doppelt?
26s:FHEM>>fd:02:05:4b                                                    --> KeepAlive
26s:FHEM>>fd:04:06:44:00:ff                                           --> Discovery?
51s:FHEM>>fd:02:07:4b                                                    --> KeepAlive


Hallo,

Mist. Natürlich habe ich die Initialisierungssequenz vom HMW-LAN-GW vergessen.
Ich habs im Github aktualisiert.

Es kann also nochmal getestet werden.
Ich hoffe das funktioniert jetzt.

Gruß
Dirk

Hallo,

Zitat von: Dirk am 13 Oktober 2013, 00:56:02
Ich hoffe das funktioniert jetzt.

leider nicht.

Gruß,

Manfred

Hm, da muss ich weiter suchen.
Kommen die Keepalive Messages alle ca. 25 Sekunden?

Kannst du mal die "Internals" vom HM485_LAN Posten?

Gruß
Dirk

Zitat von: Dirk am 13 Oktober 2013, 12:41:47
Kommen die Keepalive Messages alle ca. 25 Sekunden?

ja.

Zitat von: Dirk am 13 Oktober 2013, 12:41:47
Kannst du mal die "Internals" vom HM485_LAN Posten?

Screenshot angehängt.

Grüße,

Manfred

Hallo Manfred,

ich habe nochmal die Debugging-Infos noch mal erweitert.

Kannst du nochmal testen.
Am besten nochmal alles ersetzen. Es gab auch kleine Änderungen an ServerTools und Constants.pm.
Den Sendebuffer in den ServerTools hab ich etwas vergrößert.

Dann bitte mal das Log 1-2 min. laufen lassen.
Nach den Keepalives sollte jetzt auch die Antwort angezeigt werden.
dann mal bitte an deinem Modul eine Taste / Eingang betätigen und mal das Log beobachten.
Ggf. auch anschließend nochmal ein Discovery starten.
Das Logfile hier dann bitte mal mit dranhängen.

Gruß
Dirk

Hallo Dirk,

Zitat von: Dirk am 13 Oktober 2013, 14:45:55
ich habe nochmal die Debugging-Infos noch mal erweitert.

Ich seh nach wie vor im log nur TX: nachrichten an das GW, keine RX. Hab vorhin mal tcpdump einen Start von FHEM und ein discovery, gefiltert auf die IP des GW, mitschneiden lassen. Vielleicht kannst Du damit was anfangen.


Gruß,

Manfred

Die Ausgaben im Log würden mich trotzdem mal interessieren.
Vor allem die "Begrüßung" und die Keepalifes.
Ggf. auch mit Meereren Connects und auch vor und nach dem Stromlosmachen vom GW.

Gruß
Dirk

Hallo Dirk,

hier noch ein dump von den alive Messages.

Gruß,

Manfred

Hi Manfred,

Logmessages hast du nicht für mich?
Ich hätte gerne gesehen das das Interface sendet und das HM485_LAN sieht.
Verbose musst du auf 3 stellen. Dann solltest du die Logausgaben von FHEM sehen.

Gruß
Dirk

Hallo Dirk,

erst mit  log verbose  5 beim HM585_LAN  sehe ich nach den keepalive messages etwas.

2013.10.13 18:17:40 5: SW: <FD>^B^LK

Gruß,

Manfred

Hallo Dirk,

ich habe Dir mal das komplette Log des Severs angehängt.
- Neustart Server
- Discovery
- Strom aus/an am Gateway.

Was kann ich sonst tun?

Grüße
Jan

Hallo Manfred und Jan,

Ich  bin grade mit crazystone am fixen.
Der Messagecounter war noch nicht richtig.
Es liegt aber schon einen funktionierende Version auf Github. Allerdings noch nicht ganz stabil.

Aber man sieht schon mal was.

Gruß
Dirk

Hallo Dirk,

ja, sieht besser aus ;-)

2013.10.13 20:43:27 4: HTTP FHEMWEB:192.168.1.106:52258 GET /fhem?room=all&XHR=1&inform=1&timestamp=1381689797074
2013.10.13 20:43:27 4: HM485_LAN: Do action after discovery Found Devices: 1
2013.10.13 20:43:27 3: HM485_LAN: TX: (22) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 5A(Z)
2013.10.13 20:43:27 5: SW: <FD>^M^VS<C8><FF><FF><FF><FF><98>^@^@^@^AZ
2013.10.13 20:43:27 3: HM485_LAN: TX: (23) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 5A(Z)
2013.10.13 20:43:27 5: SW: <FD>^M^WS<C8><FF><FF><FF><FF><98>^@^@^@^AZ
2013.10.13 20:43:27 3: HM485_LAN: Alive: (23) 3032
2013.10.13 20:43:27 3: HM485_LAN: NACK: 23
2013.10.13 20:43:27 5: HM485_LAN dispatch <FD>^C^Wa^B
2013.10.13 20:43:28 3: HM485_LAN: Alive: (22) 3031
2013.10.13 20:43:28 3: HM485_LAN: NACK: 22
2013.10.13 20:43:28 5: HM485_LAN dispatch <FD>^C^Va^A
2013.10.13 20:43:28 1: HM485_LAN: Dispatch: 00003337
2013.10.13 20:43:28 1: HM485_LAN: FD0E0065000000019800003337690000 (RX: <FD>^N^@e^@^@^@^A<98>^@^@37i^@^@)

2013.10.13 20:43:28 5: HM485_LAN dispatch <FD>^N^@e^@^@^@^A<98>^@^@37i^@^@
2013.10.13 20:43:28 1: Device (00003337) not defined yet. Query aditional informations.
2013.10.13 20:43:28 3: HM485_LAN: TX: (24) I[0](0,Y,F,B)(98) 00000001 -> 00003337 [3] 68(h)
2013.10.13 20:43:28 5: SW: <FD>^M^XS<C8>^@^@37<98>^@^@^@^Ah
2013.10.13 20:43:28 3: HM485_LAN: TX: (25) I[0](0,Y,F,B)(98) 00000001 -> 00003337 [3] 6E(n)
2013.10.13 20:43:28 5: SW: <FD>^M^YS<C8>^@^@37<98>^@^@^@^An
2013.10.13 20:43:28 3: HM485_LAN: Alive: (25) 3032
2013.10.13 20:43:28 3: HM485_LAN: NACK: 25
2013.10.13 20:43:28 5: HM485_LAN dispatch <FD>^C^Ya^B
2013.10.13 20:43:28 1: NACK from 00003337 | 68
2013.10.13 20:43:28 3: HM485_LAN: Response: (24) 1000
2013.10.13 20:43:28 5: HM485_LAN dispatch <FD>^E^Xr<98>^P^@
2013.10.13 20:43:30 3: HM485_LAN: keepalive msgNo: 26
2013.10.13 20:43:30 5: SW: <FD>^B^ZK
2013.10.13 20:43:30 3: HM485_LAN: Alive: (26) 3030
2013.10.13 20:43:55 3: HM485_LAN: keepalive msgNo: 27
2013.10.13 20:43:55 5: SW: <FD>^BESCK
2013.10.13 20:43:55 3: HM485_LAN: Alive: (27) 3030

was soll ich tun damit  das 4er-RS485-I/O Modul implementiert werden kann?

Gruß,

Manfred

Zitatwas soll ich tun damit  das 4er-RS485-I/O Modul implementiert werden kann?

Du meinst das HMW-IO-4-FM?
Ich muss noch ein paar Sachen aus dem Dev-Branch fertig machen. hier bin ich schon einiges weiter.
Dann muss das Device-File noch feritg gebaut werden.

ich habe grade noch mal geupdatet.
ich hoffe es gibt jetzt keine NACK's  mehr

Legt er ein Device bei dir an?

Gruß
Dirk

Zitat von: Dirk am 13 Oktober 2013, 21:02:06
Du meinst das HMW-IO-4-FM?

ja, genau das.

Zitat
ich habe grade noch mal geupdatet.
ich hoffe es gibt jetzt keine NACK's  mehr

Legt er ein Device bei dir an?

nein. Allerdings habe ich noch nicht upgedatet. Hier das Log beim Tastendrücken:

2013.10.13 21:08:31 5: SW: <FD>^BXK
2013.10.13 21:08:31 3: HM485_LAN: Alive: (88) 3030
2013.10.13 21:08:36 3: HM485_LAN: RX: I[1](0,Y,F,B)(9A) 00003337 -> FFFFFFFF [4] 4B(K) 01
2013.10.13 21:08:36 5: HM485_LAN dispatch <FD>^O^Be<FF><FF><FF><FF><9A>^@^@37K^A^@6
2013.10.13 21:08:36 1: Device (00003337) not defined yet. Query aditional informations.
2013.10.13 21:08:36 3: HM485_LAN: TX: (89) I[0](0,Y,F,B)(98) 00000001 -> 00003337 [3] 68(h)
2013.10.13 21:08:36 5: SW: <FD>^MYS<C8>^@^@37<98>^@^@^@^Ah
2013.10.13 21:08:36 3: HM485_LAN: TX: (90) I[0](0,Y,F,B)(98) 00000001 -> 00003337 [3] 6E(n)
2013.10.13 21:08:36 5: SW: <FD>^MZS<C8>^@^@37<98>^@^@^@^An
2013.10.13 21:08:36 3: HM485_LAN: Alive: (89) 3032
2013.10.13 21:08:36 3: HM485_LAN: NACK: 89
2013.10.13 21:08:36 5: HM485_LAN dispatch <FD>^CYa^B
2013.10.13 21:08:36 3: HM485_LAN: RX: I[2](0,Y,F,B)(9C) 00003337 -> FFFFFFFF [16] 41(A) 01100003064645513030373235
2013.10.13 21:08:36 5: HM485_LAN dispatch <FD>ESC^Ce<FF><FF><FF><FF><9C>^@^@37A^A^P^@^C^FFEQ0072586
2013.10.13 21:08:36 1: Device (00003337) not defined yet. Query aditional informations.
2013.10.13 21:08:36 3: HM485_LAN: TX: (91) I[0](0,Y,F,B)(98) 00000001 -> 00003337 [3] 68(h)
2013.10.13 21:08:36 5: SW: <FD>^M[S<C8>^@^@37<98>^@^@^@^Ah
2013.10.13 21:08:36 3: HM485_LAN: TX: (92) I[0](0,Y,F,B)(98) 00000001 -> 00003337 [3] 6E(n)
2013.10.13 21:08:36 5: SW: <FD>^M\S<C8>^@^@37<98>^@^@^@^An
2013.10.13 21:08:36 3: HM485_LAN: Alive: (91) 3032
2013.10.13 21:08:36 3: HM485_LAN: NACK: 91
2013.10.13 21:08:36 5: HM485_LAN dispatch <FD>^C[a^B
2013.10.13 21:08:36 1: NACK from 00003337 | 6E
2013.10.13 21:08:36 3: HM485_LAN: Response: (90) 46455130303732353836
2013.10.13 21:08:36 5: HM485_LAN dispatch <FD>^MZr^^FEQ0072586
2013.10.13 21:08:36 3: HM485_LAN: Response: (92) 46455130303732353836
2013.10.13 21:08:36 5: HM485_LAN dispatch <FD>^M\r^XFEQ0072586
2013.10.13 21:08:39 3: HM485_LAN: RX: I[1](0,Y,F,B)(9A) 00003337 -> FFFFFFFF [4] 4B(K) 01
2013.10.13 21:08:39 5: HM485_LAN dispatch <FD>^O^De<FF><FF><FF><FF><9A>^@^@37K^A^@:
2013.10.13 21:08:39 1: Device (00003337) not defined yet. Query aditional informations.
2013.10.13 21:08:39 3: HM485_LAN: TX: (93) I[0](0,Y,F,B)(98) 00000001 -> 00003337 [3] 68(h)
2013.10.13 21:08:39 5: SW: <FD>^M]S<C8>^@^@37<98>^@^@^@^Ah
2013.10.13 21:08:39 3: HM485_LAN: TX: (94) I[0](0,Y,F,B)(98) 00000001 -> 00003337 [3] 6E(n)
2013.10.13 21:08:39 5: SW: <FD>^M^S<C8>^@^@37<98>^@^@^@^An
2013.10.13 21:08:39 3: HM485_LAN: Alive: (93) 3032
2013.10.13 21:08:39 3: HM485_LAN: NACK: 93
2013.10.13 21:08:39 5: HM485_LAN dispatch <FD>^C]a^B
2013.10.13 21:08:39 1: NACK from 00003337 | 6E


Gruß,

Manfred

Hallo Dirk, hallo crazystone,

ich habe Eurer letztes Update eingespielt und es ist eine Menge mehr im Log zu sehen (s. Anhang)

Auf der Konsole erhalte ich außerdem in der Shell, mit der ich den Server gestartet habe beim Tasten auf dem IO Modul (HMW_IO_12_Sw7_DR) folgende Perl Fehler:
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Integer overflow in hexadecimal number at /opt/fhem/FHEM/10_HM485.pm line 524.
Hexadecimal number > 0xffffffff non-portable at /opt/fhem/FHEM/10_HM485.pm line 524.
$VAR1 = '4A455130373133353332';
Use of uninitialized value $retVal in substitution (s///) at /opt/fhem/FHEM/10_HM485.pm line 527.
Use of uninitialized value $model in string ne at /opt/fhem/FHEM/10_HM485.pm line 493.
Use of uninitialized value $model in concatenation (.) or string at /opt/fhem/FHEM/10_HM485.pm line 493.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Integer overflow in hexadecimal number at /opt/fhem/FHEM/10_HM485.pm line 524.
Hexadecimal number > 0xffffffff non-portable at /opt/fhem/FHEM/10_HM485.pm line 524.
$VAR1 = '4A455130373133353332';
Use of uninitialized value $retVal in substitution (s///) at /opt/fhem/FHEM/10_HM485.pm line 527.
Use of uninitialized value $model in string ne at /opt/fhem/FHEM/10_HM485.pm line 493.
Use of uninitialized value $model in concatenation (.) or string at /opt/fhem/FHEM/10_HM485.pm line 493.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.
Use of uninitialized value $dev in hash element at fhem.pl line 2922.


Viele Grüße
Jan

Hi Jan,

zumindestens Empfängt das HMW-LAN-GW schon was :)
Allerdings gibt es noch einige Bugs.

Ich werde vermutlich auch erst morgen abend zu weiteren Bugfixes kommen.

Gruß
Dirk

Hallo Dirk,

wenn ich Dich irgendwie unterstütze kann, sag Bescheid.

Grüße
Jan

Kurze Frage da ich  mich auch gerade mit HMW auseinandersetze:
Arbeitet der HomeMatic Wired RS485 Schließerkontakt HMW-Sen-SC-12-FM nach dem PUSH prinzip?

Dh, meldet dieser selbständig eine Zustandsänderung (plus ev. ein tägliches Intervall bei Nichtänderung) oder muss permanent (wie bei 1wire) abgefragt werden?
Ich bin für meine Fensterkontakte auf der Suche nach fhem-kompatiblen, drahtgebundenen(!) Komponenten die dach dem PUSH-Prinzip arbeiten.
1Wire ist aufgrund des PULL-Prinzips eher suboptimal.

Zitat von: jkrogma am 14 Oktober 2013, 21:18:31
wenn ich Dich irgendwie unterstütze kann, sag Bescheid.

Mach ich.

Zitat von: Tobias am 15 Oktober 2013, 10:46:16
Arbeitet der HomeMatic Wired RS485 Schließerkontakt HMW-Sen-SC-12-FM nach dem PUSH prinzip?

Ja, Zustandsänderungen werden quasi in Echtzeit gesendet. Man kann den Status aber auch jederzeit vom Sensor anfordern. Und Somit Z.b. auch zyklisch "nachfragen".

Gruß
Dirk

Edit: Typo

Hallo Dirk,

mit den neuen Dateien habe ich folgendes Log:

2013.10.15 16:53:39 3: HM485: Loading available device files
2013.10.15 16:53:39 3: =====================================
2013.10.15 16:53:39 1: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw-sen-sc-12.pm
2013.10.15 16:53:39 1: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw14_dr.pm
2013.10.15 16:53:39 1: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr.pm
2013.10.15 16:53:39 1: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr.pm
2013.10.15 16:53:39 1: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_dim1l_dr.pm
2013.10.15 16:53:39 1: Including ./log/fhem.save
2013.10.15 16:53:40 1: statefile: Usage: setstate <name> <state>
where <name> is either:
- a single device name
- a list separated by komma (,)
- a regexp, if it contains one of the following characters: *[]^$
- a range separated by dash (-)

2013.10.15 16:53:44 0: Server started with 79 defined entities (version $Id: fhem.pl 3872 2013-09-07 11:58:33Z rudolfkoenig $, os linux, user fhem, pid 2790)
2013.10.15 16:53:45 3: HM485_LAN: Start HM485d with command line: ./FHEM/lib/HM485/HM485d/HM485d.pl --serialNumber SGW0123456 --device 192.168.178.47:5000 --verbose 4
2013.10.15 16:53:45 3: HM485_LAN: HM485d Could nor start
2013.10.15 16:54:54 3: HM485_LAN: TX: (0) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2013.10.15 16:54:54 3: HM485_LAN: TX: (1) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)

Seit dem "discovery start" rödelt FHEM da drauf rum, jede RS485-Aktion wird mit "Discovery is running. Pleas wait for finishing. " quittiert. Das hält er auch stundenlang durch, discovery hängt offenbar irgendwo. Kannst Du das reproduzieren?

Der Empfang funktioniert aber weiterhin auf der Konsole, FHEM läuft weiter und lässt sich auch beenden.

Gruß
Uwe

Hi Uwe,

ZitatSeit dem "discovery start" rödelt FHEM da drauf rum, jede RS485-Aktion wird mit "Discovery is running. Pleas wait for finishing. " quittiert. Das hält er auch stundenlang durch, discovery hängt offenbar irgendwo. Kannst Du das reproduzieren?

Das ist ein Bug.
Während ein Discovery läuft werden alle Requests zum Interface geblockt und mit der benannten Meldung quitiert.
Wenn das Discovery beendet wurden, dann wird diese "Blockade" wieder aufgehoben.

Das Discovery hat bei dir aber nix gemacht und liefert daher auch kein Ergebniss. Daher bleibt das nun bis zum nächsten Start von FHEM in diesem Mode.
Da werde ich noch einen Timeout oder so einbauen.

Gruß
Dirk

OK, Danke  :)

Hallo Zusammen,

ich habe heute den Masterbranch auf Github (https://github.com/kc-GitHub/FHEM-HM485) wieder aktualisiert.

Die Unterstützung des HMW-LAN-GW habe ich weitestgehend vervollständigt. Vielen Dank an crazystone für das Testen und analysieren an dieser Stelle.

Wer Zeit und Interesse hat bitte ich hiermit zum Test :)

Was geht hier derzeit alles?

- Discovery (Geräte am Bus finden und die Channels dafür anlegen)
- Config der Geräte und der Channels lesen und schreiben
- RAW-Befehle senden
- beim HMW_IO12_SW7_DR können die Schaltkanäle schon direkt geschaltet werden
- ein geänderter Status beim HMW_IO12_SW7_DR löst entsprechende Events aus

Die Unterstützung der weitere Geräte werde ich hoffentlich die nächsten Tage fertig bekommen.
Anschliessend geht es an das Peering.

Das Anlegen der Geräte scheint wohl noch nicht ganz reibungslos zu funktionieren.
- Wenn Discovery nicht alle Geräte findet, bitte noch einmal laufen lassen
- Falls nach dem Discovery noch nicht alle Informationen (Modultype, Seriennummer, Firmwareversion) vom Device ermittelt werden konnten bitte am device ein "get infos" ausführen

- Die Device-Config, also die Register im EEprom werden noch nicht automatisch gelesen. Hierfür erst ein "get config all" am Device ausführen. Auch werden erst danach die Konfigurationswerte korrekt angezeigt.


Viele Grüße
Dirk

Hi Dirk,

wenn ich Zeit finde, werde ich es am Wochenende direkt testen.

Danke schon mal.

MfG
Matthias

Hi,

ich kann das ausprobieren nur wärmstens empfehlen, es war eine lange und intensive Testreihe, inklusive "over-Internet-testing" mit CCU emulation, sniffing sessions und allem pipapo. Am Ende steht ein zumindest mit meinen paar Geräten sehr gut funktionierendes discovery, keepalive, automatisch angelegte Geräte mit channels. Ein riesen Schritt, im Vergleich von vor drei Wochen.

Es steckt noch viel Arbeit drin, das Ganze abzuschließen, aber dank Dirks hochprofessioneller Arbeit an diesem Hobby geht es fast rasend schnell voran.

Ich freue mich drauf, noch vor Weihnachten endlich mein Garagentor mit dem Handy öffnen zu können ;-)

Viele Grüße an alle Mitstreiter, Testergebnisse und Feedback herzlich willkommen!

Moin,


discovery findet den HMW_IO_12_Sw14_DR, Device wird angelegt. Ich kann aber nichts schalten und es wird auch kein Status angezeigt, nur ? ? ?

die Kanäle sehen so aus:

Zitatdigital_analog_input
HMW_IO_12_Sw14_DR_KEQ0182158_21  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_22  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_23  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_24  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_25  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_26  ? ? ?

digital_analog_output
HMW_IO_12_Sw14_DR_KEQ0182158_07  ? ? ?  on off
HMW_IO_12_Sw14_DR_KEQ0182158_08  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_09  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_10  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_11  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_12  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_13  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_14  ? ? ?

digital_input
HMW_IO_12_Sw14_DR_KEQ0182158_15  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_16  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_17  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_18  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_19  ? ? ?
HMW_IO_12_Sw14_DR_KEQ0182158_20  ? ? ?

digitaloutput
HMW_IO_12_Sw14_DR_KEQ0182158_01  ? ? ?  on off
HMW_IO_12_Sw14_DR_KEQ0182158_02  ? ? ?  on off
HMW_IO_12_Sw14_DR_KEQ0182158_03  ? ? ?  on off
HMW_IO_12_Sw14_DR_KEQ0182158_04  ? ? ?  on off
HMW_IO_12_Sw14_DR_KEQ0182158_05  ? ? ?  on off
HMW_IO_12_Sw14_DR_KEQ0182158_06  ? ? ?  on off

Mit einem USB_RS485 Adapter bekomme ich das gleiche Ergebnis. Kann es sein das es am Device File liegt?

Grüße,

Manfred

Hi Manfred,

der HMW_IO_12_Sw14_DR ist noch nicht fertig.
Kommt in den nächsten Tagen.

Gruß
Dirk

Hi Dirk,

kann ich irgend etwas beitragen? Außer dem HMW_IO_12_Sw14_DR habe ich noch einen HMW_IO_12_FM und einen HMW-IO-4-FM.

Mit dem USB-RS485 Interface sehe ich die Meldungen des HM485d auf der Konsole. Wären die nützlich? Wie bekomme ich die in ein Log?

Grüße,

Manfred

Hi Manfred,

Zitatkann ich irgend etwas beitragen

Immer mal wieder mit testen fällt mir im Moment nur ein :)

ZitatAußer dem HMW_IO_12_Sw14_DR habe ich noch einen HMW_IO_12_FM und einen HMW-IO-4-FM.

Ich habe die entsprechenden Devicefiles grade mit eingecheckt. Allerdings ist das Parsing noch nicht ganz komplett. Daher funktioniert hier noch nicht alles. Den HMW-IO-4-FM könnte du aber schon mal ausprobieren.

ZitatMit dem USB-RS485 Interface sehe ich die Meldungen des HM485d auf der Konsole. Wären die nützlich? Wie bekomme ich die in ein Log?

Mit folgendem Attribut geht das in ein Logfile:
attr HM485_LAN HM485d_logfile </path/zum/logfile>

Gruß
Dirk

Hi Dirk,

Der HMW-IO-4-FM wird angelegt, aber man sieht keine Statusänderung beim Tasten drücken.

Logfile: wenn ich das attr. setze, sehe ich keinen Traffic mehr, RX und TX LEDs bleiben aus. Auserdem wird der daemon beim beenden von FHEM nicht gestoppt, ich muss ihn killen.

[Edit]

was mich auch wundert: ziehe ich den USB-Stecker ab, passiert das:

2013.10.24 23:48:09.518 4: HM485d: Rx: FD022A4B
2013.10.24 23:48:09.522 4: HM485d: Tx: FD032A6100
2013.10.24 23:48:11.835 1: /dev/ttyUSB0 disconnected, waiting to reappear
2013.10.24 23:48:11.845 1: DISCONNECTED
2013.10.24 23:48:11.848 3: Opening SERIAL device /dev/ttyUSB0
2013.10.24 23:48:11.852 3: Can't open /dev/ttyUSB0: Datei oder Verzeichnis nicht gefunden
2013.10.24 23:48:11.855 2: RECONNECTED
2013.10.24 23:48:29.641 4: HM485d: Rx: FD022B4B
2013.10.24 23:48:29.646 4: HM485d: Tx: FD032B6100


Woher kommt das RECONNECTED? spricht der daemon mit sich selbst?

Wenn ich den USB Stecker wieder einstecke passiert nix. Wahrscheinlich weil weiter oben schon der Status auf RECONNECTED gewechselt hat. Mehrmaliges Aus/Einstecken wird nicht registriert. Einmal aus, immer aus....




Grüße,

Manfred

Hi Dirk,

wenns loggen nicht tut, dann eben Guttenbergen von der Konsole. Das sind kurze Tastendrücke am WHM-IO-4-FM:


root@RASP-FHEM1:/opt/fhem# 2013.10.24 23:57:23.395 4: HM485d: Rx: FD02024B
2013.10.24 23:57:23.398 4: HM485d: Tx: FD03026100
2013.10.24 23:57:35.370 3: HM485d: Rx:  I[3](3,Y,F,B)(FE) 00003337 -> FFFFFFFF [6] 4B(K) 00005E {BF4E}
2013.10.24 23:57:35.374 4: HM485d: Tx: FD0F0365FFFFFFFFFE000033374B00005E
2013.10.24 23:57:35.413 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 00003337 -> FFFFFFFF [18] 41(A) 001000030646455130303732353836 {466A}
2013.10.24 23:57:35.417 4: HM485d: Tx: FD1B0465FFFFFFFFF80000333741001000030646455130303732353836
2013.10.24 23:57:41.381 3: HM485d: Rx:  I[1](3,Y,F,B)(FA) 00003337 -> FFFFFFFF [6] 4B(K) 010036 {BFA4}
2013.10.24 23:57:41.385 4: HM485d: Tx: FD0F0565FFFFFFFFFA000033374B010036
2013.10.24 23:57:41.419 3: HM485d: Rx:  I[2](3,Y,F,B)(FC) 00003337 -> FFFFFFFF [18] 41(A) 011000030646455130303732353836 {C162}
2013.10.24 23:57:41.434 4: HM485d: Tx: FD1B0665FFFFFFFFFC7C0000333741011000030646455130303732353836
2013.10.24 23:57:46.590 3: HM485d: Rx:  I[3](3,Y,F,B)(FE) 00003337 -> FFFFFFFF [6] 4B(K) 020062 {6B7C}
2013.10.24 23:57:46.594 4: HM485d: Tx: FD0F0765FFFFFFFFFE000033374B020062
2013.10.24 23:57:46.633 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 00003337 -> FFFFFFFF [18] 41(A) 021000030646455130303732353836 {AC96}
2013.10.24 23:57:46.637 4: HM485d: Tx: FD1B0865FFFFFFFFF80000333741021000030646455130303732353836
2013.10.24 23:57:51.899 3: HM485d: Rx:  I[1](3,Y,F,B)(FA) 00003337 -> FFFFFFFF [6] 4B(K) 0300FA {9A68}
2013.10.24 23:57:51.903 4: HM485d: Tx: FD0F0965FFFFFFFFFA000033374B0300FA
2013.10.24 23:57:51.937 3: HM485d: Rx:  I[2](3,Y,F,B)(FC) 00003337 -> FFFFFFFF [18] 41(A) 031000030646455130303732353836 {2B9E}
2013.10.24 23:57:51.954 4: HM485d: Tx: FD1B0A65FFFFFFFFFC7C0000333741031000030646455130303732353836


Grüße,

Manfred

ZitatLogfile: wenn ich das attr. setze, sehe ich keinen Traffic mehr, RX und TX LEDs bleiben aus.

Das ist merkwürdig, muss ich mal prüfen.

ZitatAuserdem wird der daemon beim beenden von FHEM nicht gestoppt, ich muss ihn killen.

Hast du "HM485d_detatch" gesetzt? weil dann bleibt der Daemon laufen auch wenn man FHEM beendet.
amit sollen weiter nachrichten vom Bus empfangen werden, auch wenn FHEM nicht läuft. Nach dem Start von FHEM wird der Buffer dann ausgelesen. Funktioniert aber noch nicht vollständig.

Man kann den Daemon auch von FHEM beenden und neu starten. Dafür muss HM485d_bind aber gesetzt sein.
Dann kann man
set HM485_LAN hm485d status
set HM485_LAN hm485d start
set HM485_LAN hm485d stop
set HM485_LAN hm485d restart

ausführen.

Ich glaube ich muss langsam mal anfangen die Doku zu schreiben :)

Zitatwenns loggen nicht tut, dann eben Guttenbergen von der Konsole. Das sind kurze Tastendrücke am WHM-IO-4-FM:

zumindestens kommen die Key-Events an.

Gruß
Dirk

Hi Dirk,

das ist meine config:

### HM485 Interface (WIZ108SR)
#
define HM485_LAN HM485_LAN localhost:2000
attr HM485_LAN HM485d_bind 1
attr HM485_LAN HM485d_device /dev/ttyUSB0
attr HM485_LAN HM485d_logVerbose 4
attr HM485_LAN HM485d_startTimeout 5
attr HM485_LAN hmwId 00000001
attr HM485_LAN room HM485
attr HM485_LAN webCmd RAW 000085CD 98 00000001 780F00:discovery start

Der daemon wird beendet, wenn ich fhem stoppe. Aber nicht wenn ich ein Logfile angebe. Dann sehe ich auch keinen Traffic auf dem Bus. Beim HMW_IO_12_Sw14_DR sehe ich auch nicht bei allen Befehlen Traffic. Außerdem gibts Fehlermeldungen im Log, z.B.:

Use of uninitialized value $adressStep in multiplication (*) at FHEM/lib/HM485/ConfigurationManager.pm line 136.
Use of uninitialized value $adressStart in addition (+) at FHEM/lib/HM485/ConfigurationManager.pm line 136.


das war ein set config auf Kanal #9

Ich könnte den meinen Versuchsaufbau an der Firewall in die DMZ hängen und Remotezugriff ermöglichen, wenn das weiter hilft.

Grüße,

Manfred

Hi Manfred,

es gibt hier wohl noch parsing Probleme der Device Files.
Das muss ich mir am Wochenende mal anschauen.

ZitatIch könnte den meinen Versuchsaufbau an der Firewall in die DMZ hängen und Remotezugriff ermöglichen, wenn das weiter hilft.

Vielleicht komme ich da später mal drauf zurück.

Gruß
Dirk

Hallo Dirk,

vielen Dank für Deine Mühe!!! Bei mir schaltet und tastet und funktioniert jetzt alles einwandfrei. Was kann man sich mehr wünschen?
Jetzt bin ich gerade dabei ein Codeschloss mit RFID Reader in meine Alarmanlage á la FHEM/Homematic zu integrieren. Ein Traum!

Viele dankbare Grüße
Jan

Hi zusammen,

ich hatte gerade leider nur kurz Zeit die neue Version einmal zu testen und hab es soweit auch zum laufen bekommen. Also der HM485d läuft, erkennt das serielle Geräte und schickt und empfängt auch etwas, allerdings werden bei mir nach dem Discovery keine Geräte angelegt. Ich habe zur Zeit ein HMW-IO-12-Sw7-DR und einen HMW-LC-BI1-DR angeschlossen. Im Anhang mal den Auszug aus meiner Logdatei. Ich werde morgen abend nochmal weiterforschen.

MfG
Matthias

Hi Matthias,

Zitatallerdings werden bei mir nach dem Discovery keine Geräte angelegt

Laut Log läuft discovery normal durch, findet aber nix. Daher wird nix angelegt.
Bitte prüfe einmal ob was passiert, wenn du am HMW-IO-12-Sw7-DR einen Eingang auslöst (kurz gegen Masse verbinden).
Hier müsste im Log vom hm485d dann Ausgaben kommen und das Gerät auch angelegt werden.

Ansonsten prüfe bitte noch mal deine Bus-Verkabelung?
Was für ein Interface hast du? RS485-USB?
Gibt es hier eine "Data-LED"? Diese sollte blinken wenn auf dem Bus Datenverkehr ist.
Das sollte sowohl beim Discovery sein, als auch wenn du ein Gerät bedienst.

Gruß
Dirk

Hi Dirk,

bei mir ist es ja auch so dass discovery nichts findet, wenn ich beim HM485d das Logging einschalte, weil er offensichtlich mit sich selbst spricht. Die Comm-LEDs meines KMtronic Interfaces bleiben aus.
Ich weiß nicht ob Matthias von der Konsole kopiert hat oder in eine Datei logt, oder von der Konsole kopiert.


Grüße,

Manfred

Hi Manfred und Matthias,

ZitatDie Comm-LEDs meines KMtronic Interfaces bleiben aus.

Die Comm-LED's sind von der Software unabhängig und müssen bei Datenverkehr auf dem Bus auch blinken wenn der hm485d nix macht.

Wenn nicht, sollte es ein Problem mit der Busverkabelung geben.
Bitte nicht nur A und B, sondern auch GND mit verkabeln.
Nur A und B können zwar funktionieren, bei Potentialunterschieden zwischen den Geräten gibt es so aber Störungen.

Könnt ihr das bitte einmal überprüfen.

Gruß
Dirk

Achso,

Einen Busabschluss habt ihr aber angeschlossen?

Gruß
Dirk

Hi Dirk,

mein Fehler. Der fehlende Abschlusswiederstand war schuld. Komischerweise hat aber die Businstallation ohne Abschlusswiederstand mit der ersten Version deines Moduls ohne Probleme funktioniert. Ich konnte zumindest problemlos RAW Befehle senden.

Nach der Montage des Buswiederstandes hat das Discovery auf jeden Fall auch funktioniert. Com LEDs funktionieren aber nicht wirklich.

Was ist jetzt noch nicht gefunden habe, wie ich einen Aktor also einen Output am 12w7 setzen kann. Muss ich weiterhin RAW Befehle senden?

Und leider wird der Jalousienaktor noch nicht im Discovery erkannt. Kann aber aber noch an meiner Verkabelung liegen. Ich werde nochmal weiterprobieren.
Update: Auch dieser Fehler lag an meiner fliegenden Verkabelung. Der Jalosienaktor wird jetzt auch erkannt.

PS: Im Anhang noch ein Log (wie vorhin auch von der Konsole und nicht aus dem File) mit ein paar uninitialized Value fehlern.

PSPS: Hier nochmal die uninitialized Value Fehler. Die erscheinen auf der Konsole, wenn ich im Gerät des Channels auf "set config" drücke:
Use of uninitialized value $hwType in hash element at FHEM/lib/HM485/Device.pm line 147.
Use of uninitialized value $modelGroup in concatenation (.) or string at FHEM/lib/HM485/Device.pm line 218.
Use of uninitialized value $modelGroup in concatenation (.) or string at FHEM/lib/HM485/Device.pm line 778.
Use of uninitialized value $modelGroup in concatenation (.) or string at FHEM/lib/HM485/ConfigurationManager.pm line 131.
Use of uninitialized value $subType in concatenation (.) or string at FHEM/lib/HM485/ConfigurationManager.pm line 131.
Use of uninitialized value $adressStep in multiplication (*) at FHEM/lib/HM485/ConfigurationManager.pm line 136.
Use of uninitialized value $adressStart in addition (+) at FHEM/lib/HM485/ConfigurationManager.pm line 136.


Vielen Dank schon mal an alle!

MfG
Matthias

Hi Matthias,

ZitatDer fehlende Abschlusswiederstand war schuld. Komischerweise hat aber die Businstallation ohne Abschlusswiederstand mit der ersten Version deines Moduls ohne Probleme funktioniert.

Ja, ohne Busabschluss auf kurzen Strecken kann funktionieren, muss es aber nicht.

ZitatWas ist jetzt noch nicht gefunden habe, wie ich einen Aktor also einen Output am 12w7 setzen kann. Muss ich weiterhin RAW Befehle senden?

Nach dem Discovery sollte der 12-7er als Gerät angelegt worden sein. Incl. seiner 12+7 Kanäle. Die Kanäle 13-19 sollten ein on / off haben und entsprechend reagieren. Incl. Lampe im WebUI und Rükmeldung.

Die anderen Aktoren kommen nach und nach die nächsten Tage.

ZitatDie erscheinen auf der Konsole, wenn ich im Gerät des Channels auf "set config" drücke

Set Config ist noch nict ganz fehlerfrei. Kommt hoffentlich auch die Tage.

Gruß
Dirk

Hi Dirk,

ZitatNach dem Discovery sollte der 12-7er als Gerät angelegt worden sein. Incl. seiner 12+7 Kanäle. Die Kanäle 13-19 sollten ein on / off haben und entsprechend reagieren. Incl. Lampe im WebUI und Rükmeldung..

Stimmt. Jetzt nach einem FHEM Neustart sind die On/Off Buttons da!?!?

Perfekt! Danke!

MfG
Matthias

Hi Dirk,

Zitat von: Dirk am 27 Oktober 2013, 12:15:08
Hi Manfred und Matthias,
Die Comm-LED's sind von der Software unabhängig und müssen bei Datenverkehr auf dem Bus auch blinken wenn der hm485d nix macht.

Das ist zumindest bei dem Teil hier nicht richtig:

kmtronic.com usb-to-rs485-ftdi-interface (http://kmtronic.com/usb-to-rs485-ftdi-interface-converter-pcb.html)

Es gibt LEDs für TX und RX. TX blinkt wenn vom PC aus was gesendet wird, auch bei nicht angeschlossenem RS485 Bus.

Bei mir funktioniert es ja prinzipiell. Ich sehe Traffic vom/zum HM585d, aber der Status in FHEM ändert sich nicht, und ich kann keine Ausgänge schalten. Habe noch einen HM RS485HS12-7, für den sollte das Device-File ja passen.

Wenn ich den Homematic Lan Adapter verwende, habe ich das gleiche Ergebnis wie mit dem KMtronic USB <=> USB Adapter. Drum denke ich nicht dass es am nicht angeklemmten GND liegt.

Grüße,

Manfred

Zitat von: Dirk am 27 Oktober 2013, 13:01:58
Achso,

Einen Busabschluss habt ihr aber angeschlossen?

klar, ich habe den Überspannungsschutz mit schaltbarem Busabschluss.

Grüße,

Manfred

Hallo Manfred,

Zitat von: ManfredC am 27 Oktober 2013, 18:32:13
Es gibt LEDs für TX und RX. TX blinkt wenn vom PC aus was gesendet wird, auch bei nicht angeschlossenem RS485 Bus.

Bei getrennten TX und RX-LED's Stimmt das.

ZitatBei mir funktioniert es ja prinzipiell. Ich sehe Traffic vom/zum HM585d

Die RX-LED sollte aber unabhängig von der Software den Traffic auf dem Bus anzeigen.
Wenn RX Beim Schalten am Device nix Tut, tippe ich auf ein Problem mit der Verkabelung.
Dann klappt auch kein Senden. Auch wenn TX entsprechend blinkt.

ZitatHabe noch einen HM RS485HS12-7, für den sollte das Device-File ja passen.

Ja, der sollte schalten, den Status richtig interpretieren und auch Tastendrücke am Device sollten Events in FHEM auslösen.

ZitatWenn ich den Homematic Lan Adapter verwende, habe ich das gleiche Ergebnis wie mit dem KMtronic USB <=> USB Adapter. Drum denke ich nicht dass es am nicht angeklemmten GND liegt.

Ich hatte schon jede Menge Probleme die sich am Ende als Fehler in der Verkabelung herausgestellt hatten wo ich mich in der Software vorher "Dumm und Dämlich" gesucht hatte.

Teste mal FHEM/lib/HM485/test/hs485_dump.pl. (Funktioniert derzeit nur mit RS485-RS232/USB Adapter)
Hier musst du ggf. in Zeile 6
my $DEV = '/dev/ttyUSB1';
deine Interface-Schnittstelle anpassen.

Hier sollte alles was auf dem Bus kommt als RAW-HEX angezeigt werden. Ohne Protokollinterpretation.

Gruß
Dirk

Zitat von: Dirk am 27 Oktober 2013, 18:54:02

Ja, der sollte schalten, den Status richtig interpretieren und auch Tastendrücke am Device sollten Events in FHEM auslösen.
Ich hatte schon jede Menge Probleme die sich am Ende als Fehler in der Verkabelung herausgestellt hatten wo ich mich in der Software vorher "Dumm und Dämlich" gesucht hatte.

den habe ich aber noch nicht.

Zitat
Teste mal FHEM/lib/HM485/test/hs485_dump.pl. (Funktioniert derzeit nur mit RS485-RS232/USB Adapter)
Hier musst du ggf. in Zeile 6

Code Auswählen Erweitern

my $DEV = '/dev/ttyUSB1';
deine Interface-Schnittstelle anpassen.

Hier sollte alles was auf dem Bus kommt als RAW-HEX angezeigt werden. Ohne Protokollinterpretation.

es geht ja prinzipiell. Nur das kein Ausgang schaltet und auch kein Status angezeigt wird. Ich habe ein Netzteil, den Überspannungsschutz mit Abschlusswiderstand, einen HMW_IO_12_Sw14_DR, ein HMW_IO_4_FM und wahlweide das HMW-Lan Interface oder den USB <=> RS485 Adapter. Das ganze an einem Pi. Da ist die Verdrahtung recht übersichtlich.


Ich kann aber keine Relais schalten und sehe auch nur Fragezeichen bei den Eingängen. Ein get Info am HMW_IO_4_FM sieht z.B. so aus:

2013.10.27 19:28:54.596 4: HM485d: Rx: FD0D4B53C8000033371E0000000168
2013.10.27 19:28:54.616 3: HM485d: Tx: (75:1) I[3](0,F,B)(1E) 00000001 -> 00003337 [3] 68(h)  {A6EC}
2013.10.27 19:28:54.640 3: HM485d: Rx: Response: (75) I[2](3,F,B)(7C) 00003337 -> 00000001 [4] 10() 00 {E834}
2013.10.27 19:28:54.665 3: HM485d: Tx: ACK(2,B)(59) 00000001 -> 00003337 [2] {8938}
2013.10.27 19:28:54.669 4: HM485d: Tx: FD054B727C1000
2013.10.27 19:28:54.681 3: HM485d: Rx: ACK(2,B)(59) 00000001 -> 00003337 [2] {8938}
2013.10.27 19:28:54.785 4: HM485d: Rx: FD0D4C53C80000333718000000016E
2013.10.27 19:28:54.799 3: HM485d: Tx: (76:1) I[0](0,F,B)(18) 00000001 -> 00003337 [3] 6E(n)  {2266}
2013.10.27 19:28:54.825 3: HM485d: Rx: Response: (76) I[3](0,F,B)(1E) 00003337 -> 00000001 [12] 46(F) 455130303732353836 {14F6}
2013.10.27 19:28:54.836 3: HM485d: Tx: ACK(3,B)(79) 00000001 -> 00003337 [2] {FC7E}
2013.10.27 19:28:54.840 4: HM485d: Tx: FD0D4C721E46455130303732353836
2013.10.27 19:28:54.910 4: HM485d: Rx: FD0D4D53C8000033371A0000000176
2013.10.27 19:28:54.931 3: HM485d: Tx: (77:1) I[1](0,F,B)(1A) 00000001 -> 00003337 [3] 76(v)  {1E28}
2013.10.27 19:28:54.957 3: HM485d: Rx: Response: (77) I[0](1,F,B)(38) 00003337 -> 00000001 [4] 03() 06 {2F62}
2013.10.27 19:28:54.968 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 00003337 [2] {50B6}
2013.10.27 19:28:54.971 4: HM485d: Tx: FD054D72380306
2013.10.27 19:28:54.993 3: HM485d: Rx: ACK(0,B)(19) 00000001 -> 00003337 [2] {50B6}


Ein Get Config bringt eine Bildschirmausgabe von über einer Seite, ein Get State auf das Device oder einen einzelnen Ausgang lässt weder eine LED auf dem Adapter blinken, nocht gibts eine Ausgabe vom HM485d.

Grüße,

Manfred

Hallo Dirk,

setzen von HMW_IO_12_Sw14_DR_KEQ0182158_21 als digital Input:

Use of uninitialized value $adressStep in multiplication (*) at FHEM/lib/HM485/ConfigurationManager.pm line 136.
Use of uninitialized value $adressStart in addition (+) at FHEM/lib/HM485/ConfigurationManager.pm line 136.
Use of uninitialized value $addressId in int at FHEM/lib/HM485/ConfigurationManager.pm line 142.
2013.10.27 19:50:15.096 4: HM485d: Rx: FD119753C80000A96E1C000000015700000100
2013.10.27 19:50:15.111 3: HM485d: Tx: (151:1) I[2](0,F,B)(1C) 00000001 -> 0000A96E [7] 57(W) 00000100 {F4AC}
2013.10.27 19:50:15.149 3: HM485d: Rx: ACK(2,B)(59) 0000A96E -> 00000001 [2] {233A}
2013.10.27 19:50:15.152 4: HM485d: Tx: FD03977259
2013.10.27 19:50:35.267 4: HM485d: Rx: FD02984B


Grüße,

Manfred

Zitates geht ja prinzipiell.

Ah, ok. Irgendwie hatte ich das bisher falsch verstanden.
Dein Log sieht auch gut aus.
"get info" fragt die Grundsätzlichen Geräteeigenschaften ab. Also Typ, Seriennummer, Firmware-Version.

ZitatEin Get Config bringt eine Bildschirmausgabe

bei "get config" wird der gesammte benutzte EEprom ausgelesen. Zu je 16 Byte blöcken.
Da kommt dann etwas mehr :)

So sollte aber Discovery auch was finden.

Zitatden habe ich aber noch nicht.

Dann hatte ich das hier falsch verstanden

Zitat von: ManfredC am 27 Oktober 2013, 18:32:13
Habe noch einen HM RS485HS12-7, für den sollte das Device-File ja passen.

Die IO-Leitungen des HMW_IO_4_FM sind Standartmässig auf Eingang geschaltet.
Hier sollte es eine Aktion geben wenn du eine der Leitungen mit GND brückst.
Schalten geht dann nur, wenn diese Auf Ausgang konfiguriert werden.
Da bin ich noch an der Umsetzung.

Welche Geräte hast du alles?

Gruß
Dirk

Zitat von: ManfredC am 27 Oktober 2013, 19:51:45
setzen von HMW_IO_12_Sw14_DR_KEQ0182158_21 als digital Input:

Das setzen der Config ist noch nicht fehlerfrei.
Vor allem die I/O Geräte sind hier noch nicht fertig.

Hi Dirk,

sorry, bei dem HM RS485HS12-7 hatte ich das Wörtchen "bestellt" vergessen ;-)

Zitat von: Dirk am 27 Oktober 2013, 19:56:25

So sollte aber Discovery auch was finden.
Dann hatte ich das hier falsch verstanden
Die IO-Leitungen des HMW_IO_4_FM sind Standartmässig auf Eingang geschaltet.
Hier sollte es eine Aktion geben wenn du eine der Leitungen mit GND brückst.

Ich sehe eine Aktion im Terminalfenster, aber die Stausseite in FHEM zeigt weiter ????

ZitatSchalten geht dann nur, wenn diese Auf Ausgang konfiguriert werden.
Da bin ich noch an der Umsetzung.

Wäre ja schon froh wenn ich es als Input nutzen könnte. Mein Junior baut ein Haus. Die HMW_10_4 sollen als Tasterschnittstelle dienen.

ZitatWelche Geräte hast du alles?

HMW_IO_4_FM
HMW_IO_12_Sw14_DR
HMW_IO_12_FM

Beim triggern eines Eingangs am HMW_IO_12_Sw14_DR sehe ich Daten, aber keine Statusänderung in FHEM, nur ????
Relais schalten nicht
Eingang am HMW_IO_4_FM =>Daten auf der Konsole, aber nur ???? in Fhem.

Bei "Get State" am HMW_IO_12_Sw14_DR_KEQ0182158_15 sollte doch auch Daten zum Gerät gehen und auch zurück? Ich sehe nix auf der Konsole, und auch keine LED-Aktion.

Grüße,

Manfred

Hi Manfred,

ZitatBeim triggern eines Eingangs am HMW_IO_12_Sw14_DR sehe ich Daten, aber keine Statusänderung in FHEM, nur

Ah, jetzt lüftet soich der Nebel :)

Also das einzigste was derzeit ohne RAW-Befehle funktioniert ist der HMW-IO-12-Sw7-DR und der HMW-LC-Sw2-DR.

Die Lösung ist also recht einfach.
Noch ein bisschen gedulden :)

Ich schau mal, ob ich die ein Paar RAW-Befehle für den HMW-IO-12-Sw14-DR zusammenstellen kann.
Dann kannst du das schon mal schalten.

Gruß
Dirk

Hallo Manfred,

hier die RAW-Befehle um die Ausgänge des HMW_IO_12_Sw14_DR zu schalten:

set HM485_LAN RAW TTTTTTTT 98 00000001 73AAVVVV

TTTTTTTT: Target Adresse
AA:       Nummer des Ausgangs (00 - 0C) wobei die Zähliung bei 0 beginnt und ein HEX-Wert ist
VVVV:     Value ans HEX-Zahl


Die Ausgänge 00 bis 05 sind die Relais-Ausgänge
Value: 03FF = Ein, Value: 0000 = aus

Die Ausgänge 06 bis 0C sind die Digitalausgänge. Hier gilt das gleiche wie oben.

Wenn diese Ausgänge allerdings als Frequenzausgang konfiguriert sind, dann gilt:
Value entspricht hier dann der Frequenz in Milliherz:
1000, also 03E8 Hex entspricht z.B. 1 Herz
50000 also C350 Hex entspricht 50 Herz

Hier also das erste Relais eines Aktors mit der Adresse 01234567 erst ein, dann aus
set HM485_LAN RAW 01234567 98 00000001 730003FF
set HM485_LAN RAW 01234567 98 00000001 73000000


Gruß
Dirk

Hallo Dirk,

nur mal interessehalber: woher nimmst Du dieses Wissen über die Homematic Protokolle? Gibt es dazu Dokumente? Benutzt Homematic einen Standard?

Grüße
Jan

Hi Jan,

das Homematic-Wired Protokoll setzt auf dem HS485 Protokoll auf, welches vor einigen Jahren von ELV veröffentlicht wurde.
Die Erweiterungen galt es also "nur" durch mithören auf dem Bus heraus zu finden.
Die Daten der einzelnen Frames sind wiederum in den Device-XML-Dateien beschrieben welche der Firmware der CCU beiliegen.

Gruß
Dirk

Hallo Dirk,

Zitat von: Dirk am 28 Oktober 2013, 00:11:39
Hallo Manfred,

hier die RAW-Befehle um die Ausgänge des HMW_IO_12_Sw14_DR zu schalten:

Danke, ich bin bis Mittwoch oder Donnerstag auf Dienstreise. Werde es gleich testen wenn ich zu Hause bin. Bis dahin sollte auch der HM RS485HS12-7 geliefert worden sein.

Danke für Deine Arbeit!

Grüße,

Manfred

Hi Dirk,

mir ist noch ne Kleinigkeit aufgefallen. Wenn ich über das Mobile Webinterface (übers Iphone) einen Aktorkanal setze dauert es ziemlich, bis der Status (also das Lampenicon) geändert wird. Das führt dann ab- und zu dazu, dass die Lampen mehrfach ein und ausgeschaltet wird  ;). Ich denke mal das hängt damit zusammen, dass auf die Rückmeldung vom Aktor gewartet wird, ob der Befehl umgesetzt wurde. Richtig?

Ansonsten läuft das HMW-IO-12-Sw7-DR was die Aktorkanäle angeht schon sehr gut bei mir im Produktiveinsatz. Die Sensorkanäle werde ich dann jetzt am Wochenende mal angehen. Ich werde mal ein paar Taster auflegen und versuche damit schon mal einen Zuhausestatus umzusetzten. Und falls ich es noch schaffe, werde ich auch schon mal eine Jalousie auf den Jalousienaktor auflegen.

MfG
Matthias.

Hi Matthias,

Zitat
Ich denke mal das hängt damit zusammen, dass auf die Rückmeldung vom Aktor gewartet wird, ob der Befehl umgesetzt wurde. Richtig?

Die Rückmeldung kommt vom Aktor in der Regel innerhalb von 100ms.
Ich habe das auch grade mal getestet. Ich vermute eher das das vielleicht an Longpoll o.Ä. liegt.
Zumindestens werden die Icons nocht immer aktualisiert. Ich bekomme die aktualisierten Icons teilweise erst nach Reload der Seite.

Das muss ich mir später dann mal ansehen.

Gruß
Dirk

Nabend zusammen,

ich habe den Masterbranch wieder mal aktualisiert.

Es gab Fixes beim Lesen und Schreiben der Settings für das Device bzw. für die Channels.
Somit kann jetzt auch das Verhalten der Kanäle und andere Einstellungen geändert werden (z.B. Ein-/Ausgang). Diese Einstellung werden bei der Kanalanzeige aber noch nicht berücksichtigt. Vor dem Ändern der Einstellungen bitte mit "get <name> config" die EEprom-Daten vom Device lesen.

Das Parsing der Frames habe ich gefixt bzw. erweitert

Die ersten 6 Schaltausgänge des HMW-IO12-SW14-DR lassen sich nun, wie von FHEM gewöhnt, mit on/off schalten und reporten nun auch den korrekten Status

Gruß
Dirk

Hallo Dirk,

leider funktioniert das bei mir immer noch nicht. Ich habe ein HMW-IO12-SW14-DR am WIZ108SR-Modul.
Die fhem.cfg sieht so aus:
### HM485 Interface (WIZ108SR)#
define HM485_LAN HM485_LAN localhost:2000
attr HM485_LAN HM485d_bind 1
attr HM485_LAN HM485d_device 192.xxx.xxx.xx:5000
attr HM485_LAN HM485d_logVerbose 4
attr HM485_LAN HM485d_logfile ./log/RS485.log
attr HM485_LAN hmwId 00000001
attr HM485_LAN room HM485
attr HM485_LAN webCmd RAW 0000A9B4 98 00000001 780F00:discovery start.

Schließen eines Einganges am HMW-IO12-SW14-DR wird folgendermaßen geloggt:

2013.11.01 09:55:17.606 4: HM485d: Tx: FD0F3265FFFFFFFFFC7C0000A9B469110000
2013.11.01 09:55:17.685 3: HM485d: Rx:  I[3](3,Y,F,B)(FE) 0000A9B4 -> FFFFFFFF [6] 69(i) 1103FF {D176}
2013.11.01 09:55:17.688 4: HM485d: Tx: FD0F3365FFFFFFFFFE0000A9B4691103FF
2013.11.01 09:55:17.707 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 0000A9B4 -> FFFFFFFF [6] 69(i) 110000 {6DE8}
2013.11.01 09:55:17.709 4: HM485d: Tx: FD0F3465FFFFFFFFF80000A9B469110000
2013.11.01 09:55:17.727 3: HM485d: Rx:  I[1](3,Y,F,B)(FA) 0000A9B4 -> FFFFFFFF [6] 69(i) 1103FF {2366}
2013.11.01 09:55:17.729 4: HM485d: Tx: FD0F3565FFFFFFFFFA0000A9B4691103FF.

Mit "discovery start" wird aber der HMW-IO12-SW14-DR nicht gefunden und nicht angelegt. Discovery rödelt jetzt endlos vor sich hin.
Habe ich einen Beitrag verpasst, in dem noch ein Spezialtrick beschrieben wurde?
Die Rechte auf den Dateien sind gesetzt und ich habe auch die alten Dateiversionen vor dem Aktualisieren vorsichtshalber komplett rausgeschmissen...wo kann ich denn jetzt noch ansetzen?

Hallo Uwe.

dein Log sieht gut aus.
Allerdings werden die Eingänge derzeit nicht verarbeitet. Du kannst beim 12-14er im Moment "nur" die ersten 6 Ausgänge schalten.
An den Eingängen arbeite ich aktuell.

Und Discovery beendet sich bei dir nicht, und findet keine Geräte?
Discovery reportet übrigens nur Geräte welche noch nicht definiert wurden.

Gruß
Dirk

ZitatUnd Discovery beendet sich bei dir nicht, und findet keine Geräte?

Nein, läuft ewig und nein, findet  keine Geräte  :(

ZitatDiscovery reportet übrigens nur Geräte welche noch nicht definiert wurden.

Der HMW-IO12-SW14-DR ist noch nicht definiert. Ich hatte ja immer drauf gehofft, dass er mal gefunden wird...

Hi Uwe,

ZitatNein, läuft ewig und nein, findet  keine Geräte

Bitte nach einem abgebrochenem Discovery einmal
set HM485_LAN broadcastSleepMode off
ausführen

Kannst du mir mal den Log bzw. die Ausgabe von der Console vom hm485d während des Discovery schicken.
Normalerweise wird ein Gerät auch automatisch angelegt, wenn FHEM es zum ersten Mal "sieht". Also nachdem z.B. an dem Gerät ein Eingang betätigt wurde.

Ansonsten versuche mal deinen HMW-IO-12-Sw14-DR per per Hand zu definieren.

define <name> HM485 <Adresse>
attr <name> HM485 <Adresse> model HMW_IO_12_Sw14_DR

Die Adresse geht aus deinem Log hervor: 0000A9B4

Anschliessend bitte mal ein
get <name> info
ausführen. Damit sollte das Modul die noch fehlenden Informationen wie Seriennummer und Firmware-Version an FHEM übermitteln. Auch sollten dadurch die Channels angelegt werden.

Falls das nicht funktioniert nehme ich auch gerne den/die Logs. Evtl. auch per PN.
Hast du noch andere Module?

Gruß
Dirk

Hi Dirk,

so, der HMW_LC_Bl1_DR ist jetzt für mein Büro verkabelt und wenn ich die Tasten am Aktor drücke, fahren die Jalousien auch schon hoch und runter.

Erste Sache die mir aufgefallen ist:
Wenn ich ein "get config all" am Device (HMW_LC_Bl1_DR_JEQ0271568) mache kommt mehrfach folgendens:
2013.11.04 19:52:14 3: HM485_LAN: ACK: (217)
2013.11.04 19:52:14 3: HM485_LAN: Response: (217) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Also gehe ich mal davon aus, dass der Aktor generell antwortet und richtig am Bus verkabelt ist. Wenn ich jetzt allerdings am Kanal (blind) HMW_LC_Bl1_DR_JEQ0271568_03 die Konfig speichern will (Zeiten für hoch und runter z.B.) kommt
2013.11.04 19:55:13 3: HM485: Set config for HMW_LC_Bl1_DR_JEQ0271568_03:  logging=off
2013.11.04 19:55:13 3: HM485: Set config for HMW_LC_Bl1_DR_JEQ0271568_03: reference_run_counter=0
2013.11.04 19:55:13 3: HM485: Set config for HMW_LC_Bl1_DR_JEQ0271568_03: reference_running_time_top_bottom=794
2013.11.04 19:55:13 3: HM485: Set config for HMW_LC_Bl1_DR_JEQ0271568_03: change_over_delay=0
2013.11.04 19:55:13 3: HM485: Set config for HMW_LC_Bl1_DR_JEQ0271568_03: reference_running_time_bottom_top=794
2013.11.04 19:55:14 3: HM485: RESPONSE TIMEOUT for 00009F15

Das mal nur so als Hinweis.
Tastendrücke werden auch erkannt:
2013.11.04 19:56:24 3: HM485_LAN: Event: I[0](2,Y,F,B)(D8) 00009F15 -> FFFFFFFF [4] 4B(K) 01
2013.11.04 19:56:24 2: HM485: HMW_LC_Bl1_DR_JEQ0271568_02: press_long -> press_long 0
2013.11.04 19:56:25 3: HM485_LAN: Event: I[1](2,Y,F,B)(DA) 00009F15 -> FFFFFFFF [4] 4B(K) 01
2013.11.04 19:56:28 3: HM485_LAN: Event: I[1](2,Y,F,B)(DA) 00009F15 -> FFFFFFFF [16] 41(A) 01150003064A45513032373135
2013.11.04 19:56:30 3: HM485_LAN: Event: I[2](2,Y,F,B)(DC) 00009F15 -> FFFFFFFF [4] 4B(K) 00
2013.11.04 19:56:30 2: HM485: HMW_LC_Bl1_DR_JEQ0271568_01: press_long -> press_long 56
2013.11.04 19:56:33 3: HM485_LAN: Event: I[0](2,Y,F,B)(D8) 00009F15 -> FFFFFFFF [4] 4B(K) 00
2013.11.04 19:56:33 3: HM485_LAN: Event: I[1](2,Y,F,B)(DA) 00009F15 -> FFFFFFFF [4] 4B(K) 00
2013.11.04 19:56:34 3: HM485_LAN: Event: I[3](2,Y,F,B)(DE) 00009F15 -> FFFFFFFF [16] 41(A) 00150003064A45513032373135


Leider habe ich bislang noch nicht herausgefunden, wie ich den Aktor setzen kann. Den RAW Befehl, den Du mir mal genannt hast, kann ich leider nicht mehr verwenden und ein SET XX funktioniert auch nicht. Hast Du noch einen Tip für mich?

Besten Dank!

MfG
Matthias

Zitat
Wenn ich ein "get config all" am Device (HMW_LC_Bl1_DR_JEQ0271568) mache kommt mehrfach folgendens:
2013.11.04 19:52:14 3: HM485_LAN: Response: (217) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2013.11.04 19:52:14 3: HM485_LAN: ACK: (217)

Ein get-Config ließt blockweise den Eeprom des Device aus. Das sind die entsprechenden Antworten.

Beim HMW_LC_Bl1_DR bitte noch etwas Gedult.
Die Grundfunktionen sind zwar schon da, aber diese habe ich noch nicht abschließend getestet.
Setzen geht hier auch noch nicht.

Zitat
Den RAW Befehl, den Du mir mal genannt hast, kann ich leider nicht mehr verwenden und ein SET XX funktioniert auch nicht.

RAW-Befehle müssen immer über das Interface (z.B. HM485_LAN) abgesetzt werden.
Ansonsten schick mir mal die Fehlermeldungen

Gruß
Dirk

Hi Dirk,

oh man. Der Tag war lang. Im Prinzip ist es an der Groß- und Kleinschreibung gescheitert. Ich hatte den Befehl von damals bei mir aus der Config kopiert und da war RAW klein geschreiben. Jetzt mit RAW in Großbuchstaben gehts.

set HM485_LAN RAW 00009F15 98 00000001 7802C8 (Offen)
set HM485_LAN RAW 00009F15 98 00000001 7802C9 (Stop)
set HM485_LAN RAW 00009F15 98 00000001 780200 (Geschlossen)

Perfekt! Danke!

MfG
Matthias

Hi Matthias,

Zitat
Ich hatte den Befehl von damals bei mir aus der Config kopiert und da war RAW klein geschreiben.

Ja. Das habe ich in Grossbuchstaben umbenannt, dammit es als erstes in der set-Liste steht :)

Gruß
Dirk

Hallo zusammen,

es gibt ein neues Update im Master
Bei Geräten wie HMW-IO-12-Sw14-DR, HMW_IO_4_FM usw. können die Ein/Ausgangskanäle nun konfiguriert und per set on / off geschaltet werden. Auch der Status wird von FHEM entsprechend ausgewertet.

Das Ganze funktioniert derzeit ausschließlich für auf Ausgang konfigurierte Kanäle.

Gruß
Dirk

Hallo,

so ich will jetzt auch mal in das Thema Wired einsteigen.  8)
Ich habe mir mal ein Lan Gateway, Busabschluss und ein IO 12 SW 7 zugelegt. Ich habe auch alles soweit in Fhem rein bekommen und die Kanäle wurden alles angelegt.  ;D

Die Ausgänge kann ich auch per On Off schalten nur bei den Eingängen stehen ??? drin. Wenn ich einen angeschlossenen Taster drücke wird im entsprechend Kanal auch press_long oder press_short geloggt.
Ist dort einfach die Entwicklung noch nicht so weit fortgeschritten oder habe ich irgendwo einen Fehler drin?

Hier mal einen Ausschnitt aus meinem Log.
2013.12.13 20:47:57 3: HM485_LAN: keepalive msgNo: 35
2013.12.13 20:47:57 3: HM485_LAN: Alive: (35) 3030
2013.12.13 20:48:03 3: HM485_LAN: Event: I[2](0,Y,F,B)(9C) 000091DC -> FFFFFFFF [4] 4B(K) 00
2013.12.13 20:48:03 2: HM485: HMW_IO_12_Sw7_DR_JEQ0310645_01: press_long -> press_long 36
2013.12.13 20:48:03 3: HM485_LAN: Event: I[3](0,Y,F,B)(9E) 000091DC -> FFFFFFFF [4] 4B(K) 00
2013.12.13 20:48:03 3: HM485_LAN: Event: I[0](0,Y,F,B)(98) 000091DC -> FFFFFFFF [16] 41(A) 00120003064A45513033313036
2013.12.13 20:48:06 3: HM485_LAN: Event: I[1](0,Y,F,B)(9A) 000091DC -> FFFFFFFF [4] 4B(K) 0B
2013.12.13 20:48:06 2: HM485: HMW_IO_12_Sw7_DR_JEQ0310645_12: press_short -> press_short 20
2013.12.13 20:48:07 3: HM485_LAN: Event: I[2](0,Y,F,B)(9C) 000091DC -> FFFFFFFF [16] 41(A) 0B120003064A45513033313036
2013.12.13 20:48:08 3: HM485_LAN: TX: (36) I[1](0,F,B)(1A) 00000001 -> 000091DC [2] FF(�)
2013.12.13 20:48:09 3: HM485_LAN: ACK: (36)
2013.12.13 20:48:09 3: HM485_LAN: Response: (36)
2013.12.13 20:48:09 3: HM485_LAN: TX: (37) I[2](0,F,B)(1C) 00000001 -> 000091DC [2] FF(�)
2013.12.13 20:48:09 3: HM485_LAN: ACK: (37)
2013.12.13 20:48:09 3: HM485_LAN: Response: (37)
2013.12.13 20:48:09 3: HM485_LAN: TX: (38) I[3](0,F,B)(1E) 00000001 -> 000091DC [2] FF(�)
2013.12.13 20:48:09 3: HM485_LAN: ACK: (38)
2013.12.13 20:48:09 3: HM485_LAN: Response: (38)
2013.12.13 20:48:09 3: HM485_LAN: TX: (39) I[0](0,F,B)(18) 00000001 -> 000091DC [5] 78(x) 0CC8
2013.12.13 20:48:09 3: HM485_LAN: ACK: (39)
2013.12.13 20:48:09 3: HM485_LAN: Response: (39) 690CC800
2013.12.13 20:48:09 2: HM485: HMW_IO_12_Sw7_DR_JEQ0310645_13: state -> on
2013.12.13 20:48:10 3: HM485_LAN: TX: (40) I[1](0,F,B)(1A) 00000001 -> 000091DC [2] FF(�)
2013.12.13 20:48:11 3: HM485_LAN: ACK: (40)
2013.12.13 20:48:11 3: HM485_LAN: Response: (40)
2013.12.13 20:48:11 3: HM485_LAN: TX: (41) I[2](0,F,B)(1C) 00000001 -> 000091DC [2] FF(�)
2013.12.13 20:48:11 3: HM485_LAN: ACK: (41)
2013.12.13 20:48:11 3: HM485_LAN: Response: (41)
2013.12.13 20:48:11 3: HM485_LAN: TX: (42) I[3](0,F,B)(1E) 00000001 -> 000091DC [2] FF(�)
2013.12.13 20:48:11 3: HM485_LAN: ACK: (42)
2013.12.13 20:48:11 3: HM485_LAN: Response: (42)
2013.12.13 20:48:11 3: HM485_LAN: TX: (43) I[0](0,F,B)(18) 00000001 -> 000091DC [5] 78(x) 0C00
2013.12.13 20:48:11 3: HM485_LAN: ACK: (43)
2013.12.13 20:48:11 3: HM485_LAN: Response: (43) 690C0000
2013.12.13 20:48:11 2: HM485: HMW_IO_12_Sw7_DR_JEQ0310645_13: state -> off

Erstmal Lob und Dank für die Arbeit die ihr euch mit dem Thema macht  :D

Grüße
Markus

Hallo Marcus,

ZitatIst dort einfach die Entwicklung noch nicht so weit fortgeschritten ...

So ist es. und durch den "Vorweihnachtsstress" musste die Entwicklung leider zurück stehen.
In ein Paar Tagen ist aber wieder mehr Zeit, dann geht es weiter.

Für press_long und press_short sollten aber auch die entsprechenden Events ausgelöst werden. Daher kann man hier ggf. schon mal mit einem entsprechendem Notify arbeiten.

Gruß
Dirk

Ah ok gut zu wissen. Dann weiß ich wenigsten das bis hier hin mal alles passt bei mir  ;D.

Ja ich muss mal ausprobieren was ich per notify noch umsetzten kann, bin aber derzeit Zeitlich auch nicht so frei  ::)

Hallo Mango0211,

ich nutze im Moment ausschließlich die Rolloaktoren. Deshalb habe ich das Modul von Dirk etwas weiterentwickelt und mit den Rolloaktoren getestet. Für alle anderen HMW Module kann ich keine Funktion garantieren.
Als Empfehlung für das initialisieren in der fhem.cfg noch einfügen:

# Channels initialisieren
define HolInfos at +00:00:10 get WZRolloWest info

# Konfiguration der Channels einlesen
define HolConfig at +00:00:12 get WZRolloWest config all


Ich habe die Datei 10_HM485.pm angehängt. Vor dem Testen bitte von dem Original eine Sicherheitskopie anlegen.
Es gehen jetzt:
- press_short
- state auch automatische Aktuallisierung nach Event...

Viel Spaß beim Testen

Hallo,

habe das Modul von Dirk wieder etwas erweitert. Alles getestet für Rolloaktoren HMW_LC_Bl1_DR.
Es funktionieren jetzt beim Neustart von FHEM das automatische Initialisieren der Channels und auch die Ermittlung des aktuellen State.
Der Vorgang ist etwa nach 10s abgeschlossen.
Damit kann ich dann auch die StateIcons für das entsprechende Rollo in der *.cfg setzen:
# StateIcon der Channels setzen
define SetLevel at +00:01:00 {\
fhem( "attr WZRolloWest_03 devStateIcon level_[0-9]:shutter_closed level_1[0-9]:shutter_closed level_2[0-9]:shutter_7 level_3[0-9]:shutter_7 level_4[0-9]:shutter_6 level_5[0-9]:shutter_5 level_6[0-9]:shutter_4 level_7[0-9]:shutter_3 level_8[0-9]:shutter_2 level_9[0-9]:shutter_1 level_100:shutter_open");;\
}
Die Initialisierungssequenzen aus meinem vorigen Beitrag können mit dem neuen Modul in der fhem.cfg entfallen.
Die Datei 10_HM485.pm habe ich wieder angehängt.
Viel Spaß beim Testen.

Zitat von: Dirk am 23 Oktober 2013, 20:59:17
werden konnten bitte am device ein "get infos" ausführen

- Die Device-Config, also die Register im EEprom werden noch nicht automatisch gelesen. Hierfür erst ein "get config all" am Device ausführen. Auch werden erst danach die Konfigurationswerte korrekt angezeigt.

ich bin dabei das HMW-IO-12-Sw7-DR an FHEM zu Koppeln.
aktuelle Version von HM485 habe ich installiert

Der Eintrag in der fhem.save scheind bei meiner Konfiguratrion so wie oben beschrieben noch nicht zu Funktionieren!

Wenn ich die Befehle "get infos" und "get config all" Nutze bekomme ich die ansage  "Please define infos first"

Wo muss ich ansetzen?

Vielen Dank Grüße

grogra

Hallo grogra,

schicke doch bitte mal den dazugehörigen Abschnitt in deiner fhem.cfg und aus dem Logfile.

Gruß gevoo

Hallo,
ich hänge mich hier auch mal rein. Ich besitze folgende Geräte:
1x HMW-LGW-O-DR-GS-EU
1x HMW-IO-12-Sw14-DR

Diese habe ich an fhem angeschlossen. Die Verschlüsselung habe ich mit NetFinder abgeschaltet und die IP auf .5 geändert. durch rumprobieren habe ich das ganze ans laufen gekriegt und konnte mit RAW-Befehlen die Ausgänge schalten, auch habe ich die Definitionen in FHEM gesehen.
Um den WIKI-Artikel zu schreiben, und eine reproduzierbare Anleitung zu erstellen, habe ich das ganze aus der fhem.cfg wieder gelöscht.
Dann habe ich das LAN-Gateway angelegt:


define HM485_LAN HM485_LAN 192.168.0.5:1000
attr HM485_LAN hmwId 00000001
attr HM485_LAN room HM485


Nun habe ich den Befehl
set HM485_LAN discovery start
ausgeführt. Hierzu eine Frage:

ZitatMit dem Discovery-Befehl wird der gesamte RS485-Bus nach unbekannten HMW Geräten durchsucht.
Nachdem neue Geräte gefunden worden, werden diese automatisch mit FHEM gepairt.

Bedeutet "gepairt", dass die Geräte in der fhem.cfg eingetragen werden? Oder wird Firmwareseitig irgend etwas im 12/14 IO verändert?

Okay, der Discovery-Befehl lieferte im WEB-Frontend gar keine Ausgabe, also hier das Log:

Zitat2014.04.02 17:16:58.846 3: HM485_LAN: Alive: (85) 3030
2014.04.02 17:17:00.265 5: Cmd: >set HM485_LAN discovery start<
2014.04.02 17:17:00.268 3: HM485_LAN: TX: (86) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2014.04.02 17:17:00.269 5: Triggering HM485_LAN (1 changes)
2014.04.02 17:17:00.269 5: Notify loop for HM485_LAN discovery start
2014.04.02 17:17:00.371 3: HM485_LAN: TX: (87) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2014.04.02 17:17:00.376 3: HM485_LAN: Alive: (87) 3032
2014.04.02 17:17:00.884 3: HM485_LAN: Alive: (86) 3031
2014.04.02 17:17:10.269 2: HM485_LAN: Discovery - canceled. No results found within 10 seconds!
2014.04.02 17:17:10.273 3: HM485_LAN: TX: (89) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 5A(Z)
2014.04.02 17:17:10.375 3: HM485_LAN: TX: (90) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 5A(Z)
2014.04.02 17:17:10.382 3: HM485_LAN: Alive: (90) 3032
2014.04.02 17:17:10.890 3: HM485_LAN: Alive: (89) 3031

Dann habe ich ein
set HM485_LAN broadcastSleepMode off
abgesetzt. Trotzdem wird das Gerät nicht gefunden.

Ausserdem ist mir noch nicht klar, was der hm485d.pl ist bzw. wo der läuft. Mein erster Versuch funktionierte ausschliesslich mit den zwei fhem-Modulen (oder irgendwas lief, was jetzt nicht mehr läuft)...

Könnt ihr mir einen Tipp geben?
Sobald ich das verstanden habe, würde ich auch gerne begeistert beim Debuggen und Entwickeln unterstützen, falls Bedarf besteht.

Viele Grüße und schonmal Danke für die Hilfe
Stephan

Hallo Stephan,

ich habe leider noch kein HMW-IO-12-Sw14-DR im Einsatz. Vielleicht kann ich die mit einigen prinzipiellen Sachen helfen.
Dein HMLan Gateway wird in der Weboberfläche angezeigt und hat den Status "open"?

Ein set HM485_LAN discovery start sollte dein I/O Modul erkennen. Alternativ kannst du an einen Eingang ein Signal anlegen, oder das Modul auf andere Weise überreden etwas über den Bus zu senden. Dann müßte es auch erkannt werden. Ein Neustart von FHEM müßte das gleiche Ergebnis liefern.

"gepairt" bedeutet hier, daß das Modul von fhem erkannt wird und sich ansteuern läßt. Im Modul wird nichts geändert. Es erfolgt lediglich die Ablage einer Eprom- Kopie im Speicher deines Rechners. Deren Werte können in der Weboberfläche angezeigt werden.

Die Datei 10_HM485.pm findest du in deiner fhem- Installation im Unterverzeichnis FHEM.

Die hm485d.pl benötigst du nicht, da du das originale HMWGateway benutzt. Das läßt sich direkt ansprechen. Für andere Busadapter benötigst du hm485d.pl als "Emulator".

Gruß gevoo

Zitat von: gevoo am 03 April 2014, 17:29:19
Dein HMLan Gateway wird in der Weboberfläche angezeigt und hat den Status "open"?

check (ja)

Zitat von: gevoo am 03 April 2014, 17:29:19
Ein set HM485_LAN discovery start sollte dein I/O Modul erkennen. Alternativ kannst du an einen Eingang ein Signal anlegen, oder das Modul auf andere Weise überreden etwas über den Bus zu senden. Dann müßte es auch erkannt werden. Ein Neustart von FHEM müßte das gleiche Ergebnis liefern.

Ein "set HM485_LAN discovery start" bricht nach 10 Sekunden erfolglos ab (siehe log im vorherigen Beitrag)
Ein Neustart von fhem (shutdown restart) bringt keine Fortschritte.
Ein reboot des Servers ändert ebenfalls nichts.
Ein an den Eingang angeschlossener Schalter erzeugt folgende Events
014-04-03 23:17:34.080 Global global UNDEFINED HMW_IO_12_Sw14_DR_JEQ0459634 HM485 00009A2B
2014-04-03 23:17:34.249 Global global UNDEFINED HMW_IO_12_Sw14_DR_JEQ0459634 HM485 00009A2B
2014-04-03 23:17:34.765 Global global UNDEFINED HMW_IO_12_Sw14_DR_JEQ0459634 HM485 00009A2B
2014-04-03 23:17:34.933 Global global UNDEFINED HMW_IO_12_Sw14_DR_JEQ0459634 HM485 00009A2B
dadurch wird ein
HM485
HMW_IO_12_Sw14_DR_JEQ0459634
angelegt.
nun kann ich sagen
get HMW_IO_12_Sw14_DR_JEQ0459634 info
was mir die Channels anlegt.
Wie funktioniert das bei Ausgabe-Only-Bausteinen?
Was genau macht der Befehl
get config all
Kann ich auch einzelne Configs auslesen?
Wie kann ich die Ausgänge umschalten/config editieren?

Zitat von: gevoo am 03 April 2014, 17:29:19
Die Datei 10_HM485.pm findest du in deiner fhem- Installation im Unterverzeichnis FHEM.

ja, diese habe ich bereits heruntergeladen. Es hat ja auch schonmal funktioniert. Allerdings wollte ich eine reproduzierbare Anleitung schreiben, und habe die Definitionen gelöscht. Jetzt bekomme ich fhem nicht mehr dazu, sie anzulegen. ;-)

Zitat von: gevoo am 03 April 2014, 17:29:19
Die hm485d.pl benötigst du nicht, da du das originale HMWGateway benutzt. Das läßt sich direkt ansprechen. Für andere Busadapter benötigst du hm485d.pl als "Emulator".

Okay, das bringt schonmal Licht ins Dunkel ... :-)

Hallo Stephan,

das "set HM485_LAN discovery start" nach 10s abbricht, ist so vorgesehen, wenn kein Modul antwortet. Offenbar ist dein I/O Modul damit nicht zum Datenaustausch zu begeistern. Aus den Events kannst du zumindest die ID deines Moduls herausfinden, hier 00009A2B. Damit könntest du es per Hand in der fhem.cfg definieren, z.B. so: define IOModul HM485 00009A2B.
Bei Ausgabe-Only-Bausteinen ist meist ein Taster zum pairen vorhanden, wie auch bei dem HMW_LC_Bl1_DR. Wenn du die Taste betätigst, wird auch ein Event ausgelöst. Normalerweise sollte der Baustein dann auch mit Autocreate in der fhem.cfg angelegt werden.

Config für einen Channel ist nicht möglich. es wird immer der gesamte Eprom gelesen.

Die Ausgänge beim I/O Modul lassen sich derzeit nur mit RAW- Befehlen schalten. Siehe auch in diesem Thread weiter vorn. Da wollte Dirk noch etwas machen. Ich würde das auch übernehmen, habe aber keines zum Testen.

Gruß gevoo

Moin gevoo,

danke für die schnelle Antwort.
Das anlegen der Devices funktioniert bei mir ja, sobald ich einen Eingang betätige. Nur das Discovery macht Probleme.
Wegen dem Umschalten der Ausgänge werde ich mal noch ein wenig in der HMW-Protokoll-Doku lesen, vielleicht kommen mir da ja noch ein paar Erkenntnisse:)

Danke und lg
stephan

Hallo Stephan,

erkennt fhem von deinem I/O Baustein alle Eingänge und Ausgänge?

Vielleicht könnten wir in Zusammenarbeit das Modul 10_HM485.pm noch etwas dafür erweitern?

Gruß Gert

Hallo @all,

bin mal wieder an einer Aufgabenstellen wo es bei mir nicht Funkt. Vieleicht habt Ihre einen Tip für mich?

Ich möchte einen zweiten HM485 LAN Betrieben, nach dem der erste super Funktioniert
Nun habe ich folgendes in die Config eingetragen..


# LAN to RS485 Kopplung im EG
define HM485_LAN HM485_LAN 192.xxx.xxx.110:1000
attr HM485_LAN hmwId 00000001
attr HM485_LAN room EGCenter
attr HM485_LAN verbose 4

# LAN to RS485 Kopplung im OG
define OG.HM485 HM485_LAN 192.xxx.xxx.111:1000
attr OG.HM485 hmwId 00000002
attr OG.HM485 room OGCenter
attr OG.HM485 verbose 4


Wenn ich das cfg speichere erhalten ich folgende Meldung


hmwId 00000001 already used. Please use another one.
Please define OG.HM485 first
Please define OG.HM485 first
Please define OG.HM485 first


Hinweis
der erste HM485 ist derzeit deaktiviert

Was mach ich Falsch?

Danke an alle

grogra

Hallo grogra,

ZitatIch möchte einen zweiten HM485 LAN Betrieben, nach dem der erste super Funktioniert
Nun habe ich folgendes in die Config eingetragen..

Dieses Szenario ist zwar vorgesehen, aber noch ungetestet.
Evtl hast du hier einen Bug gefunden

Zitatder erste HM485 ist derzeit deaktiviert

Wie hast du den deaktiviert?


Gruß
Dirk

Hallo Gert,

Zitat von: gevoo am 04 April 2014, 15:50:13
erkennt fhem von deinem I/O Baustein alle Eingänge und Ausgänge?

Ja, das tut es. Habe auch die Frequenz-Input und Frequenz-Output funktion getestet (dabei wahrscheinlich zwei OC-Ausgänge geschossen) ;-(
Den Analogspannungseingang habe ich dann nicht mehr getestet  :-[ :P

Zitat von: gevoo am 04 April 2014, 15:50:13
Vielleicht könnten wir in Zusammenarbeit das Modul 10_HM485.pm noch etwas dafür erweitern?

(fast) nichts lieber als das... sag mir, was ich tun soll :-)
Habe durchaus ein bisschen Perl-, und programmierkenntnisse, aber bei HMW blick ich (noch) nicht durch...
Gibt es noch andere Module, die mangels Besitz nicht richtig getestet sind?
Baue gerade eine Test-Anlage ( will wissen, was ich im Sommer in meinem Haus verwenden kann), vielleicht komme ich ja noch auf die ein oder andere Idee:-)

@grogra: ich glaube, ich habe irgendwo gelesen, dass das LAN-Gateway nur! auf die ID 1 hört ...

Viele Grüße
Stephan

an dem gerät liegt ein Strom an..

Zitat von: grogra am 04 April 2014, 15:59:06
an dem gerät liegt ein Strom an..

meinst du:

Zitatan dem gerät liegt kein Strom an..

?

Zitat von: abc2006 am 04 April 2014, 15:58:44
Gibt es noch andere Module, die mangels Besitz nicht richtig getestet sind?

Noch einige. Die letzte Zeit hatte ich der Weiterentwicklung leider nur wenig Zeit spendiert.
Das wird sich aber wieder ändern.

Zitatich glaube, ich habe irgendwo gelesen, dass das LAN-Gateway nur! auf die ID 1 hört ...

Grundsätzlich sind die Adresse 00000001 - 000000FF für die Zentrale vorgesehen.
Das ganze wird aber selbst bei der CCU so nicht genutzt. Daher kann man dort auch nur ein HM-Wired Interface definieren

Gruß
Dirk

sorry,

Das HM485 mit der ID00000001 ist derzeit Strom los.
DaS HM485 mit der ID00000002 ist unter Strom und am Netz.

das man nur derzeit eines Verbinden kann geht leider aus den Beschreibungen nicht eindeutig hervor.

Wenn das nicht Klappt kann ich mir von meiner Frau etwas anhören :-) da ich dann ein Kabel quer durch das Haus legen muss. Ursprünglich wollte ich den ersten HM485 alle IO anschließen aber ich bekomme die Leitung nicht durch den Schacht..

Zitat von: grogra am 04 April 2014, 16:08:47
Das HM485 mit der ID00000001 ist derzeit Strom los.

Damit ist es für FHEM aber aktiv, auch wenn es derzeit nicht erreichbar ist.

Zitatdas man nur derzeit eines Verbinden kann geht leider aus den Beschreibungen nicht eindeutig hervor.

Das sollte auch nicht so bleiben :)

Ich kann mir das gerne heute oder morgen Abend man ansehen.

Zitatda ich dann ein Kabel quer durch das Haus legen muss. Ursprünglich wollte ich den ersten HM485 alle IO anschließen aber ich bekomme die Leitung nicht durch den Schacht.

Es könnte hier problematisch werden, wenn du versuchst die Geräte die an unterschiedlichen Interfaces hängen direkt miteinander zu pairen.
Das wird so nicht gehen, da sich die Geräte nicht "sehen".
Die Geräte müssen dann immer über FHEM laufen.

So richtig verstehe ich noch nicht warum du zweit Interfaces brauchst.
Du kannst doch in deinem Schacht nur das Buskabel legen. Wo das Interface sitzt ist egal. Es muss nicht am Anfang vom Bus sein.

Gruß
Dirk

Hallo Stephan,

dann schlage ich vor wir fangen mit dem Schalten der Ausgänge an?
Wird im Webinterface schon on und off hinter dem entsprechenden Channel angezeigt?
Klick bitte mal auf diesen Channel- Link und poste die Configseite. Dann müßte ich für den ersten Versuch erst einmall alle Infos haben.

Gruß gevoo

Hallo Dirk,

ursprünglich wollte ich von dem ersten HM485 an dem ein 12-Sw7 hängt und betrieben wird, in den OG und da Ebenfalls einen zweiten 12-Sw7 an den ersten HM485 hängen. Die Verbindung dazwischen wollte ich mit einer Entsprechenden Leitung 4x 0,25 Geschirmt machen.. (die bekomme ich aber nicht durch den Schacht).

Daher habe ich einen zweiten HM485 in den OB eingebaut und wollte diesen mit einer dLan Verbindung an FHEM hängen.

Grüße

grogra
PS.
siehst Du eine Chance das wir den Bug beheben? Was brauchst Du von mir dazu?

ZitatDaher habe ich einen zweiten HM485 in den OB eingebaut und wollte diesen mit einer dLan Verbindung an FHEM hängen.

Aso.
Dann gibt es aus meiner Sicht 2 Möglichkeiten.

1. Zwei Interfaces wie du es aktuelle planst.
Peerings müssen dann aber immer über FHEM laufen.

2. Verlängern des Busses über 2 Netzwerk-RS485-Adapter
RS485Bus <-> Netzwerk <-> RS485Bus

Gruß
Dirk

Hallo Dirk,

Mir Persönlich wäre die Variante das man 256 x HM485 in ein LAN nehmen kann und daran die IO etc. usw. Anschließt. Da ich in meinen Haus eine umfangreiche Netzwerk Verdrahtung im UG und EG habe. Der Rest über einen dLAN Versorgt ist. (leider ist erst nach dem Umbau die Idee mit der Hausautomatisierung entstanden :-[ ).

In meine Garage, Gartenhaus etc. habe ich z.B. dLan jedoch reicht die Funkstrecke von HMLAN nicht aus. Da gibt es jedoch noch massig was Automatisiert werden sollte....

Das man dabei immer über FHEM gehen muss / soll finde ich sehr gut.

Was meinst Du dazu?

Grüße

grogra

Hi Gert:

Anbei eine komplett-Übersicht, einmal die Relais-Channel und einmal die Open-Collector-channel.
Wenn ich in der Übersich einmal auf on oder off klicke, erscheint auch das Glühobst. Kann aber auch mit irgendeiner getesteten und dann vergessenen Einstellung zusammenhängen (autocreate lässt grüßen xD)

@ Dirk: was meinst du mit "peerings müssen immer über fhem laufen? Ich persönlich habe (bis jetzt noch) ausnahmslos alle schaltaktionen über fhem abgewickelt... dass bei ausfall von fhem dann gar nichts mehr geht, ist mir klar, wird evtl noch geändert, aber sehe ich momentan nicht als Problem/hatte ich noch nie ?

Viele Grüße,
Stephan

Zitat von: abc2006 am 04 April 2014, 17:06:21
was meinst du mit "peerings müssen immer über fhem laufen? Ich persönlich habe (bis jetzt noch) ausnahmslos alle Schaltaktionen über fhem abgewickelt

Im Moment ist das korrekt. Das ist aktuell noch nicht implementiert.

Grundsätzlich lassen sich auch mit HM-Wired so genannte Peerings (Direktverknüpfungen) anlegen.
Das ist allerdings im Moment noch nicht von FHEM aus programmierbar.
Damit kann man Schaltaktionen direkt auf einem Aktor ausführen. FHEM muss dafür dann nicht laufen.
Dafür müssen alle betreffenden Geräte aber an einem Bus hängen.

Gruß
Dirk

Hallo Stephan,

hier die erste Testversion:
- wenn du fhem neu gestartet hast, sind dann nach ca. 10 Sekunden die State's der Channel 1-6 und 7-14 gesetzt? Also keine Fragezeichen mehr?
- wenn du in der Weboberfläche die Channels 1-6, durch klicken auf on oder off im Webinterface, schaltest, müßtest du das klicken der Relais hören?
- dann bitte channel 7 "on" klicken --> ins log gehen und mir die letzte Zeile mit HM485_SetChannelState control = ..... posten.

Gruß gevoo

Hallo gevoo,

Zitat von: gevoo am 04 April 2014, 20:18:03
hier die erste Testversion:
- wenn du fhem neu gestartet hast, sind dann nach ca. 10 Sekunden die State's der Channel 1-6 und 7-14 gesetzt? Also keine Fragezeichen mehr?

Ich habe autocreate abgeschaltet und durchlaufe folgende schritte:
- shutdown restart
- taster I12  (kennnummer 20, der wo auf dem Bild frequency steht) betätigen
- auf den angelegten Eintrag klicken
- get info
danach sind alle Devices vorhanden

Bei Channel 03 ist eine ausgeschaltete Lampe, beim Rest Fragezeichen.

und noch ein edit, ist schon spät: bei Channel 1-6 erscheinen die Lampen, wenn ich auf on/off klicke, bei 7-14 leider nicht.

Zitat von: gevoo am 04 April 2014, 20:18:03
- wenn du in der Weboberfläche die Channels 1-6, durch klicken auf on oder off im Webinterface, schaltest, müßtest du das klicken der Relais hören?

Das funktionierte schon vorher. Geht aber immer noch :-)

Zitat von: gevoo am 04 April 2014, 20:18:03
- dann bitte channel 7 "on" klicken --> ins log gehen und mir die letzte Zeile mit HM485_SetChannelState control = ..... posten.


2014.04.04 23:38:44.719 3: HM485_SetChannelState: control = switch.state


Ich hab da so komische Zeichen im Log ... ich versuch die mal noch weg zu bekommen, sieht nach nem codierungsproblem aus..

edit: uppsi, du wolltest ja nur die eine Zeile haben ...

Könntest du mir einen Gefallen tun und oben in die Datei einen Kommentar mit Änderungsdatum/Uhrzeit machen? dann kann ich hier besser den Überblick behalten..  Alternativ, kannst/willst/darfst du es bei github ins rep einchecken?

lg
stephan

Zitat von: Dirk am 04 April 2014, 16:05:05

Zitat von: abc2006 am 04 April 2014, 15:58:44
    Gibt es noch andere Module, die mangels Besitz nicht richtig getestet sind?

Noch einige. Die letzte Zeit hatte ich der Weiterentwicklung leider nur wenig Zeit spendiert.
Das wird sich aber wieder ändern.

Welche denn? Ich wollte mir sowieso noch ein paar Module kaufen, vielleicht nehm ich dann zuerst welche von diesen? (den noch nicht getesteten)

lg
stephan 

Hallo Stephan,

die Idee mit der Versionsnummer war gut. Ich habe diese jetzt einfach einmal auf 0.1.15 festgelegt.

Bitte führe folgendes aus:
- Datei 10_HM485.pm einspielen
- fhem neu starten: shutdown restart
- einige Sekunden warten
--> mit dieser Version sollten sich die Fragezeichen in den aktuellen State umwandeln, ohne daß du etwas eingibst.
Voraussetzung ist, daß du diesmal die Einträge in der fhem.cfg stehen läßt und nicht löscht.

- jetzt sollten sich auch die Channels 07-14 schalten lassen

Erwarte mit Spannung deinen Bericht.

Gruß gevoo

Hallo Gert,

für reproduzierbare Testergebnisse habe ich jetzt mal eine minimal-fhem.cfg angelegt.
Folgende Schritte konnte ich reproduzierbar verifizieren:

- starten von FHEM, es wird nur das (bereits definierte) LGW angezeigt (Bild 1)
- Taster I12 betätigt und mit F5 aktualisiert (Bild 2)
- get HMW_IO_12_Sw14_DR_JEQ0459634 info (Bild 3)
- fhem.cfg:
define HM485_LAN HM485_LAN 192.168.0.5:1000
attr HM485_LAN hmwId 00000001
attr HM485_LAN room HM485
define HMW_IO_12_Sw14_DR_JEQ0459634 HM485 00009A2B
attr HMW_IO_12_Sw14_DR_JEQ0459634 room HM485
define FileLog_HMW_IO_12_Sw14_DR_JEQ0459634 FileLog ./log/HMW_IO_12_Sw14_DR_JEQ0459634-%Y.log HMW_IO_12_Sw14_DR_JEQ0459634
attr FileLog_HMW_IO_12_Sw14_DR_JEQ0459634 logtype text
attr FileLog_HMW_IO_12_Sw14_DR_JEQ0459634 room HM485

- shutdown restart
- Die Ein/Ausgänge sind verschwunden (Bild 4)
- get HMW_IO_12_Sw14_DR_JEQ0459634 info - die IO sind wieder da, aber mit Fragezeichen (Bild 5)
- nun sind in der fhem.cfg gefühlte 1000 Zeilen mehr aufgetaucht (Allerdings nicht nach IO-Nummer sortiert, wäre ein nice-to-have):
define HMW_IO_12_Sw14_DR_JEQ0459634_20 HM485 00009A2B_20
attr HMW_IO_12_Sw14_DR_JEQ0459634_20 firmwareVersion 0.5
attr HMW_IO_12_Sw14_DR_JEQ0459634_20 model HMW_IO_12_Sw14_DR
attr HMW_IO_12_Sw14_DR_JEQ0459634_20 room HM485
attr HMW_IO_12_Sw14_DR_JEQ0459634_20 serialNr JEQ0459634
attr HMW_IO_12_Sw14_DR_JEQ0459634_20 subType digital_input

- in der Übersicht sind immer noch Fragezeichen
- shutdown restart
- jetzt sind bei Ausgang 1-6 (Relais) ausgeschaltete Birnen, die bei klick hörbar und sichtbar den Status ändern ( Bild 6)
- bei digital_analog_output sind weiterhin Fragezeichen, die on/off-Schalter sind verschwunden ( ich könnte schwören, die waren vorher da ..) damit ist auch die Frage beantwortet, ob sich Kanal 7-14 schalten lassen :-)
- bei den digital-Inputs stehen verschiedene Werte (klar, den 20er hab ich benutzt, die anderen jungfräulich, aber warum bei 15 und 16 "???" ?

Viele Grüße
Stephan

PS: ich werde das nachher nocheinmal genauso durchgehen, habs gerade eilig :-)

Hallo Stephan,

erst einmal vielen Dank für deine detailierte Analyse. Sie hat mir geholfen einige Fehler abzustellen.
Jetzt zur Version 0.1.16:
- in deiner Test fhem.cfg sollten nur folgende Zeilen stehen:

define HM485_LAN HM485_LAN 192.168.0.5:1000
attr HM485_LAN hmwId 00000001
attr HM485_LAN room HM485

define HMW_IO_12_Sw14_DR_JEQ0459634 HM485 00009A2B
attr HMW_IO_12_Sw14_DR_JEQ0459634 room HM485
define FileLog_HMW_IO_12_Sw14_DR_JEQ0459634 FileLog ./log/HMW_IO_12_Sw14_DR_JEQ0459634-%Y.log HMW_IO_12_Sw14_DR_JEQ0459634
attr FileLog_HMW_IO_12_Sw14_DR_JEQ0459634 logtype text
attr FileLog_HMW_IO_12_Sw14_DR_JEQ0459634 room HM485

Alles andere kann raus. Das wurde durch einen Programmfehler ins Config geschrieben, den ich verbockt habe. D.h. beim nächsten Versuch sollten in der fhem.cfg
keine weitern Zeilen auftauchen.
- Die State's sollten jetzt korrekt angezeigt werden, war auch ein Fehler.
- Das Modul sollte sich jetzt selbst initialisieren: du solltest kein get info oder get config mehr benötigen

Ich freue mich, wenn du weiter am Ball bleibst und den nächsten Test durchführtst.

Gruß gevoo

Hallo, ich hatte die Frage auch schon einem ander Thread gestellt, dachte aber das passt hier auch ganz gut rein.

http://forum.fhem.de/index.php/topic,10607.180/topicseen.html (http://forum.fhem.de/index.php/topic,10607.180/topicseen.html)

Ich möchte ja am HMW_IO_12_Sw14_DR  4 von 6 digitalen Eingänge nutzen um Kontaktsensoren an den Fenstern zu überwachen. Ich habe nun das Problem das 2 von den 6 Eingängen auf behaviour: digital_input und die übrigen 4 auf frequency_input stehen habe. Sobald ich das frequency_input auf digital_input ändere, fällt einer der Eingänge welche bereits auf digital_input stehen wieder auf frequency_input zurück. Ich kann nur 2 der 6 Eingänge auf digital umstellen. Im anderen Thread habe ich zur Antwort bekommen das man den HMW_IO_12_Sw14_DR derzeit nur über die CCU konfigurieren kann. Ist das richtig oder gibt es noch andere Möglichkeiten?

Gruß
cerberus

Zitat von: gevoo am 06 April 2014, 20:46:35
Hallo Stephan,

erst einmal vielen Dank für deine detailierte Analyse. Sie hat mir geholfen einige Fehler abzustellen.
Jetzt zur Version 0.1.16:
- in deiner Test fhem.cfg sollten nur folgende Zeilen stehen:

Code Auswählen Erweitern


define HM485_LAN HM485_LAN 192.168.0.5:1000
attr HM485_LAN hmwId 00000001
attr HM485_LAN room HM485

define HMW_IO_12_Sw14_DR_JEQ0459634 HM485 00009A2B
attr HMW_IO_12_Sw14_DR_JEQ0459634 room HM485
define FileLog_HMW_IO_12_Sw14_DR_JEQ0459634 FileLog ./log/HMW_IO_12_Sw14_DR_JEQ0459634-%Y.log HMW_IO_12_Sw14_DR_JEQ0459634
attr FileLog_HMW_IO_12_Sw14_DR_JEQ0459634 logtype text
attr FileLog_HMW_IO_12_Sw14_DR_JEQ0459634 room HM485

Alles andere kann raus. Das wurde durch einen Programmfehler ins Config geschrieben, den ich verbockt habe. D.h. beim nächsten Versuch sollten in der fhem.cfg
keine weitern Zeilen auftauchen.


define HM485_LAN HM485_LAN 192.168.0.5:1000
attr HM485_LAN hmwId 00000001
attr HM485_LAN room HM485
define HMW_IO_12_Sw14_DR_JEQ0459634 HM485 00009A2B
attr HMW_IO_12_Sw14_DR_JEQ0459634 room HM485
define FileLog_HMW_IO_12_Sw14_DR_JEQ0459634 FileLog ./log/HMW_IO_12_Sw14_DR_JEQ0459634-%Y.log HMW_IO_12_Sw14_DR_JEQ0459634
attr FileLog_HMW_IO_12_Sw14_DR_JEQ0459634 logtype text
attr FileLog_HMW_IO_12_Sw14_DR_JEQ0459634 room HM485


Zitat
- Die State's sollten jetzt korrekt angezeigt werden, war auch ein Fehler.
- Das Modul sollte sich jetzt selbst initialisieren: du solltest kein get info oder get config mehr benötigen

Es funktioniert leider gar nichts mehr ;-(
Das Modul wird erkannt,wenn ich den Taster drücke. Soweit waren wir ja schon. (Bild 1)
Dafür kann ich kein set discovery mehr absetzen, das dropdown ist jetzt leer. (Bild 4)
Schalter u.ä. sind nicht vorhanden.
Nach einem get info sind die Schalter dann da, mit ??? (Bild 2)
Nach einem shutdown restart sind die Bilder da (Bild 3)

lg
stephan

Hallo Stephan,

danke fürs Testen. Ich brauche noch die dazugehörigen Einträge im log. Ob du mir die noch posten könntest?
Gruß gevoo

ich habe dir mal die gesamte Datei angehängt. Hab ich natürlich nicht drauf geachtet, gelobe Besserung für den nächsten Bericht :-)

lg
stephan

Hallo Stephan,

danke für deine Info's.
Auf ein Neues, warte wieder auf deinen Bericht.

Gruß gevoo

Hi,
etwas genauere Hinweise würden mir helfen :-)
Für mich siehts genauso aus wie vorher (s.u.)
lg
stephan

Edit:
gerade war meine fhem.cfg wieder voll mit einträgen


define HMW_IO_12_Sw14_DR_JEQ0459634_20 HM485 00009A2B_20
attr HMW_IO_12_Sw14_DR_JEQ0459634_20 firmwareVersion 0.5
attr HMW_IO_12_Sw14_DR_JEQ0459634_20 model HMW_IO_12_Sw14_DR
attr HMW_IO_12_Sw14_DR_JEQ0459634_20 room HM485
attr HMW_IO_12_Sw14_DR_JEQ0459634_20 serialNr JEQ0459634
attr HMW_IO_12_Sw14_DR_JEQ0459634_20 subType digital_input

leider nicht reproduzierbar.
Ausserdem habe ich gerade ein 12-Sw7 angeschlossen, von dem ich dachte, dass es mittlerweile gut unterstützt wird. Das allererste Discovery start hat tatsächlich zwei Geräte gefunden:

2014.04.09 18:07:25 3: HM485_LAN: Discovery - found device: 00009A2B
2014.04.09 18:07:26 3: HM485_LAN: Discovery - found device: 0000B8C5


aber nichts angelegt, alle weiteren discoveries waren dann erfolglos. Habe noch keinen Taster angeschlossen, aber mir scheint, dass das 12/7 auch noch nicht integriert ist?

Viele Grüße
Stephan

Hallo Stephan,

und hast du auch noch ein Stückchen aus dem log für mich?

Gruß gevoo

ja, auch das :-)


2014.04.09 18:05:01 3: HM485_LAN: Alive: (132) 3030
2014.04.09 18:05:09 3: HM485_LAN: Event: I[0](3,Y,F,B)(F8) 00009A2B -> FFFFFFFF [4] 69(i) 0E
2014.04.09 18:05:09 2: HM485: HMW_IO_12_Sw14_DR_JEQ0459634_15: frequency -> 1023
2014.04.09 18:05:09 3: HM485_LAN: Event: I[1](3,Y,F,B)(FA) 00009A2B -> FFFFFFFF [4] 69(i) 13
2014.04.09 18:05:11 3: HM485_LAN: TX: (133) I[3](0,F,B)(1E) 00000001 -> 00009A2B [4] 53(S) 02
2014.04.09 18:05:11 3: HM485_LAN: ACK: (133)
2014.04.09 18:05:11 3: HM485_LAN: Response: (133) 69020000
2014.04.09 18:05:11 3: HM485_ProcessResponse: ioHash = HASH(0x21259a8) hmwId = 00009A2B msgData = 69020000 requestType = 53
2014.04.09 18:05:11 3: HM485_LAN: TX: (134) I[0](0,F,B)(18) 00000001 -> 00009A2B [4] 53(S) 02
2014.04.09 18:05:11 3: HM485_LAN: ACK: (134)
2014.04.09 18:05:11 3: HM485_LAN: Response: (134) 69020000
2014.04.09 18:05:11 3: HM485_ProcessResponse: ioHash = HASH(0x21259a8) hmwId = 0
0009A2B msgData = 69020000 requestType = 53
2014.04.09 18:05:31 3: HM485_LAN: Alive: (135) 3030
2014.04.09 18:05:51 3: HM485_LAN: Alive: (136) 3030
2014.04.09 18:05:54 3: HM485_LAN: Event: I[0](3,Y,F,B)(F8) 00009A2B -> FFFFFFFF [4] 69(i) 0E
2014.04.09 18:05:54 3: HM485_LAN: Event: I[1](3,Y,F,B)(FA) 00009A2B -> FFFFFFFF [4] 69(i) 13
2014.04.09 18:05:56 3: HM485_LAN: TX: (137) I[1](0,F,B)(1A) 00000001 -> 00009A2B [4] 53(S) 02
2014.04.09 18:05:56 3: HM485_LAN: ACK: (137)
2014.04.09 18:05:56 3: HM485_LAN: Response: (137) 69020000
2014.04.09 18:05:56 3: HM485_ProcessResponse: ioHash = HASH(0x21259a8) hmwId = 00009A2B msgData = 69020000 requestType = 53
2014.04.09 18:05:56 3: HM485_LAN: TX: (138) I[2](0,F,B)(1C) 00000001 -> 00009A2B [4] 53(S) 02
2014.04.09 18:05:56 3: HM485_LAN: ACK: (138)
2014.04.09 18:05:56 3: HM485_LAN: Response: (138) 69020000
2014.04.09 18:05:56 3: HM485_ProcessResponse: ioHash = HASH(0x21259a8) hmwId = 00009A2B msgData = 69020000 requestType = 53
2014.04.09 18:06:16 3: HM485_LAN: Alive: (139) 3030
2014.04.09 18:06:36 3: HM485_LAN: Alive: (140) 3030
2014.04.09 18:06:54 3: HM485_LAN: TX: (141) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2014.04.09 18:06:54 3: HM485_LAN: TX: (142) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2014.04.09 18:06:54 3: HM485_LAN: Alive: (142) 3032
2014.04.09 18:06:54 3: HM485_LAN: Alive: (141) 3031
2014.04.09 18:07:04 2: HM485_LAN: Discovery - canceled. No results found within 10 seconds!
2014.04.09 18:07:04 3: HM485_LAN: TX: (144) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 5A(Z)
2014.04.09 18:07:04 3: HM485_LAN: TX: (145) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 5A(Z)
2014.04.09 18:07:04 3: HM485_LAN: Alive: (145) 3032
2014.04.09 18:07:04 3: HM485_LAN: Alive: (144) 3031
2014.04.09 18:07:24 3: HM485_LAN: TX: (146) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2014.04.09 18:07:24 3: HM485_LAN: TX: (147) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2014.04.09 18:07:24 3: HM485_LAN: Alive: (147) 3032
2014.04.09 18:07:24 3: HM485_LAN: Alive: (146) 3031
2014.04.09 18:07:25 3: HM485_LAN: Discovery - found device: 00009A2B
2014.04.09 18:07:26 3: HM485_LAN: Discovery - found device: 0000B8C5
2014.04.09 18:07:27 3: HM485_LAN: TX: (149) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 5A(Z)
2014.04.09 18:07:27 3: HM485_LAN: TX: (150) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 5A(Z)
2014.04.09 18:07:27 3: HM485_LAN: Alive: (150) 3032
2014.04.09 18:07:27 3: HM485_LAN: TX: (151) I[0](0,Y,F,B)(98) 00000001 -> 0000B8C5 [3] 68(h)
2014.04.09 18:07:27 3: HM485_LAN: Alive: (151) 3032
2014.04.09 18:07:27 3: HM485_LAN: NACK: (151) 0000B8C5
2014.04.09 18:07:27 3: HM485_LAN: Alive: (149) 3031
2014.04.09 18:07:47 3: HM485_LAN: Alive: (152) 3030
2014.04.09 18:07:49 3: HM485_LAN: TX: (153) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2014.04.09 18:07:49 3: HM485_LAN: TX: (154) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2014.04.09 18:07:49 3: HM485_LAN: Alive: (154) 3032
2014.04.09 18:07:50 3: HM485_LAN: Alive: (153) 3031
2014.04.09 18:07:59 2: HM485_LAN: Discovery - canceled. No results found within 10 seconds!


lg
stephan

okay, da ich das Ding ja übers LAN bekomme, hab ich einen eigenen Test-fhem aufgesetzt. Gerade noch das Log-Level auf 5 erhöht.
-> ich versuchs nochmal :-)

so, gerade fhem auf der Kommandozeile gestartet:


Useless use of private variable in void context at ./FHEM/10_HM485.pm line 1172, <$fh> line 51.
Useless use of private variable in void context at ./FHEM/10_HM485.pm line 1172, <$fh> line 51.
Prototype mismatch: sub main::HM485_SendCommandState ($$$) vs ($) at ./FHEM/10_HM485.pm line 1246, <$fh> line 51.

root@new:/opt/fhem#
root@new:/opt/fhem# Argument "off" isn't numeric in int at ./FHEM/10_HM485.pm line 1365.
Argument "off" isn't numeric in int at ./FHEM/10_HM485.pm line 1365.
Argument "off" isn't numeric in int at ./FHEM/10_HM485.pm line 1365.
Argument "off" isn't numeric in int at ./FHEM/10_HM485.pm line 1365.
Argument "off" isn't numeric in int at ./FHEM/10_HM485.pm line 1365.
Argument "off" isn't numeric in int at ./FHEM/10_HM485.pm line 1365.
Use of uninitialized value $hmwId in numeric gt (>) at FHEM/lib/HM485/Util.pm line 264.
Use of uninitialized value $chType in concatenation (.) or string at FHEM/lib/HM485/Device.pm line 690.
Use of uninitialized value $hmwId in numeric gt (>) at FHEM/lib/HM485/Util.pm line 264.
Use of uninitialized value $chType in concatenation (.) or string at FHEM/lib/HM485/Device.pm line 690.
Use of uninitialized value $hmwId in numeric gt (>) at FHEM/lib/HM485/Util.pm line 264.
Use of uninitialized value $chType in concatenation (.) or string at FHEM/lib/HM485/Device.pm line 690.
Use of uninitialized value $hmwId in numeric gt (>) at FHEM/lib/HM485/Util.pm line 264.
Use of uninitialized value $chType in concatenation (.) or string at FHEM/lib/HM485/Device.pm line 690.
Use of uninitialized value $hmwId in numeric gt (>) at FHEM/lib/HM485/Util.pm line 264.
Use of uninitialized value $chType in concatenation (.) or string at FHEM/lib/HM485/Device.pm line 690.
Use of uninitialized value $hmwId in numeric gt (>) at FHEM/lib/HM485/Util.pm line 264.
Use of uninitialized value $chType in concatenation (.) or string at FHEM/lib/HM485/Device.pm line 690.


So, fangen wir mal vorne an.
im meinem (neuen) Log steht:


2014.04.09 22:56:38 5: SW: <FD>^MCS<C8><FF><FF><FF><FF><98>^@^@^@^AZ
2014.04.09 22:56:38 3: HM485_LAN: TX: (67) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 5A(Z)
2014.04.09 22:56:38 5: SW: <FD>^MDS<C8><FF><FF><FF><FF><98>^@^@^@^AZ
2014.04.09 22:56:38 3: HM485_LAN: TX: (68) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 5A(Z)


Ist es machbar, dass diese @^ und ^MDS als normale Zeichen gezeigt werden?
Wenn ja, wie?

Das Discovery bringt folgende Meldungen im Log:

2014.04.09 22:59:29 4: Connection closed for FHEMWEB:127.0.0.1:36951
2014.04.09 22:59:29 4: HTTP FHEMWEB:127.0.0.1:36964 GET /fhem&detail=HM485_LAN&detail=HM485_LAN&dev.setHM485_LAN=HM485_LAN&cmd.setHM485_LAN=set&arg.setHM485_LAN=discovery&val.setHM485_LAN=start
2014.04.09 22:59:29 5: Cmd: >set HM485_LAN discovery start<
MS������
z 22:59:29 5: SW:
2014.04.09 22:59:29 3: HM485_LAN: TX: (77) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2014.04.09 22:59:29 5: Triggering HM485_LAN (1 changes)
2014.04.09 22:59:29 5: Notify loop for HM485_LAN discovery start
2014.04.09 22:59:29 4: eventTypes: HM485_LAN HM485_LAN discovery start -> discovery start
2014.04.09 22:59:29 4: HTTP FHEMWEB:127.0.0.1:36964 GET /fhem?detail=HM485_LAN
Use of uninitialized value $fn in concatenation (.) or string at ./FHEM/01_FHEMWEB.pm line 1082.
2014.04.09 22:59:29 4: /fhem?detail=HM485_LAN / RL:2164 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
NS������
z 22:59:29 5: SW:
2014.04.09 22:59:29 3: HM485_LAN: TX: (78) I[0](0,Y,F,B)(98) 00000001 -> FFFFFFFF [3] 7A(z)
2014.04.09 22:59:29 3: HM485_LAN: Alive: (78) 3032
2014.04.09 22:59:29 4: HTTP FHEMWEB:127.0.0.1:36964 GET /fhem/pgm2/svg.js
2014.04.09 22:59:29 4: Connection accepted from FHEMWEB:127.0.0.1:36965
2014.04.09 22:59:29 4: HTTP FHEMWEB:127.0.0.1:36965 GET /fhem/pgm2/fhemweb_noArg.js
2014.04.09 22:59:29 4: HTTP FHEMWEB:127.0.0.1:36964 GET /fhem/pgm2/fhemweb_time.js
2014.04.09 22:59:29 4: Connection accepted from FHEMWEB:127.0.0.1:36966
2014.04.09 22:59:29 5: SW: �OD�
2014.04.09 22:59:29 4: HTTP FHEMWEB:127.0.0.1:36965 GET /fhem?cmd={ReadingsVal(%22HM485_LAN%22,%22RAW%22,%22%22)}&XHR=1
2014.04.09 22:59:29 5: Cmd: >{ReadingsVal("HM485_LAN","RAW","")}<
2014.04.09 22:59:29 4: /fhem?cmd={ReadingsVal(%22HM485_LAN%22,%22RAW%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2014.04.09 22:59:29 4: HTTP FHEMWEB:127.0.0.1:36966 GET /fhem?cmd={AttrVal(%22HM485_LAN%22,%22room%22,%22%22)}&XHR=1
2014.04.09 22:59:29 5: Cmd: >{AttrVal("HM485_LAN","room","")}<
2014.04.09 22:59:29 4: /fhem?cmd={AttrVal(%22HM485_LAN%22,%22room%22,%22%22)}&XHR=1 / RL:26 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2014.04.09 22:59:29 4: HTTP FHEMWEB:127.0.0.1:36964 GET /fhem/images/default/icoEverything.png
2014.04.09 22:59:29 4: HTTP FHEMWEB:127.0.0.1:36964 GET /fhem/images/default/fhemicon.png
2014.04.09 22:59:29 4: HTTP FHEMWEB:127.0.0.1:36964 GET /fhem?XHR=1&inform=type=status;filter=HM485_LAN&timestamp=1397077169716
2014.04.09 22:59:29 3: HM485_LAN: Alive: (77) 3031
2014.04.09 22:59:39 2: HM485_LAN: Discovery - canceled. No results found within 10 seconds!



Beim Drücken des Tasters am I20 platzt meine Konsole vor Meldungen:

2014.04.09 23:00:22 3: HM485_LAN: Event: I[2](2,Y,F,B)(DC) 00009A2B -> FFFFFFFF [4] 69(i) 13
2014.04.09 23:00:22 5: HM485_LAN dispatch e������+i
2014.04.09 23:00:22 5: Loading ./FHEM/10_HM485.pm
Useless use of private variable in void context at ./FHEM/10_HM485.pm line 1172.
Useless use of private variable in void context at ./FHEM/10_HM485.pm line 1172.
Prototype mismatch: sub main::HM485_SendCommandState ($$$) vs ($) at ./FHEM/10_HM485.pm line 1246.
2014.04.09 23:00:22 4: HM485: type
TS��+�
h09 23:00:22 5: SW:
2014.04.09 23:00:22 3: HM485_LAN: TX: (84) I[0](0,Y,F,B)(98) 00000001 -> 00009A2B [3] 68(h)
2014.04.09 23:00:22 3: HM485_LAN: ACK: (84)
2014.04.09 23:00:22 3: HM485_LAN: Response: (84) 1C00
2014.04.09 23:00:22 5: HM485_LAN dispatch �Tr
2014.04.09 23:00:22 4: HM485: Device 00009A2B not defined yet. We need the serial number for autocreate
US��+
n09 23:00:22 5: SW:
2014.04.09 23:00:22 3: HM485_LAN: TX: (85) I[1](0,F,B)(1A) 00000001 -> 00009A2B [3] 6E(n)
2014.04.09 23:00:22 3: HM485_LAN: ACK: (85)
2014.04.09 23:00:22 3: HM485_LAN: Response: (85) 4A455130343539363334
Ur8JEQ0459634:00:22 5: HM485_LAN dispatch
2014.04.09 23:00:22 5: Triggering global (1 changes)
2014.04.09 23:00:22 5: Notify loop for global UNDEFINED HMW_IO_12_Sw14_DR_JEQ0459634 HM485 00009A2B
2014.04.09 23:00:22 2: autocreate: define HMW_IO_12_Sw14_DR_JEQ0459634 HM485 00009A2B
2014.04.09 23:00:22 2: HM485: Assigned HMW_IO_12_Sw14_DR_JEQ0459634 (00009A2B) to HM485_LAN
2014.04.09 23:00:22 2: HM485: Auto get info for : HMW_IO_12_Sw14_DR_JEQ0459634
2014.04.09 23:00:22 5: Triggering global (2 changes)
2014.04.09 23:00:22 5: Triggering global (3 changes)
VS��+
h09 23:00:22 5: SW:
2014.04.09 23:00:22 3: HM485_LAN: TX: (86) I[2](0,F,B)(1C) 00000001 -> 00009A2B [3] 68(h)
2014.04.09 23:00:22 3: HM485_LAN: ACK: (86)
2014.04.09 23:00:22 3: HM485_LAN: Response: (86) 1C00
2014.04.09 23:00:22 5: HM485_LAN dispatch �VrZ
WS��+
n09 23:00:22 5: SW:
2014.04.09 23:00:22 3: HM485_LAN: TX: (87) I[3](0,F,B)(1E) 00000001 -> 00009A2B [3] 6E(n)
2014.04.09 23:00:22 3: HM485_LAN: ACK: (87)
2014.04.09 23:00:22 3: HM485_LAN: Response: (87) 4A455130343539363334
Wr|JEQ0459634:00:22 5: HM485_LAN dispatch
XS��+
v09 23:00:22 5: SW:
2014.04.09 23:00:22 3: HM485_LAN: TX: (88) I[0](0,F,B)(18) 00000001 -> 00009A2B [3] 76(v)
2014.04.09 23:00:22 3: HM485_LAN: Alive: (88) 3032
2014.04.09 23:00:22 5: HM485_LAN dispatch �Xa
�+
2014.04.09 23:00:22 3: HM485: RESPONSE TIMEOUT for 00009A2B
2014.04.09 23:00:22 3: HM485_LAN: Event: I[3](3,Y,F,B)(FE) 00009A2B -> FFFFFFFF [4] 69(i) 13
2014.04.09 23:00:22 5: HM485_LAN dispatch e������+i�
Use of uninitialized value $hmwId in numeric gt (>) at FHEM/lib/HM485/Util.pm line 264.
2014.04.09 23:00:22 2: HM485: HMW_IO_12_Sw14_DR_JEQ0459634: frequency -> 1023
2014.04.09 23:00:22 5: Triggering HMW_IO_12_Sw14_DR_JEQ0459634 (4 changes)
2014.04.09 23:00:22 5: Notify loop for HMW_IO_12_Sw14_DR_JEQ0459634 ACK
2014.04.09 23:00:22 4: eventTypes: HM485 HMW_IO_12_Sw14_DR_JEQ0459634 ACK -> ACK
2014.04.09 23:00:22 4: eventTypes: HM485 HMW_IO_12_Sw14_DR_JEQ0459634 ACK -> ACK
2014.04.09 23:00:22 4: eventTypes: HM485 HMW_IO_12_Sw14_DR_JEQ0459634 RESPONSE TIMEOUT -> RESPONSE TIMEOUT
2014.04.09 23:00:22 4: eventTypes: HM485 HMW_IO_12_Sw14_DR_JEQ0459634 frequency: 1023 -> frequency: .*
2014.04.09 23:00:24 5: SW: YS��+
S
2014.04.09 23:00:24 3: HM485_LAN: TX: (89) I[1](0,F,B)(1A) 00000001 -> 00009A2B [4] 53(S) 02
2014.04.09 23:00:24 3: HM485_LAN: ACK: (89)
2014.04.09 23:00:24 3: HM485_LAN: Response: (89) 69020000
2014.04.09 23:00:24 5: HM485_LAN dispatch �Yr8i
2014.04.09 23:00:24 3: HM485_ProcessResponse: ioHash = HASH(0x1355528) hmwId = 00009A2B msgData = 69020000 requestType = 53
Use of uninitialized value $hmwId in numeric gt (>) at FHEM/lib/HM485/Util.pm line 264.
2014.04.09 23:00:24 2: HM485: HMW_IO_12_Sw14_DR_JEQ0459634: state -> off
Argument "off" isn't numeric in int at ./FHEM/10_HM485.pm line 1365.
2014.04.09 23:00:24 5: Triggering HMW_IO_12_Sw14_DR_JEQ0459634 (2 changes)
2014.04.09 23:00:24 5: Notify loop for HMW_IO_12_Sw14_DR_JEQ0459634 ACK
2014.04.09 23:00:24 4: eventTypes: HM485 HMW_IO_12_Sw14_DR_JEQ0459634 ACK -> ACK
2014.04.09 23:00:24 4: eventTypes: HM485 HMW_IO_12_Sw14_DR_JEQ0459634 off -> off

nach dem Drücken des Tasters wird der HMW_IO_12_Sw14_DR_JEQ0459634 in der Übersicht angezeigt (Bild1). Dort ist eine Birne sichtbar, die meiner Meinung nach fehl am Platze ist.


Nach einem "get HMW_IO_12_Sw14_DR_JEQ0459634 info" habe ich alle 26 Kanäle, und in der Übersicht werden alle INs und OUTs angezeigt, jedoch alle mit Fragezeichen (Bild 2) Hierzu eine Anmerkung: Bei verwendung eines 12/14er Bausteins mag diese Darstellung noch hilfreich sein. Ich denke jedoch, dass wenn ich nachher 15 Rolladenaktoren, 4x 12/14er und 4x 12/7er sowie diverse andere Geräte im Einsatz habe, diese Darstellung sehr unübersichtlich wird. Ich würde daher eine weitere Unterteilung nach Devices bevorzugen : Übersicht aller Devices, klick drauf: Übersicht aller INs/OUTs.


Nach einem shutdown restart ist die Übersicht wieder weg.
In der fhem.cfg finden sich die Zeilen

define HMW_IO_12_Sw14_DR_JEQ0459634 HM485 00009A2B
attr HMW_IO_12_Sw14_DR_JEQ0459634 room HM485


soweit erstmal
lg
stephan

Hallo Stephan,

das Discovery scheint es dir ja angetan zu haben. O.k. ich habe in der Define procedure Änderungen vorgenommen, die dich dabei unterstützen sollten.
Ausserdem hänge ich auch noch die bereinigte Device.pm mit an, die du unter /FHEM/lib/HM485/
findest. Ein Discovery ist nur von Erfolg gekrönt wenn das Device noch nicht in der fhem.cfg existiert. Ich vermute mal, daß es auch nicht in der fhem.save stehen darf, da die Daten bei jedem Start wieder geladen werden.

Die Orakel aus deinem esten Codeblock kann ich im Moment nicht verhindern. Die kommen aus der 00_HM485_LAN.pm in die ich mich noch nicht richtig eingearbeitet habe. Das Gateway funktioniert ja offenbar, sodas dafür im Moment noch keine Notwendigkeit besteht.

Ein get <Device> info liest nur die Eprom- daten und initialisiert die Channels. Wenn du auch noch den State der Channels haben willst, mußt du noch ein get <Device> config all hinterherschicken.

Die einzelnen Channels lassen sich auch in unterschiedlichen Räumen anzeigen. Dazu später mehr, wenn alles andere funktioniert.

Der 12-Sw7 funktioniert momentan auch nur mit RAW- Befehlen.

Gruß gevoo

Hi,
habe noch nicht so richtig Zeit gehabt, weiter was zu testen. Konntest du die ON/OFF-Switches für die OD-Ausgänge schon hinzufügen?

Ausserdem eine kleine Frage, wahrscheinlich stehe ich irgendwo massiv auf dem Schlauch:

Ich würde gerne alles, was HMW betrifft, in eine Extra Datei loggen:

define HMW Filelog ./log/hmw.log 10_HM485*

leider kommen in meinem Log nur sehr wenige Meldungen an, allerdings versammeln die sich alle im fhem.log.

Was mache ich verkehrt??
lg
stephan

Hallo Stephan,

du machst nicht verkehrt. Im log für das Device kommen nur die Meldungen an, die das Device betreffen, wie z.B. Channel on/ off usw. Alles andere wird im zentralen log festgehalten.

lg gevoo

Hallo zusammen,

ich hatte ja vor einiger Zeit mal geschrieben das ich für meine Lichtsteuerung HM-Wired einsetzten will und wollte mal berichten

Jetzt läuft das ganze System.  8)
Geschalten werden derzeit Küche 4 Lichtkreise; Bad 3 Lichtkreise, Flur 2 Lichtkreise. Muss sagen es läuft alles wunderbar.
Ich muss hier noch mal ein Lob austeilen für alle die an diesem Projekt mitarbeiten.  :)

Grüße
Markus

Hallo Leute,

ich habe jetzt meine erste Wired Komponente ein wenig beobachtet und mit ihr rumgespielt.

Ich bin ein wenig verwirrt, was jetzt der aktuellste Code für das Modul ist. Es gibt das Zipfile aus dem github [1]
und dann gibt es noch zwei neuerer Dateien hier im Thread.

Auf jeden Fall habe ich ein Problem mit den analogen Ausgängen. Diese können ja umgestellt werden auf digital.
Wenn ich das mache, klappt es aber nur teilweise. Wenn ich zwei umgestellt habe, und den dritten bearbeite, wird der vorherige wieder analog. Liegt das an der Oberfläche? Sollte ich das via raw Kommandos versuchen? Das Fehlerbild ist ziemlich verschieden.
Wenn ich unter configuration digital auswähle, dann auf safe config klicke, steht dort direkt wieder analog. Wenn ich das dann nochmal mache, bleibt digital drin. Und dann folgt eben der andere Fehler....

Ich lese allerdings auch, dass hier Leute ihre HMW Komponenten schon mehr oder weniger produktiv einsetzen. Mit FHEM?. Gibt
es dann noch mehr Leseinput?   Im Wiki und im Forum habe ich auch schon ordentlich gestöbert.

Viele Grüße
Stephan








[1] https://github.com/kc-GitHub/FHEM-HM485/archive/master.zip

Hallo Stephan, genau das Problem hatte ich auch. Derzeit wird die Konfiguration der I/O Ports noch nicht unterstützt. Wenn du alle Eingänge auf digital umstellen möchtest geht das aktuell nur über die CCU Zentrale. Da ich keine CCU habe und ich mir auch nicht extra eine anschaffen wollte um das I/O Modul zu konfigurieren, habe ich mir die CCU2 FW auf ein PI gepackt und so die I/O Port eingestellt.

siehe folgender Beitrag:

http://forum.fhem.de/index.php/topic,10607.msg157418.html#msg157418 (http://forum.fhem.de/index.php/topic,10607.msg157418.html#msg157418)

wie du dir eine CCU baust steht hier

http://homematic-forum.de/forum/viewtopic.php?f=26&t=16998 (http://homematic-forum.de/forum/viewtopic.php?f=26&t=16998)


Gruß
cerberus

Klasse!
Danke fürs Aufschlauen!

Ich habe mir gerade die Anleitung durchgelesen. Ich habe leider keinen HM-LAN bzw. HM-LAN RS485 Adapter.
Die CCU wird sich wohl nicht von einem remote laufenden HM485d und RS485 Wandler steuern lassen.

Da muss ich wohl warten oder HW kaufen. Oder ich probiere das einfach erstmal mit der CCU auf meinem Ersatz RPI.
Am WE werd ich mal die Anleitung durchgehen...

Viele Grüße
Stephan

Zitat von: stephan-221 am 15 Mai 2014, 21:15:24
Die CCU wird sich wohl nicht von einem remote laufenden HM485d und RS485 Wandler steuern lassen.

Doch wird sie. Der HM485d verhält sich wie ein HMW-LAN. Du kannst den auch auf dem gleichen Raspberry Pi laufen lassen.
Du musst den HM485d allerdings als root laufen lassen und Localport 1000 benutzen
Als Schlüssel in der CCU gibst du 0 ein. Dann sollte es funktionieren.

Gruß
Dirk

Hallo Dirk,

danke für den Hinweis. Ich habe meine CCU quasi am laufen.
Die SD-Card ist etwas zu klein, daher keine extra Partition etc.
Es werden ein paar Fehlermeldungen ausgespuckt, aber an sich läuft die RCU.

Leider klappt absolut kein "Geräte anlernen".
Ich habe dann zurückgeschwenkt auf den FHEM mit hm485d und auch über Kreuz beide Raspberries (RCU und FHEM) mit hm485d konfiguriert.

Problem liegt wohl an meinem HMW Element. Es lässt nicht nicht discovern. Beim Booten werden die Stati als Broadcast übermittelt.
Schalten über FHEM geht auch an den 6 dig. Ausgängen. Vielleicht habe ich doch wohl ein Montagsgerät erwischt.

a) Kann man in der rcu irgenwo manuell das Gerät hinzufügen?
     Ich will ja nur die Ports einmalig konfigurieren.
     Normale Kommunikation geht ja mit FHEM.

b) Die HMW Geräte kann man nicht irgendwie resetten?
     Alternativ die FW neu Flashen via ISP?

c)  Sind die Konfig Kommandos schon als  RAW Values bekannt?
     Dann könnte ich diese ja auch per FHEM übertragen.

edit:
Irgendwann nach etlichen Versuchen hat Discovery ja mal am FHEM geklappt, sonst wäre das Device dort nicht drin :-S


Viele Grüße
Stephan

Nach intensiver google und Forensuche bin ich auch die HMW485 Protokolldoku gestoßen und
konnte Punkt c) also lösen.  Daher sind die anderen Fragen quasi überflüssig.

Raw Kommandos für die Konfiguration der Ausgänge:

http://forum.fhem.de/index.php/topic,23884.0.html

Viele Grüße
Stephan

Hallo zusammen,

ich habe eine Frage zu den Log Einträgen.
Es kommt alle 10 Sec zu den beiden Einträgen

2014.06.01 01:16:54 3: HM485_LAN: keepalive msgNo: 8
2014.06.01 01:16:54 3: HM485_LAN: Alive: (8) 3030

Das Problem ist desto älter das Monat wird desto größer wird das Logfile und dauert dann auch ewig bis es geöffnet ist.

Kann man die beiden Meldungen abstellen oder in eine anderes Logfile umleiten?

Gruß
Markus

Hallo mango211,

probiers doch einfach mal mit
attr HM485_LAN verbose 2

Gruß gevoo

Hallo gevoo,

nein leider hat das umstellen der verbose mode nichts gebracht.

Gruß
Markus

Hallo mango0211,

dann hilft nur noch die brutale Methode:
- Öffne in einem Texteditor das Modul /FHEM/00_HM485_LAN.pm
- Scrolle bis zur Procedure sub HM485_LAN_Write($$;$)
- ändere dort den Quelltext durch einfügen eines Kommentarzeichens (#) in ca. Zeile 355 von

} elsif ($cmd == HM485::CMD_KEEPALIVE) {
  $sendData = pack('H*',sprintf('%02X%02X', $msgId, $cmd));
                 HM485::Util::logger($name, 3, 'keepalive msgNo: ' . $msgId);

in

} elsif ($cmd == HM485::CMD_KEEPALIVE) {
$sendData = pack('H*',sprintf('%02X%02X', $msgId, $cmd));
# HM485::Util::logger($name, 3, 'keepalive msgNo: ' . $msgId);

-damit ist Zeile eins verschwunden.

- gehe zur Procedure sub HM485_LAN_parseIncommingCommand($$)
- ändere dort den Quelltext durch Einfügen eines Kommentarzeichens in ca. Zeile 787 von
} elsif ($msgCmd == HM485::CMD_ALIVE) {
my $aliveStatus = substr($msgData, 0, 2);
HM485::Util::logger($name, 3, 'Alive: (' . $msgId . ') ' . uc(unpack ('H*', $msgData)));
if ($aliveStatus == '00') {

in
} elsif ($msgCmd == HM485::CMD_ALIVE) {
my $aliveStatus = substr($msgData, 0, 2);
# HM485::Util::logger($name, 3, 'Alive: (' . $msgId . ') ' . uc(unpack ('H*', $msgData)));
if ($aliveStatus == '00') {

-damit ist auch Zeile zwei verschwunden.

speichere die Datei ab und starte FHEM neu.

Grüße gevoo

Hallo,

Danke für deine Antwort

scheint wohl echt die einzige Möglichkeit zu sein.
Ich werde es bei Gelegenheit testen und dann berichten.

Gruß
Markus

Hallo gevoo,

mir ist gerade eingefallen  ::)...

Könnte man die beiden Messages auch in eine andere Logdatei umleiten? Also das ich mit eine Extra Logdatei anlege für diese 2 Meldungen?

Gruß
Markus

Hallo mango0211,

dann müßtest Du die log- Procedure im Modul Util.pm durch Deine eigene ersetzen/ bzw. Deine eigene log- Procedure an der Stelle
HM485::Util::logger($name, 3, 'keepalive msgNo: ' . $msgId);
aufrufen. Die könnte dann in eine von Dir definierte Log- Datei schreiben.
Könntest Du in 99_MyUtils.pm hinterlegen. Dann ist sie immer verfügbar.

Gruß gevoo

Hallo gevoo,

sorry für die etwas verspätete Antwort.

Deine Idee mit dem Logfile hat super geklappt hab zwar etwas gebraucht aber jetzt läuft das  ;D

Danke und Gruß
Markus

Zitat von: gevoo am 23 März 2014, 08:37:17
Hallo,

habe das Modul von Dirk wieder etwas erweitert. Alles getestet für Rolloaktoren HMW_LC_Bl1_DR.
Es funktionieren jetzt beim Neustart von FHEM das automatische Initialisieren der Channels und auch die Ermittlung des aktuellen State.
Der Vorgang ist etwa nach 10s abgeschlossen.
Damit kann ich dann auch die StateIcons für das entsprechende Rollo in der *.cfg setzen:

Code Auswählen Erweitern

# StateIcon der Channels setzen
define SetLevel at +00:01:00 {\
fhem( "attr WZRolloWest_03 devStateIcon level_[0-9]:shutter_closed level_1[0-9]:shutter_closed level_2[0-9]:shutter_7 level_3[0-9]:shutter_7 level_4[0-9]:shutter_6 level_5[0-9]:shutter_5 level_6[0-9]:shutter_4 level_7[0-9]:shutter_3 level_8[0-9]:shutter_2 level_9[0-9]:shutter_1 level_100:shutter_open");;\
}
Die Initialisierungssequenzen aus meinem vorigen Beitrag können mit dem neuen Modul in der fhem.cfg entfallen.
Die Datei 10_HM485.pm habe ich wieder angehängt.
Viel Spaß beim Testen.

Hallo gevoo,

ist das noch aktuell und kann so verwendet und definiert werden?
Muss ich dann die Definition für jede Device erstellen?

Hallo Holzwurm63,

das ist noch aktuell. Die definition mußt du für jedes Device machen, für das du ein Icon verwenden willst.
Im Anhang nochmal die derzeit aktuellste Version für die alte Configversion.

Gruß gevoo

Hallo gevoo,

Danke für dein Feedback. Da ich Jalousien habe und keine Rollos wäre es für mich interessant zu wissen ob eine Implementierung einer Lamellenschrägstellung geplant oder möglich ist.

Hallo Holzwurm83,

mit welchem Modul willst Du denn die Jalousien ansteuern?

Gruß gevoo

Ich habe meine Jalousien am HMW_LC_BL_DR angeschlossen.

O.k. Wenn due die Öffnungs- und Schließzeiten entsprechend einstellst, sollte das doch gehen?
Oder reden wir gerade aneinander vorbei?

Gruß gevoo

Ja, dann weiß man auf welcher Höhe die Lamellen stehen.

Ich möchte allerdings auch den Winkel der Lamellen einstellen und kontrollieren. Wenn die Lamellen ganz zu sind haben sie null Grad und wenn ich sie dann um 0,5 nach oben fahren lasse stehen sie bei 25° und bei 2 stehen sie bei max160°.

Man müsste dann denke ich abfragen wie lange in welche Richtung die Lamellen zuletzt gefahren sind um die Lamellenstellung festzuhalten und dann von dieser pos. neue Befehle absetzen zu können.

Hoffe du kannst mir folgen?

Also für mein Verständnis funktioniert das also so:
Jalousie fährt runter, wenn die erste Lamelle unten angekommen ist, beginnen sich die Lamellen zu schließen bis sie ganz geschlossen sind?
Hochwärts in umgekehrter Reihenfolge.

Wenn das so ist hast du also eine Zeit für das Herunterfahren z.B. 15 s und dann hinten drann noch eine für das Schließen also z.B. 5 s oder?

Gruß gevoo

Hallo,

ich möchte mich in die Diskussion über eine Lamellensteuerung einklinken, da ich dasselbe auch vorhabe.

Bei mir ist es so: die Jalousie fährt vollständig geschlossen runter und wenn sie wieder hochfährt, wird sie vorher wieder vollständig geöffnet.

Spontan fallen mir 2 Möglichkeiten ein, wie man den aktuellen Stand der Lamelle auszulesen kann:
1. Man weiß, wieviel die Lamelle zuletzt in welche Richtung gefahren ist UND man weiß, welche Lamellenstellung zuvor eingestellt war.

2. Man fährt vor einer Neueinstellung der Lamelle diesselbe in eine definierte Stellung (z.B. ganz geschlossen) und stellt danach die gewünscht Stellung ein.

Gruß Scotty

Zitat von: gevoo am 13 September 2014, 20:39:38
Also für mein Verständnis funktioniert das also so:
Jalousie fährt runter, wenn die erste Lamelle unten angekommen ist, beginnen sich die Lamellen zu schließen bis sie ganz geschlossen sind?
Hochwärts in umgekehrter Reihenfolge.

Wenn das so ist hast du also eine Zeit für das Herunterfahren z.B. 15 s und dann hinten drann noch eine für das Schließen also z.B. 5 s oder?

Gruß gevoo

Hallo gevoo,

tut mir leid, dass ich mich erst jetzt zurück melde. Mich hatte es total zerlegt!

So wie du es beschrieben hast ist die Reihenfolge genau anders herum. Sobald du die Lamellen nach unten fahren lässt werden diese erst nach unten gedreht z.B. 5 s und dann fahren diese z.B. 15 s weiter nach unten. Bei hochfahren drehen sich zuerst wieder 5s die Lamellen und fahren dann wieder 15s nach oben.

Hallo holzwurm83,

wenn Du möchtest, dann können wir diese Sache hier auch einmal weiter voranbringen.
Deiner Antwort entnehme ich:
- Wenn man z.B. die Jalousie zur Beschattung haben möchte und die Lamellen meinetwegen auf 20 Grad stellen möchte, dann geht das nur auf dem Weg von unten nach oben.
- Daraus ergibt sich, daß die Beschattung auf dem Weg von oben nach unten nur mit geschlossenen Lamellen möglich ist. Wenn ich die Jalousie auf LEVEL 40 nach unten fahren lasse sind die Lamellen genauso geschlossen als wenn ich sie auf LEVEL 60 fahren lassen würde.
- Weiterhin heisst das, ich kann den Lamellenwinkel nur in der Aufwärtsbewegung beinflussen? Oder schließen sich die Dinger wieder, wenn ich sie nur 45 grad geöffnet habe und dann die Jalousie abwärts fahren lasse?

Gruß gevoo

Zitat von: gevoo am 08 Februar 2015, 11:42:45
Hallo holzwurm83,

wenn Du möchtest, dann können wir diese Sache hier auch einmal weiter voranbringen.

Gruß gevoo

;D Na klar, gerne!

Zitat- Wenn man z.B. die Jalousie zur Beschattung haben möchte und die Lamellen meinetwegen auf 20 Grad stellen möchte, dann geht das nur auf dem Weg von unten nach oben.

Ja, genau. Theoretisch würde das auch von oben nach unten gehen, aber nicht alle Lamellen haben den gleiche Öffnungswinkel. Ich habe z.B. zwei verschiedene Ausführung. Die eine die im Winkel 0-180 Grad drehen kann und die andere die nur 0-90 (90 Grad=Wagerecht) Grad drehen kann.
Ich denke das wir die finale Gradzahl nur über einen Referenzpunkt (0,90 oder 180) anfahren werden können, da die 230V Motoren keine so genau Feinmotorik haben!?

Zitat- Daraus ergibt sich, daß die Beschattung auf dem Weg von oben nach unten nur mit geschlossenen Lamellen möglich ist. Wenn ich die Jalousie auf LEVEL 40 nach unten fahren lasse sind die Lamellen genauso geschlossen als wenn ich sie auf LEVEL 60 fahren lassen würde.

Richtig! Je nach dem ob ich nach oben oder unten fahre drehen die Lamellen immer zuerst bis zu maximum.

Zitat- Weiterhin heisst das, ich kann den Lamellenwinkel nur in der Aufwärtsbewegung beinflussen? Oder schließen sich die Dinger wieder, wenn ich sie nur 45 grad geöffnet habe und dann die Jalousie abwärts fahren lasse?

Die Lamellen drehen immer erst mal komplett bevor sie fahren. D.h. beim fahren nach unten drehen sie je nach Stellung zuerst auf 0 Grad und beim hochfahren drehen sie zuerst auf 90 bzw. 180 Grad.


Ich weiß nicht ob das dann die gleiche Baustelle ist, aber im täglichen gebrauch habe ich jetzt auch sehr einen Toggle Befehl vermisst.
Ich hab grad gesehen das der ja schon eingebaut ist. :) Der togglet bei mir nur nach oben.

Hallo holzwurm83,

in der Anlage ein kleines Modul als Diskussionsgrundlage. Die Datei in das Verzeichnis fhem/FHEM/ kopieren und in der cfg folgendermaßen definieren:
define <name> Jalousie <Rolloaktor> <DrehzeitAb> <AbwaertsZeit> <DrehzeitAuf> <AufwaertsZeit>
Beispiel:
define WZJalousie Jalousie WZRolloSued 5 26 7 26
<DrehzeitAb> + <AbwaertsZeit> muß dabei gleich REFERENCE_RUNNING_TIME_TOP_BOTTOM sein und
<DrehzeitAuf> + <AufwaertsZeit> gleich REFERENCE_RUNNING_TIME_BOTTOM_TOP

Mit den proceduren Jalousie_SetDownWinkel, Jalousie_SetDownSchatten, Jalousie_SetUpWinkel und Jalousie_SetUpSchatten solltest Du schon einige Grundfunktionen an der Jalousie erzielen können.
Alles ist jetzt auf eine Jalousie mit 90° Drehwinkel eingerichtet.
Jalousie_SetDownWinkel(  <name>, 45) Dreht die Lamellen bei Abwärtsfahrt auf den Winkel 45°
Jalousie_SetDownSchatten(  <name>, 60) Senkt die Jalousie auf Level 60 ab
Jalousie_SetUpWinkel( <name>, 90) Stellt den Jalousiewinkel bei Aufwärtsfahrt auf 90°
Jalousie_SetUpSchatten( <name>, 80) Fährt das Rollo nach oben auf Level 80

Gruß gevoo

Hallo gevoo,

ich habe das gleich mal ausprobiert. Nur irgendwas habe ich da wohl nicht ganz verstanden.
Ich habe das wie folgt definiert:
define TEST_WZJalousieOST Jalousie WG1_J_WZ_OST 3 57 3 58

mit

jalousie_SetDownSchatten(  TEST_WZJalousieOST, 60)

bekomme ich dann folgende Meldung!?
Unknown command jalousie_SetDownSchatten(, try help.

Hallo holzwurm83,

wenn Du es in der cfg eingibst oder in der fhem Befehlszeile, brauchst Du geschweifte Klammern
{jalousie_SetDownSchatten(  TEST_WZJalousieOST, 60)}
Und noch ein paar kleine Verbesserungen.

Gruß gevoo

Zitat von: gevoo am 11 Februar 2015, 19:23:42
Hallo holzwurm83,

wenn Du es in der cfg eingibst oder in der fhem Befehlszeile, brauchst Du geschweifte Klammern

Code Auswählen Erweitern

{jalousie_SetDownSchatten(  TEST_WZJalousieOST, 60)}
Und noch ein paar kleine Verbesserungen.

Gruß gevoo

Ich bekomme dann folgende Fehlermeldung.
Bareword "TEST_WZJalousieOST" not allowed while "strict subs" in use at (eval 43) line 1.

Hallo holzwurm83,

das heißt Du sollst TEST_WZJalousieOST in Anführungsstriche schreiben. Also so:
{jalousie_SetDownSchatten(  "TEST_WZJalousieOST", 60)}

Gruß gevoo

Zitat von: gevoo am 12 Februar 2015, 20:15:34
Hallo holzwurm83,

das heißt Du sollst TEST_WZJalousieOST in Anführungsstriche schreiben. Also so:

Code Auswählen Erweitern

{jalousie_SetDownSchatten(  "TEST_WZJalousieOST", 60)}

Gruß gevoo

Hallo gevoo,

sorry, aber jetzt habe ich folgende Meldung.

Undefined subroutine &main::jalousie_SetDownSchatten called at (eval 15033) line 1.

Hallo holzwurm83,

die Procedure heißt auch
Jalousie_SetDownSchatten
Damit sollte es jetzt aber passen.

Gruß gevoo

Hallo gevoo,

habe das heute noch mal getestet.

define <name> Jalousie <Rolloaktor> <DrehzeitAb> <AbwaertsZeit> <DrehzeitAuf> <AufwaertsZeit>
als Rolloaktor kommt der kommt der Aktor selbst rein und nicht der Kanal, oder?

Ich bekomme nur eine Fehlermeldung im Log, wenn ich einen Befehl ausführe.

set HMW_LC_Bl1_DR_KEQ0020771_03 LEVEL 111.842105263158 : Please define HMW_LC_Bl1_DR_KEQ0020771_03 first

Als Autor habe ich HMW_LC_Bl1_DR_KEQ0020771 definiert aber der passende Kanal zu diesem Autor heißt WG2_J_AZ_WEST. Kann es sein dass er da die Verbindung nicht herstellen kann?

Hallo holzwurm83,

Zitatals Rolloaktor kommt der kommt der Aktor selbst rein und nicht der Kanal, oder?

War so gedacht.

ZitatAls Autor habe ich HMW_LC_Bl1_DR_KEQ0020771 definiert aber der passende Kanal zu diesem Autor heißt WG2_J_AZ_WEST. Kann es sein dass er da die Verbindung nicht herstellen kann?

Da hast Du recht. Ich habe es jetzt so geändert, daß bei der Definition gleich der Kanal 03 angegeben wird. Ich hoffe, daß ich nichts übersehen habe.

Gruß gevoo

Hallo gewoon,

bei
{Jalousie_SetUpSchatten(  "TEST_AZJalousieWEST", 80)}
bekomme ich folgendes im LOG
2015.02.15 20:20:06 3: set HMW_LC_Bl1_DR_KEQ0020771 LEVEL 125 : Unknown argument LEVEL, choose one of  CONFIG

und bei
{Jalousie_SetUpWinkel(  "TEST_WZJalousieOST", 90)}
bekomme ich folgendes im LOG
2015.02.15 20:23:03 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/90_Jalousie.pm line 145.
2015.02.15 20:23:03 3: set  LEVEL 0 : Please define LEVEL first

Hallo holzwurm83,

ich habe die Definition nach Deinen Anfordernissen geändert:
-> define TEST_AZJalousieWEST Jalousie WG2_J_AZ_WEST  3 57 3 58
Also jetzt bei der Definition den Kanal verwenden.

Und wieder einige Verbesserungen.

Gruß gevoo

Hallo gevoo,

jetzt schaltet der Aktor.

Die Lamellen stellen sich nur nicht ein. Ich vermute das da die definition nicht korrekt ist. Die Stellung der Lamellen muss immer nach dem verfahren der Jalousie eingestellt werden.
Grundsätzlich ist beim abwärtsfahren ist die Lamelle immer komplett geschlossen (0°) und beim aufwärtsfahren ist die Lamelle immer komplett offen (90°)

Ich bekomme beim Fhemstart die Meldung:
Error messages while initializing FHEM:
configfile: Falsche Zeitangaben in Jalousie Definition TEST_WZJalousieOST: + <> REFERENCE_RUNNING_TIME_TOP_BOTTOM

Die Config des Kanals ist wie folgt:
REFERENCE_RUNNING_TIME_BOTTOM_TOP: 58 s
REFERENCE_RUNNING_TIME_TOP_BOTTOM: 57s

somit müsste doch die definition wie folgt lauten!?
define TEST_WZJalousieOST Jalousie WG1_J_WZ_OST 3 54 3 55

ich habe es auch so probiert, aber mit der gleichen Meldung.
define TEST_WZJalousieOST Jalousie WG1_J_WZ_OST 3 57 3 58

Hallo holzwurm83,

was steht den im log vor der Zeile? Da muß was stehen, was etwa so aussieht:
Name = TEST_WZJalousieOST, Parameter = ....................

Gruß gevoo

Hallo holzwurm83,

ZitatIch vermute das da die definition nicht korrekt ist.

Habe die Drehrichtung beim Runterfahren geändert.

Gruß gevoo

Zitat von: gevoo am 19 Februar 2015, 18:52:37
Hallo holzwurm83,

was steht den im log vor der Zeile? Da muß was stehen, was etwa so aussieht:

Code Auswählen Erweitern

Name = TEST_WZJalousieOST, Parameter = ....................

Gruß gevoo

Hier der LOG
2015.02.19 19:03:54 3: Name = TEST_WZJalousieOST, Parameter = Jalousie WG1_J_WZ_OST 3 54 3 55
2015.02.19 19:03:54 1: Jalousie mit Rolloaktor WG1_J_WZ_OST verbunden

Hallo holzwurm83,

die Definition
define TEST_WZJalousieOST Jalousie WG1_J_WZ_OST 3 54 3 55
stimmt.
Habe noch ein log eingebaut, um zu prüfen, daß die richtigen Config- Daten übernommen werden.

Gruß gevoo

Hallo gevoo,

den Fehler habe ich weiterhin.
Error messages while initializing FHEM:
configfile: Falsche Zeitangaben in Jalousie Definition TEST_WZJalousieOST:DrehzeitAb + AbwaertsZeit <> REFERENCE_RUNNING_TIME_TOP_BOTTOM

Danach muss ich die Definition neu setzten.
define TEST_WZJalousieOST Jalousie WG1_J_WZ_OST 3 54 3 55

Log:
2015.02.19 20:54:42 3: Name = TEST_WZJalousieOST, Parameter = Jalousie WG1_J_WZ_OST 3 54 3 55
2015.02.19 20:54:42 3: REFERENCE_RUNNING_TIME_TOP_BOTTOM = 57
2015.02.19 20:54:42 1: Jalousie mit Rolloaktor WG1_J_WZ_OST verbunden

Ich hatte nun die Fehlermeldung auch beim setzen der Definition. Das scheint wohl wieder ein Timeing problem zu sein. Nach einem get config und get state am Aktor lässt die definition ohne Fehler setzen.

Das mit den Stellungen verstehe ich noch nicht.

z.B. mit
{Jalousie_SetUpWinkel( "TEST_WZJalousieOST", 90)}
fahren die Jalousien auf 90% runter, aber es sollen sich doch nur die Lamellen auf auf 90° drehen.

Hallo holzwurm83,

Zitatfahren die Jalousien auf 90% runter, aber es sollen sich doch nur die Lamellen auf auf 90° drehen.

Ist auch ein Timingproblem. Ich habe die Sache etwas verzögert. Es kann bis zu 1 Minute vergehen, bis der richtige Winkel eingestellt ist.

Gruß gevoo

Hallo gevoo,

grundsätzlich schein es wohl zu funktionieren. Wobei mir nicht gang klar ist ob ich dich Grudsätzlich richtig verstanden habe wie du die Funktionsweise gedacht hast. 

Der Befehl z.B.
{Jalousie_SetUpWinkel( "TEST_WZJalousieOST", 90)}
fährt zuerst Jalousien auf 90% runter, wartet eine weile und dreht dann Lamellen auf auf 90°. Das ging auch bereits ohne die Verzögerng.

Sind die 90 dann der Winkel oder das level?

Kannst du mir das noch mal genauer erklären um es sauber testen zu können.

Danke Dir

Hallo holzwurm83,

Ausgangspunkt ist der Rolloaktor, der nur LEVEL kennt. Deshalb wird jetzt der Winkel in den entsprechenden LEVEL umgerechnet.
Wenn Du jetzt Jalousie_SetUpWinkel( "TEST_WZJalousieOST", 90) verwendest, müßte folgendes passieren:
- Jalousie_SetUpWinkel stellt den Winkel beim Hochfahren ein.
- Deshalb sollte sich die Jalousie bis nach ganz unten in Ihre Ausgangsposition bewegen ( RolloAktor LEVEL = 0).
- dann soll sich der Winkel auf den gewünschten Wert einstellen ( RolloAktor LEVEL = z.B. 9).
Ich werte also Deine Zeitangaben aus der Definition aus, um die Abwärtsbewegung in einen LEVEL Bereich für das Drehen und einen für die Abwärtsbewegung aufzuteilen.
Analog beim Hochfahren.

Gruß gevoo

Hallo gevoo,

die Anwendung im Alltag erschließt sich für mich noch nicht ganz, bzw. ist mir nicht ganz klar wie ich die Befehle anwenden soll. Meistens möchte man nur den Winkel unabhängig davon welcher Winkel gerade eingestellt ist änder.

Sorry, aber manchmal dauerst etwas länger. ;)


Wie ist das mit dem level? Beim ist

Level100 = ganz oben
Level0     = ganz unten

, oder stimmt da was mit der Verkabelung bei mir nicht? Wobei das passen sollte. Wenn ich am Modul nach oben drücke fahren die auch nach oben.

Hallo holzwurm83,

das sind jetzt die Proceduren auf niedrigster Ebene. Wenn die funktionieren, können wir bedienerfreundliche dazu bauen.

Gruß gevoo

Hallo gevoo,

Ok Danke! Ich werde es dann noch mal im Detail testen und dir ein Feedback geben. Bin nur leider erst ab Montag wieder zuhause.

Gruß

Hallo,

gibt es hier einen neuen Stand?
Ich habe meine Jalousien am Laufen, will aber noch die Winkel einstellen. Nach einigem Lesen im Forum (das scheint ja echt kompliziert zu sein), bin ich hierauf gestossen. Meine Jalousien arbeiten wie beschrieben.
Runterfahren: Sind ganz geschlossen
Hochfahren: Sind auf 90°-Stellung.
Ich möchte die Jalousien gerne auf ein bestimmtes Level fahren und dann in Stufen (max. 5 reichen) auf 90°öffnen können. Das ganze ohne erst ganz auf zu (Level 0) zu fahren.

Hat jemand schon so etwas gemacht und Codeschnipsel für mich? Ich bin noch nicht so in der Programmierung drinnen, um mir das selber erstellen zu können.

Gruß Jürgen

Hallo Jürgen,

es gibt noch nichts Neues. Mir fehlt ein bischen das Verständnis für die Details.
Läßt sich Deine Jalousie, wenn sie in einer bestimmten Höhe steht im Winkel verstellen?

Gruß gevoo

Hallo gevoo,
Ich kann meine Jalousien mit fhem auf alle mögliche Level fahren. Beim runterfahren sind sie ganz geschlossen und bleiben so in der Ziel- oder endstellung. Winkel kann ich über fhem nicht verstellen. Das geht nur über die Taster. Beim hochfahren stehen sie waagrecht und bleiben so, wenn ich auf ein bestimmtes Level von unten fahre. Wenn ich jetzt manuell auf einem Level einen öffnungswinkel einstelle und danach schlägt eine Automatik (PV-Anlage, zeitsteuerung...) zu und die Jalousie verändert den Level ist sie entweder ganz zu oder ganz auf. Damit bekomme ich Ärger mit meiner Frau.

Ich würde gerne beim runterfahren auf ein bestimmtes Level z.b schließen auf 60% anschließend die Lamellen so weit öffnen, das man durchschauen kann aber die Sonne nicht direkt durchkommt.

So etwas ähnliches habe ich hier gefunden, aber nicht verstanden wie ich es einbinde.

Gruß Jürgen

Hallo Jürgen,

Deinen Worten entnehme ich folgendes:
- Beim Herunterfahren, stehen die Lamellen auf geschlossen ( 0°).
- wird die Jalousie angehalten und der Aufwärtstaster betätigt, drehen die Lamellen so lange wie der Taster gehalten wird, bis 90° erreicht sind. Dann fährt die Jalousie wieder hoch.
- Betätigt man dann den Abwärtstaster, drehen zuerst die Lamellen in Richtung 0°.
- Sind die Lamellen auf 0°, dann fährt die Jalousie wieder abwärts.

Ist das korrekt so?

Gruß gevoo

Hallo Gebot,
1: korrekt
2: aufwärtstaster betätigen: Jalousien drehen und fahren hoch so lange, bis Abwärtstaster betätigt wird. Eine bestimmte lamellenstellung kann nur dadurch erreicht werden, das während der Drehung die Abwärtstaste betätigt wird. Es ist ein Taster, deswegen muss ich ihn nur betätigen aber nicht halten.
3: in der hochfahrbewegung kann ich die Jalousie durch Drücken der Abwärtstaste anhalten. Dann muss ich warten und zum Weiteren Abwärtsfahren die Taste nochmal drücken.

Gruß Jürgen

Hallo gevoo,
Meinte natürlich nicht Gebot. Das iPAD mit seiner Rechtschreibung bringt mich noch zum Wahnsinn

Hallo Jürgen,

jetzt habe ich erst einmal richtig verstanden, wie Eure Jalousien arbeiten. Ich werde das Modul entsprechend anpassen.

Gruß gevoo

Hallo Jürgen,

anbei die neue Version zum Testen:
# Vor Verwendung dieses Modules sind folgende Zeiten zu betimmen:
#   - Jalousie steht ganz oben: Abwaertstaste betaetigen und Zeit messen bis Lamellen
#      komplett geschlossen sind ( 0 Grad- Stellung) ==> DrehzeitAb
#   - Jalousie steht ganz unten: Aufwaertstaste betaetigen und Zeit messen bis Lamellen
#      komplett offen sind ( 90 Grad- Stellung) ==> DrehzeitAuf
#   - in der Weboberflaeche des Rolloaktors sind die korrekten Zeiten für den gesamten
#      Schliessvorgang ( Lamellen zu + Jalousie runterfahren) und den gesamten
#      Oeffnungsvorgang einzutragen
#
#   Die Jalousie wird folgendermassen definiert:
#
#   define <name> Jalousie <Rolloaktor_03> <DrehzeitAb> <DrehzeitAuf>
#
#   - <name> ist frei waehlbar
#   - <Rolloaktor_03> ist der Name des Kanal 03 des anzusteuernden Rolloaktors
#   - <DrehzeitAb> und <DrehzeitAuf> sid Zeitangaben in Sekunden -> siehe Beschreibung oben
#
#   {Jalousie_SetWinkel(<name>, 45)}
#   
#   in der fhem Eingabezeile stellt den Winkel der Lamellen auf 45 Grad ein.
#
#   set Jalousie level 60
#
#   faehrt die Jalousie auf 60 %
#

Gruß gevoo

Hallo gevoo,
habe die 90_Jalousie.pm ins FHEM-Verzeichnis zu den anderen .pm Dateien kopiert. Beim define (define testjal Kueche_Ost_03 2 2) erhalte ich die Meldung:

ZitatCannot load module Jalousie

Muss ich die 90_jalousie.pm noch laden oder ist der Aufruf falsch?

Ich habe doch richtig erkannt, dass Du die Fahrzeiten aus dem Device lädst, wo sie ja auch konfiguriert sind. Somit ist nur die Zeit anzugeben, die die Jalousie für das Wenden der Lamellen benötigt ohne die Zeit für Hoch- bzw. Runterfahren.

Gruss Jürgen

Hallo Jürgen,

Dein Define ist nicht ganz komplett. Es muß heißen:
define testjal Jalousie Kueche_Ost_03 2 2

ZitatIch habe doch richtig erkannt, dass Du die Fahrzeiten aus dem Device lädst, wo sie ja auch konfiguriert sind. Somit ist nur die Zeit anzugeben, die die Jalousie für das Wenden der Lamellen benötigt ohne die Zeit für Hoch- bzw. Runterfahren.

Ja das stimmt.

Gruß gevoo

Sorry gevoo,
hatte eingegeben:
define testjal Jalousie KU_Jalousie_Ost_03 2 2
und bekomme die Meldung:
Cannot load module Jalousie

Im log steht:

Zitat2015.05.03 19:43:55 1: reload: Error:Modul 90_Jalousie deactivated:
Global symbol "$msg" requires explicit package name at ./FHEM/90_Jalousie.pm line 129.
Global symbol "$msg" requires explicit package name at ./FHEM/90_Jalousie.pm line 133.
Global symbol "$msg" requires explicit package name at ./FHEM/90_Jalousie.pm line 161.

2015.05.03 19:43:55 0: Global symbol "$msg" requires explicit package name at ./FHEM/90_Jalousie.pm line 129.
Global symbol "$msg" requires explicit package name at ./FHEM/90_Jalousie.pm line 133.
Global symbol "$msg" requires explicit package name at ./FHEM/90_Jalousie.pm line 161.

2015.05.03 19:44:07 1: Perfmon: possible freeze starting at 19:44:06, delay is 1.489
2015.05.03 19:44:54 4: CUL_Parse: CUL_0 A 14 C9 845E 2A8260 000000 8565B200000500000931FFED -83.5
2015.05.03 19:44:54 1: PERL WARNING: Subroutine Jalousie_Initialize redefined at ./FHEM/90_Jalousie.pm line 37.
2015.05.03 19:44:54 1: PERL WARNING: Subroutine Jalousie_Define redefined at ./FHEM/90_Jalousie.pm line 47.
2015.05.03 19:44:54 1: PERL WARNING: Subroutine Jalousie_Undef redefined at ./FHEM/90_Jalousie.pm line 115.
2015.05.03 19:44:54 1: reload: Error:Modul 90_Jalousie deactivated:
Global symbol "$msg" requires explicit package name at ./FHEM/90_Jalousie.pm line 129.
Global symbol "$msg" requires explicit package name at ./FHEM/90_Jalousie.pm line 133.
Global symbol "$msg" requires explicit package name at ./FHEM/90_Jalousie.pm line 161.

2015.05.03 19:44:54 0: Global symbol "$msg" requires explicit package name at ./FHEM/90_Jalousie.pm line 129.
Global symbol "$msg" requires explicit package name at ./FHEM/90_Jalousie.pm line 133.
Global symbol "$msg" requires explicit package name at ./FHEM/90_Jalousie.pm line 161.

Gruß Jürgen

Hallo Jürgen,

dann zum nächsten Versuch.

Gruß gevoo

Habe wieder

Zitatdefine testjal Jalousie KU_Jalousie_Ost_03 2 2

eingegeben. Jetzt die Meldung

Zitatwrong syntax: define <name> Jalousie <Rolloaktor_03> <DrehzeitAb> <DrehzeitAuf>

.
Logfile:

Zitat2015.05.03 20:13:27 1: define testjal testjal Jalousie KU_Jalousie_Ost_03 2 2: wrong syntax: define <name> Jalousie <Rolloaktor_03> <DrehzeitAb> <DrehzeitAuf>

Es scheint, dass der Name irgendwo fest drinsteht.
Gruß Jürgen

Hallo Jürgen,

einen hatte ich noch übersehen. Jetzt sollte es funktionieren.

Gruß gevoo

Hallo gevoo,

jetzt hat es doch etwas gedauert, bis ich weitermachen konnte. Habe FHEM auf einen Raspi umgezogen und das hat Dank meiner mangelnden Linux-Kenntnisse doch etwas gedauert.

Habe alles so eiongestellt wie geschrieben. beim
define testjal Jalousie KU_Jalousie_Ost_03 2 2
kommt jetzt
Can't find string terminator '"' anywhere before EOF at (eval 411) line 1

Der Rest sieht so aus wie im Anhang.

Und das steht im Log:

Zitat2015.05.22 21:32:22 1: Jalousie mit Rolloaktor KU_Jalousie_Ost_03 verbunden
2015.05.22 21:32:22 1: PERL WARNING: Bareword found where operator expected at (eval 411) line 1, near """set"
2015.05.22 21:32:22 1: PERL WARNING:    (Missing operator before set?)
2015.05.22 21:32:22 1: PERL WARNING: String found where operator expected at (eval 411) line 1, near "set",""
2015.05.22 21:32:22 1: PERL WARNING: String found where operator expected at (eval 411) line 1, at end of line
2015.05.22 21:32:22 1: PERL WARNING:    (Missing semicolon on previous line?)
2015.05.22 21:32:51 4: CUL_Parse: CUL_0 A 14 06 A270 EF38E0 000000 00D52C25990000723D0C8042 -41
2015.05.22 21:34:39 4: CUL_Parse: CUL_0 A 14 2B 845E 2A8260 000000 8700DB00000400000931FCF7 -78.5
2015.05.22 21:35:31 4: CUL_Parse: CUL_0 A 14 07 A270 EF38E0 000000 00D52D259B0000720C0C8043 -40.5
2015.05.22 21:36:43 4: CUL_Parse: CUL_0 A 14 2C 845E 2A8260 000000 8700DB00000500000932FEF4 -80
2015.05.22 21:37:55 4: CUL_Parse: CUL_0 A 14 08 A270 EF38E0 000000 00D52C259A000071DC0C8041 -41.5

Gruß Jürgen

Hallo Jürgen,

o.k Fehler behoben, auf zum nächsten Versuch.

Gruß gevoo

Hallo gevoo,
hab die neue pm eingebunden. Die obige Meldung kommt nicht mehr. Wollte dann die Jalousie testweise auf Level 60 fahren.
Befehl in FHEM-Befehlszeile: {Jalousie_SetDownSchatten(  "testjal", 60)}

Dann erhalten ich die Meldung:

ZitatUnrecognized character \xC2; marked by <-- HERE after nSchatten(<-- HERE near column 27 at (eval 471) line 1.

Ich habe mir allerdings aus dem Thread zusammengesucht, dass dieser Befehl die Jalousie herunter fahren lassen sollte und hoffe, dass es stimmt. Vielleicht auch nur in einer älteren Version der 90_Jalousie.pm und den Befehl gibt es gar nicht mehr.
Du hast doch bestimmt schon eine Logik mit Deinem Modul laufen. Könntest Du nicht ein Codeschnipsel reinstellen, aus dem ersichtlich ist welche Befehle ich wie eingeben muss, damit die Jalousie z.B. auf Level 50 fährt und dann auf den Winkel 60 °? Würde zumindest mir sehr helfen.

Gibt es zu Deinem Modul ein Wiki, in dem die möglichen Befehele gelistet und evtl. erklärt sind, Dann würden die Beginner in FHEM, so wie ich, vielleicht besser zurecht kommen.

Gruß Jürgen

Hallo bmwfan,

die Anleitung findest Du in der Datei selbst.

Hier der Text:
# Vor Verwendung dieses Modules sind folgende Zeiten zu betimmen:
#   - Jalousie steht ganz oben: Abwaertstaste betaetigen und Zeit messen bis Lamellen
#      komplett geschlossen sind ( 0 Grad- Stellung) ==> DrehzeitAb
#   - Jalousie steht ganz unten: Aufwaertstaste betaetigen und Zeit messen bis Lamellen
#      komplett offen sind ( 90 Grad- Stellung) ==> DrehzeitAuf
#   - in der Weboberflaeche des Rolloaktors sind die korrekten Zeiten für den gesamten
#      Schliessvorgang ( Lamellen zu + Jalousie runterfahren) und den gesamten
#      Oeffnungsvorgang einzutragen
#
#   Die Jalousie wird folgendermassen definiert:
#
#   define <name> Jalousie <Rolloaktor_03> <DrehzeitAb> <DrehzeitAuf>
#
#   - <name> ist frei waehlbar
#   - <Rolloaktor_03> ist der Name des Kanal 03 des anzusteuernden Rolloaktors
#   - <DrehzeitAb> und <DrehzeitAuf> sind Zeitangaben in Sekunden -> siehe Beschreibung oben
#
#   {Jalousie_SetWinkel(<name>, 45)}
#   
#   in der fhem Eingabezeile stellt den Winkel der Lamellen auf 45 Grad ein.
#
#   set Jalousie level 60
#
#   faehrt die Jalousie auf 60 %
#



Viele Grüße

Christoph
PS: @gevoo: Ich bin gerade am testen.

Hallo Christoph,

ja genau so ist es, Du hast die Sache gründlich studiert. Dem habe ich erstmal nichts weiter hizuzufügen.
Über Rückmeldung zu Deinem Test bin ich dankbar.

Gruß gevoo

Hallo gevoo,

bei mir klappt die Initialisierung nicht:

015.05.25 11:31:20 3: Modul 90_Jalousie.pm: Init Done with Version V 0.00.06 - 24.05.2015
2015.05.25 11:31:20 3: Name = Jal_Tuer_Links, Parameter = Jalousie HMW_LC_Bl1_DR_LEQ0169803_03 2 2
2015.05.25 11:31:20 1: Jalousie mit Rolloaktor HMW_LC_Bl1_DR_LEQ0169803_03 verbunden
2015.05.25 11:31:20 1: PERL WARNING: Bareword found where operator expected at (eval 60) line 1, near """set"
2015.05.25 11:31:20 3: eval: {ReadingsVal("Jal_Tuer_Links",""set","")}
2015.05.25 11:31:20 1: PERL WARNING: (Missing operator before set?)
2015.05.25 11:31:20 1: PERL WARNING: String found where operator expected at (eval 60) line 1, near "set",""
2015.05.25 11:31:20 3: eval: {ReadingsVal("Jal_Tuer_Links",""set","")}
2015.05.25 11:31:20 1: PERL WARNING: String found where operator expected at (eval 60) line 1, at end of line
2015.05.25 11:31:20 3: eval: {ReadingsVal("Jal_Tuer_Links",""set","")}
2015.05.25 11:31:20 1: PERL WARNING: (Missing semicolon on previous line?)


Hallo Christoph,

Fehler beseitigt.

Gruß gevoo

Hallo gevoo,

danke für Deine schnelle Hilfe.
Das Initialisieren mit "define Jal_Tuer_Links Jalousie HMW_LC_Bl1_DR_LEQ0169803_03 2 2" hat nun geklappt.
Anschließend habe ich mir zwei WebLinks zum Testen erstellt "define JalTest weblink cmdList Jal_Wink45:Jal_Wink45:{Jalousie_SetWinkel(Jal_Tuer_Links,45)} Jal_Schatten60:Jal_Schatten60:{Jalousie_SetWinkel(Jal_Tuer_Links,60)}"

Wenn ich einen davon auswähle, bekomme ich den folgenden Fehler:
Bareword "Jal_Tuer_Links" not allowed while "strict subs" in use at (eval 159) line 1.


Im angehängten Bild ist auch ein kleines Problem: Oben im "Set" Auswahlfeld scheint sich ein Fehlermeldungstext eingeschlichen zu haben.

Vielen Dank für Deine Mühe !!
Viele Grüße
Christoph

Hallo Christoph,

versuch es bitte einmal so:
define JalTest weblink cmdList Jal_Wink45:Jal_Wink45:{Jalousie_SetWinkel("Jal_Tuer_Links",45)} Jal_Schatten60:Jal_Schatten60:Jalousie_SetWinkel("Jal_Tuer_Links",60)}

Gruß gevoo

Hallo gevoo,

Danke für die Hilfe, da habe ich mich wirklich als Anfänger geoutet :-)
Der Gerätename der Definition muss natürlich in Anführungsstriche.

Die cmdlist hat aber aus irgendeinem Grund trotzdem nicht funktioniert, aber das ist kein Thema für diesen Thread.

Ich habe dann mit {Jalousie_SetWinkel("Jal_Tuer_Links",60)}  in der Befehlszeile getestet und hatte dann da teilweisen Erfolg.

Zu den Rahmenbedingungen:
Die beiden Werte: reference_running_time_bottom_top und reference_running_time_top_bottom werden bei mir aus einem Grund, den ich nicht verstehe, immer mal wieder auf den Wert 1371,70 zurückgesetzt. Ich habe Sie dann mal wieder beiden auf 50 gesetzt (das ist die Zeit, die ich gemessen habe) und natürlich ein "Save Config" gemacht. Der Wert stand beim Testen dann auch jeweils 50.

Die Jalousie ist als "define Jal_Tuer_Links Jalousie HMW_LC_Bl1_DR_LEQ0169803_03 2 2" definiert.

Ich habe die Jalousie auf Level = 70 gefahren und dann {Jalousie_SetWinkel("Jal_Tuer_Links",60)}   und {Jalousie_SetWinkel("Jal_Tuer_Links",45)}  eingetragen.
Dabei ist sie zuerst auf Level = 84  und dann auf ca Level = 68 heruntergefahren. Dann habe ich angefangen die Werte zu testen:

{Jalousie_SetWinkel("Jal_Tuer_Links",65)} 
{Jalousie_SetWinkel("Jal_Tuer_Links",67)} 
{Jalousie_SetWinkel("Jal_Tuer_Links",63)} 
{Jalousie_SetWinkel("Jal_Tuer_Links",61)}

Dabei konnte ich sehr erfolgreich die Neigung der Lamellen fein justieren.
Mit einem Winkelwert hatten die Lamellenneigungen allerdings nichts zu tun. Es ist schließlich immer ein Thema, ob ich als letztes nach oben, oder nach unten gefahren bin.
Ich kann mir gut vorstelle, dass bei mir die werte von 50 sec rauf und runter sowie jeweils 2 sec Wendezeit noch nicht so genau passen. Das muss ich die Woche über mal testen.

Wenn ich mir jetzt überlege, was ich mir in der Bedienung wünschen würde, dann könnte es so aussehen:
Ich fahre die Jalousie mit dem normalen slider auf ein bestimmtes Level und  habe dann im webcmd noch einen Wert +1 und -1 mit dem ich die Position zum ausprobieren inkrementell in Einzelschritten verändern kann. Aus der Erfahrung heraus, kann ich den Wert dann mgl.  später auf +3 oder -2 setzen, je nachdem, was ich an meiner speziellen Jalousie dann haben will.
Mit den ermittelten Werten
Ich habe noch keine Möglichkeit gefunden, eine inkrementelle Einstellung zu hinterlegen. evtl. brauche ich da einfach noch mehr Ahnung.

Viele Grüße
Christoph

Hallo Christoph,

ich habe offenbar immer noch ein Verständnisproblem:
Es ist schließlich immer ein Thema, ob ich als letztes nach oben, oder nach unten gefahren bin.
Das must Du mir bitte etwas genauer erklären.

Gruß gevoo

Hallo gevoo,

ich habe nochmal etwas weiter getestet.
In den Fotos habe ich mit der normalen Steuerung das Level verändert.
Die Bilder zeigen:
1. Level 100 auf Level 50
2. Level 50 auf Level 60
3. Level 60 auf Level 40
4. Level 40 auf Level 50

In Bild 1 und Bild 4 steht das Level jeweils auf 50. Die Jalousie ist aber genau andersherum gekippt.

Mein nächstes Ziel war, Dir eine Sammlung von Daten mit Fotos zu schicken.
Dabei wollte ich eine Serie mit verschiedenen Positionen zeigen:
Also (Beispielwerte, hat nichts mit dem Log unten zu tun):
{Jalousie_SetWinkel("Jal_Tuer_Links",60)} 
{Jalousie_SetWinkel("Jal_Tuer_Links",30)} 
{Jalousie_SetWinkel("Jal_Tuer_Links",45)} 
{Jalousie_SetWinkel("Jal_Tuer_Links",70)} 
{Jalousie_SetWinkel("Jal_Tuer_Links",45)} 

Leider hat nicht jeder Befehl auch eine Reaktion gezeigt, so dass die Bilder keinen Unterschied gezeigt hätten.
Auch das Logfile war nicht so aussagekräftig, vor allen weil ich auch keine Korrelation zu den gesetzten Werten gefunden habe.
Kannst Du evtl. ein eigenes Log für die 90_Jalousie.pm erzeugen ?

2015.05.26 20:04:04 3: HM485: HMW_LC_Bl1_DR_LEQ0169803_03: level -> 51
2015.05.26 20:04:06 3: HM485_LAN: Event: I[0](2,Y,F,B)(D8) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:04:11 3: HM485_LAN: Event: I[1](2,Y,F,B)(DA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:04:11 3: HM485: HMW_LC_Bl1_DR_LEQ0169803_03: level -> 50
2015.05.26 20:04:16 3: HM485_LAN: Event: I[2](2,Y,F,B)(DC) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:04:30 3: HM485_LAN: Event: I[1](3,Y,F,B)(FA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:04:30 3: HM485: HMW_LC_Bl1_DR_LEQ0169803_03: level -> 49
2015.05.26 20:04:36 3: HM485_LAN: Event: I[3](0,Y,F,B)(9E) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:04:41 3: HM485_LAN: Event: I[1](1,Y,F,B)(BA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:04:46 3: HM485_LAN: Event: I[3](2,Y,F,B)(DE) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:04:55 3: HM485_LAN: Event: I[1](3,Y,F,B)(FA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:04:55 3: HM485: HMW_LC_Bl1_DR_LEQ0169803_03: level -> 48
2015.05.26 20:05:00 3: HM485_LAN: Event: I[3](0,Y,F,B)(9E) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:05:14 3: HM485_LAN: Event: I[1](1,Y,F,B)(BA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:05:14 3: HM485: HMW_LC_Bl1_DR_LEQ0169803_03: level -> 50
2015.05.26 20:05:19 3: HM485_LAN: Event: I[3](2,Y,F,B)(DE) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:05:29 3: HM485_LAN: Event: I[1](3,Y,F,B)(FA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:05:47 3: HM485_LAN: Event: I[3](0,Y,F,B)(9E) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:06:04 3: HM485_LAN: Event: I[1](1,Y,F,B)(BA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:06:04 3: HM485: HMW_LC_Bl1_DR_LEQ0169803_03: level -> 49
2015.05.26 20:06:09 3: HM485_LAN: Event: I[3](2,Y,F,B)(DE) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:07:01 3: HM485_LAN: Event: I[1](3,Y,F,B)(FA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:07:01 3: HM485: HMW_LC_Bl1_DR_LEQ0169803_03: level -> 50
2015.05.26 20:07:06 3: HM485_LAN: Event: I[3](0,Y,F,B)(9E) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:07:43 3: HM485_LAN: Event: I[1](1,Y,F,B)(BA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:08:11 3: HM485_LAN: Event: I[3](2,Y,F,B)(DE) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:08:20 3: HM485_LAN: Event: I[1](3,Y,F,B)(FA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:08:45 3: HM485_LAN: Event: I[3](0,Y,F,B)(9E) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:08:45 3: HM485: HMW_LC_Bl1_DR_LEQ0169803_03: level -> 49
2015.05.26 20:08:50 3: HM485_LAN: Event: I[1](1,Y,F,B)(BA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:09:14 3: HM485_LAN: Event: I[3](2,Y,F,B)(DE) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:09:18 3: HM485_LAN: Event: I[1](3,Y,F,B)(FA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:09:39 3: HM485_LAN: Event: I[3](0,Y,F,B)(9E) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:09:39 3: HM485: HMW_LC_Bl1_DR_LEQ0169803_03: level -> 48
2015.05.26 20:09:44 3: HM485_LAN: Event: I[1](1,Y,F,B)(BA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:10:08 3: HM485_LAN: Event: I[3](2,Y,F,B)(DE) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:10:22 3: HM485_LAN: Event: I[1](3,Y,F,B)(FA) 0000D511 -> FFFFFFFF [4] 69(i) 02
2015.05.26 20:10:31 3: HM485_LAN: Event: I[3](0,Y,F,B)(9E) 0000D511 -> FFFFFFFF [4] 69(i) 02


Viele Grüße
Christoph

Hallo Christoph,

kann ich aus Deinen Ausführungen schlußfolgern:
- daß die Lamellen beim Herunterfahren nach innen voll geschossen werden?
- daß die Lamellen beim Hochfahren nach außen voll geschlossen werden?
- daß sich beim Ändern des Level immer die Lamellen zuerst in die jeweilige Endlage drehen, bevor sich die Jalousie bewegt?

Gruß gevoo

Hallo Christoph,

wie wäre es, wenn wir mit dem Testen der Funktion Jalousie_SetWinkel beginnen.
Habe ein eigenes Log gebaut.
Stell die Jalousie an ein beliebiges Level und experimentiere mit Jalousie_SetWinkel herum.

Gruß gevoo

Hallo gevoo,

Zitat von: gevoo am 27 Mai 2015, 20:11:50
kann ich aus Deinen Ausführungen schlußfolgern:
1. daß die Lamellen beim Herunterfahren nach innen voll geschossen werden?
2. daß die Lamellen beim Hochfahren nach außen voll geschlossen werden?
3. daß sich beim Ändern des Level immer die Lamellen zuerst in die jeweilige Endlage drehen, bevor sich die Jalousie bewegt?

Für die Jalousien, die bei mir eingebaut sind, stimmen die Aussagen 1 und 2.
Generell kann es aber auch genau andersherum sein, weil die gesamte Jalousie auch um 180 Grad gedreht eingebaut worden sein könnte.

Zur Aussage 3: nein, die Lamellen werden nicht eigenständig gesteuert, sondern erst durch die Bewegung des Zugbandes verändert.
Setze ich bei Level 50 ein Level 60, dann wird die Lamelle zusammen mit dem Einziehen der Jalousie gedreht. Ich mach mal ein Video :-)

Ich werde jetzt mal das neue Log mal erzeugen.

Viele Grüße
Christoph

hallo gevoo,

die Zeile 224 muss wie folgt heissen, sonst gibt es einen fehler:
print Datei "aktuelle Version ist jetzt $Jalousie_Version\n";

für den Test habe ich auf Level 50
die folgenden Befehle abgesetzt:
{Jalousie_SetWinkel("Jal_Tuer_Links",45)}
{Jalousie_SetWinkel("Jal_Tuer_Links",10)}
{Jalousie_SetWinkel("Jal_Tuer_Links",20)} (Ab hier keine Reaktion der Jalousie mehr)
{Jalousie_SetWinkel("Jal_Tuer_Links",30)}
{Jalousie_SetWinkel("Jal_Tuer_Links",40)}
{Jalousie_SetWinkel("Jal_Tuer_Links",50)}
{Jalousie_SetWinkel("Jal_Tuer_Links",60)}
{Jalousie_SetWinkel("Jal_Tuer_Links",70)}
{Jalousie_SetWinkel("Jal_Tuer_Links",80)}
{Jalousie_SetWinkel("Jal_Tuer_Links",90)}


aktuelle Version ist jetzt V 0.00.06 - 24.05.2015
2015-05-27_22:26:51 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = 45
2015-05-27_22:26:51 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = 0.5 deltaLevel = 0.25
2015-05-27_22:26:51 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 45 grad
2015-05-27_22:30:33 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = -35
2015-05-27_22:30:33 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = -0.388888888888889 deltaLevel = -0.194444444444444
2015-05-27_22:30:33 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 10 grad
2015-05-27_22:30:39 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = 10
2015-05-27_22:30:39 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = 0.111111111111111 deltaLevel = 0.0555555555555556
2015-05-27_22:30:39 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 20 grad
2015-05-27_22:30:44 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = 10
2015-05-27_22:30:44 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = 0.111111111111111 deltaLevel = 0.0555555555555556
2015-05-27_22:30:44 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 30 grad
2015-05-27_22:30:49 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = 10
2015-05-27_22:30:49 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = 0.111111111111111 deltaLevel = 0.0555555555555556
2015-05-27_22:30:49 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 40 grad
2015-05-27_22:30:54 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = 10
2015-05-27_22:30:54 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = 0.111111111111111 deltaLevel = 0.0555555555555556
2015-05-27_22:30:54 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 50 grad
2015-05-27_22:30:59 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = 10
2015-05-27_22:30:59 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = 0.111111111111111 deltaLevel = 0.0555555555555556
2015-05-27_22:31:00 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 60 grad
2015-05-27_22:31:04 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = 10
2015-05-27_22:31:04 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = 0.111111111111111 deltaLevel = 0.0555555555555556
2015-05-27_22:31:04 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 70 grad
2015-05-27_22:31:10 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = 10
2015-05-27_22:31:10 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = 0.111111111111111 deltaLevel = 0.0555555555555556
2015-05-27_22:31:10 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 80 grad
2015-05-27_22:31:14 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = 10
2015-05-27_22:31:14 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = 0.111111111111111 deltaLevel = 0.0555555555555556
2015-05-27_22:31:14 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 90 grad



Hallo Chrictoph,

offenbar reagiert der Aktor bei zu kleinen Leveländerungen nicht mehr. Ich habe das korrigiert. Dann mußt Du halt damit leben, daß der Winkel gleich um 18° verstellt wird anstatt nur um 10°. Bitte neu testen.

Gruß gevoo

Hallo gevoo,

erstmal vorneweg: bei mir wird es jetzt erstmal 2 Wochen ruhig weil ich im Urlaub bin.

Für den Test habe ich noch zwei weitere Logs in die Datei gespielt:
Den Level vor und den Level, der vom SetWinkel übergeben wird.

Insgesamt hat sich leider nur beim erstenmal bei 45 Grad etwas getan.
Ich werde nach meine Urlaub mal prüfen, ab welchen Werten der Aktor aktiv wird.

Viele Grüße
Christoph 


aktuelle Version ist jetzt V 0.00.06 - 24.05.2015
2015-05-29_15:55:19 Jalousie_Define: Jal_Tuer_Links, HMW_LC_Bl1_DR_LEQ0169803_03, 2, 2
2015-05-29_15:56:34 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = 45
2015-05-29_15:56:34 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = 0.5 deltaLevel = 0.25
2015-05-29_15:56:34 Jalousie_SetWinkel_Level_Vor : 53
2015-05-29_15:56:34 Jalousie_SetWinkel_Level_Nach : 53.25
2015-05-29_15:56:34 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 45 grad
2015-05-29_15:56:42 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = -35
2015-05-29_15:56:42 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = -0.388888888888889 deltaLevel = -0.194444444444444
2015-05-29_15:56:42 Jalousie_SetWinkel_Level_Vor : 53
2015-05-29_15:56:42 Jalousie_SetWinkel_Level_Nach : 52.8055555555556
2015-05-29_15:56:42 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 10 grad
2015-05-29_15:56:50 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = 35
2015-05-29_15:56:50 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = 0.388888888888889 deltaLevel = 0.194444444444444
2015-05-29_15:56:50 Jalousie_SetWinkel_Level_Vor : 53
2015-05-29_15:56:50 Jalousie_SetWinkel_Level_Nach : 53.1944444444444
2015-05-29_15:56:50 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 45 grad
2015-05-29_15:56:58 Jalousie_SetWinkel: Jal_Tuer_Links deltaW = 40
2015-05-29_15:56:58 Jalousie_SetWinkel: Jal_Tuer_Links deltaZeit = 0.444444444444444 deltaLevel = 0.222222222222222
2015-05-29_15:56:58 Jalousie_SetWinkel_Level_Vor : 53
2015-05-29_15:56:58 Jalousie_SetWinkel_Level_Nach : 53.2222222222222
2015-05-29_15:56:58 Jalousie_SetWinkel: Jal_Tuer_Links Winkel auf 85 grad


Hallo,

habe wieder weiter gemacht und dieses Mal genau die Anleitung befolgt.  ;)
1: Neueste 90_Jalousie.pm geladen.
2: Zeile 10 von 180 auf 90 geändert, da meine Jalousien 90 grad drehen.
3: Jalousie auf Level 70 gefahren.
4: Befehl {Jalousie_SetWinkel("Jal_KU_Ost_03",45)} in Befehlszeile eingegeben.

Leider keine Reaktion und im Log steht:
2015.05.30 20:56:37 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/90_Jalousie.pm line 190.
2015.05.30 20:56:37 1: PERL WARNING: Use of uninitialized value in division (/) at ./FHEM/90_Jalousie.pm line 195.
2015.05.30 20:56:37 1: PERL WARNING: Use of uninitialized value in division (/) at ./FHEM/90_Jalousie.pm line 196.
2015.05.30 20:56:37 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 3454.

Habs mir zwar angeschaut aber mangels PERL-Kenntnissen nicht analysieren können. Im Log der Jalousie ist lediglich der Fahrbefehl eingertagen. Ein weietrer Befehl zum Drehen wurde anscheinend nicht abgesetzt.
2015-05-30_21:07:10 Jal_KU_Ost_03 LEVEL 70
2015-05-30_21:07:19 Jal_KU_Ost_03 LEVEL: 70

Kann es sein, dass ein Parameter nicht übergeben wird?

Hallo Jürgen,

habe noch ein log eingebaut, was die Übergabe des Winkels kontrolliert.

Gruß gevoo

Hallo gevoo,
hab das neue Modul geladen, aber dasselbe Ergebnis.
2015.05.31 13:33:37 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/90_Jalousie.pm line 191.
2015.05.31 13:33:37 1: PERL WARNING: Use of uninitialized value in division (/) at ./FHEM/90_Jalousie.pm line 196.
2015.05.31 13:33:37 1: PERL WARNING: Use of uninitialized value in division (/) at ./FHEM/90_Jalousie.pm line 197.
2015.05.31 13:33:37 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 3454.

Das ist mein Aufruf:
# --- Lamellensteuerung der Jalousien. Test von gevoo
define testjal Jalousie Jal_KU_Ost_03 2 2
define FileLog_testjal FileLog ./log/testjal-%Y.log testjal
attr FileLog_testjal logtype text
attr FileLog_testjal room Z-Logfiles

cunj hat sich irgendwie zusätzliche logs erzeugt und konnte den define-befehl und die setwinkel mitloggen. Wie geht denn das? Wenn ich das auch einrichten könnte, wäre die Fehlersuche sicher leichter.
Gruß Jürgen

Hallo Jürgen,

das zusätzliche log liegt in Deinem log- Verzeichnis unter 90Jalousie*.log

Gruß gevoo

Danke.

Das steht drin:
aktuelle Version ist jetzt V 0.00.07 - 30.05.2015
2015-05-31_13:32:31 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2
2015-05-31_13:33:37 Jalousie_SetWinkel: Jal_KU_Ost_03 winkel = 45
2015-05-31_13:33:37 Jalousie_SetWinkel: Jal_KU_Ost_03 deltaW = 45
2015-05-31_13:33:37 Jalousie_SetWinkel: Jal_KU_Ost_03 deltaZeit = 0 deltaLevel = 0
2015-05-31_13:39:48 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2

Zur Anmerkung:
13:39 hatte ich einen restart gemacht und dabei stand das im Log-File:
2015.05.31 13:39:48 1: Including ./FHEM/Garage.cfg
2015.05.31 13:39:48 1: Jalousie mit Rolloaktor Jal_KU_Ost_03 verbunden
2015.05.31 13:39:48 1: Including ./log/fhem.save

Woher kommen deltalevel und deltazeit?

Hallo Jürgen,

habe noch logs eingebaut, um den Fehler zu finden.
Hast Du dem Jal_KU_Ost_03 die richtigen Zeiten gegeben?

Gruß gevoo

Hallo gevoo,
bin seit Montag auf Reisen und kann es erst heute abend testen.

Wenn Du die Zeiten Top_Bottom (64 sec.) und Bottom_Top (65 sec.) meinst: Ja. Sind definiert. Allerdings ist Reference_Run_Counter auf 0 gestellt, für was immer der Parameter auch steht.
Die Wendezeiten kommen ja über das define und sind mit je 2 sec. angegeben (siehe Zitat).

Gruß Jürgen

Hallo gevoo,

Modul eingebaut und getestet. Leider stellt sich noch kein Winkel ein, wobei ich vermutlich früher einen Fehler bei der Befehlseingabe gemacht hatte. Anbei die log's und meine Erklärungsversuche:

Zitataktuelle Version ist jetzt V 0.00.07 - 30.05.2015
2015-06-07_10:22:19 Jalousie_Define: Jal_KU_Ost_03, ,
2015-06-07_10:22:19 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2

Hier mit Befehl: {Jalousie_SetWinkel("Jal_KU_Ost_03",45)} versucht, Winkel einzustellen, wobei das der Aktor selber ist. Das stand im Log:

Zitat2015-06-07_10:40:18 Jalousie_SetWinkel: Jal_KU_Ost_03 winkel = 45
2015-06-07_10:40:18 Jalousie_SetWinkel: Jal_KU_Ost_03 deltaW = 45
2015-06-07_10:40:18 Jalousie_SetWinkel: Jal_KU_Ost_03 auf =  zu =
2015-06-07_10:40:18 Jalousie_SetWinkel: Jal_KU_Ost_03 deltaZeit = 0 deltaLevel = 0

und zusätzlich das im FHEM-log-file:

Zitat2015.06.07 10:40:18 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/90_Jalousie.pm line 197.
2015.06.07 10:40:18 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/90_Jalousie.pm line 201.
2015.06.07 10:40:18 1: PERL WARNING: Use of uninitialized value in division (/) at ./FHEM/90_Jalousie.pm line 203.
2015.06.07 10:40:18 1: PERL WARNING: Use of uninitialized value in division (/) at ./FHEM/90_Jalousie.pm line 204.
2015.06.07 10:40:18 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 3454.

Dann bin ich darauf gekommen, dass ich nicht den Aktor direkt sondern den Namen, den ich der Prozedur gegeben habe (testjal) ansprechen muss. Sorry. Anfängerfehler.

Hier mit Befehl: {Jalousie_SetWinkel("testjal",45)} wiederholt

Zitat2015-06-07_10:45:41 Jalousie_SetWinkel: testjal winkel = 45
2015-06-07_10:45:41 Jalousie_SetWinkel: testjal deltaW = 45
2015-06-07_10:45:41 Jalousie_SetWinkel: testjal auf =  zu =
2015-06-07_10:45:41 Jalousie_SetWinkel: testjal deltaZeit = 1 deltaLevel = 0

Jetzt waren keine Eintragungen im FHEM-Logfile, allerdings auch keine Verstellung des Winkels, was bei 45 ° doch sichtbar sein müßte.

Allerdings wundert es mich, dass die Zeiten für auf und zu leer sind. Das müßten doch die Zeiten sein, die aus dem Aktor ausgelesen werden. Stimmt das so?

Gruß Jürgen

Hallo Jürgen,

{Jalousie_SetWinkel("Jal_KU_Ost_03",45)}
kann nicht funktionieren, da das define die Zeiten für auf und zu nicht ermitteln konnte. Das kann mehrere Ursachen haben:
- Dein Aktor war noch nicht initialisiert
- Du hast die Prozedure zu für nach einem Neustart aufgerufen...

Um die Fehler einzugrenzen, teste es bitte noch einmal mit der angehängten Version.
In der fhem.cfg:
define testjal Jalousie Jal_KU_Ost_03 2 2

Dann Prüfen, ob in der Weboberfläche bei Jal_KU_Ost_03 die Zeiten für Auf und Abwärtsbewegung korrekt sind?

Dann in der fhem Befehlszeile
{Jalousie_SetWinkel("testjal",45)}

Dann die 90Jalousie*.log posten

Gruß gevoo

Hallo gevoo,
nächster Versuch.
Nach restart steht in der FHEM-log folgendes:

ZitatUse of uninitialized value in concatenation (.) or string at ./FHEM/90_Jalousie.pm line 87, <$fh> line 278.
2015.06.07 18:02:50 1: Jalousie Zeit f�r Abwaertsbewegung nicht definiert!
2015.06.07 18:02:50 1: Jalousie Zeit f�r Aufwaertsbewegung nicht definiert!
Use of uninitialized value in concatenation (.) or string at ./FHEM/90_Jalousie.pm line 113, <$fh> line 278.
Use of uninitialized value in concatenation (.) or string at ./FHEM/90_Jalousie.pm line 113, <$fh> line 278.
2015.06.07 18:02:50 1: Jalousie mit Rolloaktor Jal_KU_Ost_03 verbunden

Die Initialiserung ist (nur zur Kontrolle):
# --- Lamellensteuerung der Jalousien. Test von gevoo
define testjal Jalousie Jal_KU_Ost_03 2 2
define FileLog_testjal FileLog ./log/testjal-%Y.log testjal
attr FileLog_testjal logtype text
attr FileLog_testjal room Z-Logfiles

Das folgende steht dann im Log. Du hast recht. Er hat anscheinend die Fahrzeiten nicht, obwohl die in der Weboberfläche korrekt angezeigt werden (siehe Anhang) und die Jalousie auch dementsprechend fährt.

Zitataktuelle Version ist jetzt V 0.00.08 - 07.06.2015
2015-06-07_18:02:50 Jalousie_Define: testjal reference_running_time_top_bottom =
2015-06-07_18:02:50 Jalousie_Define: Jal_KU_Ost_03, ,
2015-06-07_18:02:50 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2
2015-06-07_18:11:09 Jalousie_SetWinkel: testjal winkel = 45
2015-06-07_18:11:09 Jalousie_SetWinkel: testjal deltaW = 45
2015-06-07_18:11:09 Jalousie_SetWinkel: testjal auf =  zu =
2015-06-07_18:11:09 Jalousie_SetWinkel: testjal deltaZeit = 1 deltaLevel = 0

Hast Du noch eine Idee?

Gruß Jürgen

Hallo Jürgen,

welche Version von 10_HM485.pm und Device.pm verwendest Du?

Gruß gevoo

Hallo gevoo,

war wieder einmal verreist. Deswegen die späte Antwort.
Folgende Versionen:

Zitathead1
   10_HM485.pm
   Version 0.5.124

Eine Device.pm finde ich nicht in meinem FHEM-Verzeichnis. Ich habe diese *device.pm Datei:

Zitat# $Id: 10_HXBDevice.pm 7686 2015-01-24 11:54:59Z borisneubert $

Mache aber regelmäßig die Updates von FHEM.

Fehlt mir evtl. eine Datei?

Gruß Jürgen

Hallo Jürgen,

probiere es bitte einmal mit der:
http://forum.fhem.de/index.php/topic,10607.msg300937.html#msg300937 (http://forum.fhem.de/index.php/topic,10607.msg300937.html#msg300937)

Gruß gevoo

Hallo Jürgen,

habe Deinen Beitrag im anderen Thread gelesen. Damit eine Synchronisation zwischen Rolloaktor und Jalousiemodul stattfindet, gehe bitte folgendermaßen vor:
Folgende Eingaben in fhem Kommandozeile und mit <ENTER> abschließen
set testjal level 50
{Jalousie_SetWinkel( 'testjal', 45)}
Dann hätte ich gern Informationen über
1. die Ausgangssituation ( bevor Du die Befehle eingegeben hast).
2. was ist nach Eingabe des 1. Befehls passiert
3. was ist nach Eingabe des 2. Befehls passiert
4. die dazugehörigen Logs.

Gruß gevoo

Hallo gevoo,
nachdem ich den Sommer über viele andere Dinge getan habe, kommen jetzt wieder die Jalousien dran. Habe Deine Befehle eingeben.
1: Ausgangszustand: Jalousie ganz offen.

ZitatInternals:
   DEF        Jal_KU_Ost_03 2 2
   NAME       testjal
   NR         490
   STATE      ??? sollen 3 Fragezeichen bedeuten
   TYPE       Jalousie
   Jalousie:
     ab         50
     aktor      Jal_KU_Ost_03
     auf        50
     drehZeitAb 2
     drehZeitAuf 2
     lastMove   ab
     winkel     0
   Readings:
     2015-06-14 21:06:35   winkel          0
Attributes:
   room       Kueche

2: Nach erstem Befehl:

Zitat2015.11.21 18:37:36 4: CUL_Parse: CUL_0 A 14 DD 845E 2A8260 000000 8830EB0000040000093BFFE0 -90
Illegal division by zero at ./FHEM/90_Jalousie.pm line 214.
2015.11.21 18:38:03 2: Perfmon: ready to watch out for delays greater than one second

FHEM stürzt wegen Division durch 0 ab. Anbei das log-File:

Zitataktuelle Version ist jetzt V 0.00.08 - 07.06.2015
2015-11-21_18:38:08 Jalousie_Define: testjal reference_running_time_top_bottom = 50
2015-11-21_18:38:08 Jalousie_Define: Jal_KU_Ost_03, 50, 50
2015-11-21_18:38:08 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2

Seltsam ist, dass das device aber folgende settings hat:

Zitatreference_running_time_top_bottom:   64 s

Bei meinen Versuchen hat es aber manchmal geklappt, die Jalousie auf einen bestimmten level fahren zu lassen. Wenn erfolgreich, konnte ein Winkel einegstellt werden, allerdings hat {Jalousie_SetWinkel( 'testjal', 90)} die Jalousie auf ca. 45 ° gestellt. Ich habe allerdings auch statt 180 ° 90 °-Jalousien konfiguriert.

Also 2 Probleme: Division durch 0 bei level XX und Winkeleinstellugn stimmt nicht.

Gruß Jürgen

Hallo Jürgen,

ich dachte schon die Aktion hast Du abgehakt.
In der Anlage die neue Testversion. Teste bitte wieder in der gleichen Reihenfolge, wie beim letzten mal.

Gruß gevoo

Hallo gevoo,

bei set testjal level 80 fährt die Jalousie auf den level 95, bei level 50 auf den tatsächlichen level 88. Meine Vermutung: Die im Device eingegebenen Fahrzeiten werden nicht ausgelesen.
Wo werden denn die programmierten Laufzeiten des Device in Deinem Code ausgelesen? Ich habs versucht zu finden, aber mangels Perl-kenntnissen nicht entdeckt.

bei {Jalousie_SetWinkel("testjal",90)} drehen die Jalousien um ca. 45 °.

Frage: das device muss so "testjal" oder so 'testjal' eingegeben werden?

Anbei das log-File und die Erklärung:

Zeit 09:43:00: testjal auf level 80 gefahren. Ist: level 95.
Zeit 09:44:05: Winkel 90° eingegeben. Ist auf ca. 45 ° gefahren.
Dann wieder auf level 100 hochgefahren, um neuen Versuch zu starten
Zeit 09:45:30: testjal auf level 50 gefahren. Ist: Level 88
Zeit 09:44:21: Winkel 90° eingegeben. Ist auf ca. 45 ° gefahren.

Jürgen

Hallo Jürgen,

ZitatWo werden denn die programmierten Laufzeiten des Device in Deinem Code ausgelesen?

in Zeile 105 und 107.
Welche HM-Wired Version benutzt Du eigentlich?

ZitatFrage: das device muss so "testjal" oder so 'testjal' eingegeben werden?

Ist eigentlich egal. Perl akzeptiert beides als string. Mir ist 'testjal' lieber.

Gruß gevoo

Müßten die aktuellen sein, da ich regelmäßig updates mache.

Zitat=head1
   00_HM485_LAN.pm Version 23.03.2015

=head1 SYNOPSIS
   HomeMatic Wired (HM485) Modul for FHEM
   contributed by Dirk Hoffmann 10/2012 - 2013
   $Id$

und

Zitat##############################################
# $Id: 00_HMLAN.pm 9886 2015-11-14 09:50:33Z martinp876 $

und

Zitat=head1
   10_HM485.pm
   Version 0.5.141

und

Zitat#############################################
# $Id: HMConfig.pm 9830 2015-11-08 19:04:41Z martinp876 $
# CUL HomeMatic device configuration data

Weis nicht genau, welches Modul Du meinst.

Gruß Jürgen

Hi,
wenn Du den HM485-Kram regelmäßig aktualisieren würdest,  dann hättest Du 0.7.2x in der 10_Hm485.pm.

@gevoo: Gut von Dir mal wieder was zu lesen. Ich hatte den Eindruck, Du hättest Dich komplett zurüchgezogen.

Gruß,
Thorsten

Wieder eine Lücke in meinen FHEM Kenntnissen?
Ich war der Meinung, dass der Befehl "update" alle Module updatet und den gebe ich mindestens jede Woche ein.
Wenn das genannte Modul damit nicht aktualisiert wird, wie kann ich es dann aktualisieren und wie kann ich erkennen, welche Module sonst auch nicht aktualisiert werden?

Gruß Jürgen

Zitat von: bmwfan am 22 November 2015, 20:31:12
Ich war der Meinung, dass der Befehl "update" alle Module updatet und den gebe ich mindestens jede Woche ein.

Nein, das klappt nur für die Module, die in der "offiziellen" FHEM-Auslieferung sind. Das ist für den HMW-Kram noch nicht der Fall.

Zitat
Wenn das genannte Modul damit nicht aktualisiert wird, wie kann ich es dann aktualisieren

Genau so, wie man es auch installiert. Ich habe gerade eine Anleitung im Wiki ergänzt: http://www.fhemwiki.de/wiki/HomeMatic_Wired (http://www.fhemwiki.de/wiki/HomeMatic_Wired)
Ich würde Dir empfehlen, das nicht auf die Schnelle zu machen. Inzwischen hat sich ganz schön viel getan, da kann es sein, dass Du ein paar Sachen in Deiner Installation ändern musst. Ich würde Dir empfehlen, auch gleich auf die Dev-Version zu gehen.

Zitat
und wie kann ich erkennen, welche Module sonst auch nicht aktualisiert werden?

Du hast wahrscheinlich die HMW-Dateien irgend wann einmal manuell reinkopiert. Alle Module, die so installiert sind, werden vom FHEM-update nicht behandelt.

Gruß,
   Thorsten

Hallo Thorsten,

zu spät.  ;)
Hab schon die Version 0.7.21 (und alle anderen Dateien aus dem downgeloadeden zip-File) wieder händisch reinkopiert. FHEM ist nach restart wieder problemlos angelaufen. Dann ein update gemacht. FHEM ist wieder angelaufen, ich habe allerdings jetzt Meldungen im log, die vorher nicht da waren. Z.B.:

Zitat2015.11.23 20:54:14 1: Perfmon: possible freeze starting at 20:54:13, delay is 1.387
2015.11.23 20:54:16 1: Perfmon: possible freeze starting at 20:54:15, delay is 1.861
2015.11.23 20:55:06 1: PERL WARNING: Use of uninitialized value in sprintf at fhem.pl line 2038.

Keine Ahnung, ob das von dem händischen Update kommt. Werde es noch beobachten.

Gibt es irgendwo eine Aufstellung, welche Module automatisch upgedatet werden und welche nicht?
Alternativ: Kann ich ein update-script erstellen, das mir auch die nicht automatische upgedateten Module prüft und ggf. updated?

Gruß Jürgen

P.S.: Da ich an einem Jalousienmodul etwas anpassen will suche ich schon eine Weile danach, wie PERL-Programme für FHEM entwickelt werden. Hardware: Raspi. Editor im Moment: Notepad++. Aber wie hier debuggen? Deswegen einige grundlegende Fragen an einen erfahrenen Entwickler:
Wie macht Ihr Entwickler das?
Nur im Editor schreiben und auf das laufende System zum Test aufspielen? Debugging mit Log-Einträgen?
IDE benutzen mit Debugger? Wenn ja, welchen
Das Ganze auf einem Entwicklungssystem oder auf der "scharfen" Hardware?

Bin da für jeden Tip dankbar.

Gruß Jürgen

Zitat von: bmwfan am 23 November 2015, 21:33:27ich habe allerdings jetzt Meldungen im log, die vorher nicht da waren.

Sowas in der Richtung habe ich bisher im Zusammenhang mit HM485 nicht gesehen.

Zitat
Gibt es irgendwo eine Aufstellung, welche Module automatisch upgedatet werden und welche nicht?
Alternativ: Kann ich ein update-script erstellen, das mir auch die nicht automatische upgedateten Module prüft und ggf. updated?

So ganz allgemein geht das wohl nicht, da das System ja nicht weiß, woher die nicht-FHEM Sachen her sind. ...aber wahrscheinlich kann man sich schon ein Skript schreiben, das den HM485-Kram runterlädt und reinkopiert. Ich arbeite aber auch gerade daran, HM485 in die "offizielle" FHEM-Auslieferung zu bekommen. Das kann aber noch ein bisschen dauern, da ich noch einiges an Doku schreiben muss.

Zitat
P.S.: Da ich an einem Jalousienmodul etwas anpassen will suche ich schon eine Weile danach, wie PERL-Programme für FHEM entwickelt werden. Hardware: Raspi. Editor im Moment: Notepad++. Aber wie hier debuggen? Deswegen einige grundlegende Fragen an einen erfahrenen Entwickler:
Wie macht Ihr Entwickler das?
Nur im Editor schreiben und auf das laufende System zum Test aufspielen? Debugging mit Log-Einträgen?

Genau so mache ich das. Manchmal braucht man ein "shutdown restart", aber oft reicht sogar ein "reload <Dateiname>".

Zitat
IDE benutzen mit Debugger? Wenn ja, welchen

Meine "IDE" ist notepad++, WinSCP und putty.

Zitat
Das Ganze auf einem Entwicklungssystem oder auf der "scharfen" Hardware?

Auf einem Entwicklungssystem. Insbesondere im Winter...

Gruß,
   Thorsten

Hallo Thorsten,

Zitat@gevoo: Gut von Dir mal wieder was zu lesen. Ich hatte den Eindruck, Du hättest Dich komplett zurüchgezogen.

Ich lese immer mit und bin begeistert, wie Ihr die Sachen schon weiterentwickelt habt. Ich bin mehr der Typ der nur was schreibt, wenn es auch etwas zu schreiben gibt. Deshalb war es in letzter Zeit etwas ruhiger. Ihr hab die Sache doch wunderbar gemeistert.

Gruß gevoo

Hallo Jürgen,

hast Du nach den letzten Updates noch einmal einen Test gefahren?

Gruß gevoo

Zitat von: gevoo am 24 November 2015, 20:32:16Ich lese immer mit und bin begeistert, wie Ihr die Sachen schon weiterentwickelt habt.

Danke für's Lob.
Wenn Du gerade mal was schreibst: Kannst Du erklären, wie das hier funktioniert:


<parameter id="SHORT_ONDELAY_TIME">
  <logical type="float" unit="s" default="0.0" max="982980.0" min="0.0"/>
  <physical size="2.0" type="integer" interface="eeprom" endian="little">
    <address index="+7"/>
  </physical>
  <conversion type="float_configtime" value_size="1.6" factors="0.1,1,60,1000"/>
  <conversion type="integer_integer_map">
      <value_map parameter_value="0xffff" device_value="0xc000" mask="0xc000"/>
  </conversion>
</parameter>

Ich habe mir auch das Coding dazu angesehen, aber das hilft auch nicht viel. Ich glaube, dass da irgendwo was nicht stimmt.
Gruß,
    Thorsten

Hallo Thorsten,

Ich kann Dir erklären, wie ich das interpretieren würde. Ob es stimmt weiß ich nicht:
Es handelt sich um den Parameter für die Wartezeit nach auslösen von press_short,
   - die Zeit ist vom Typ float, Einheit = s, Startwert = 0.0, Maximalwert = 982980.0, Minimalwert = 0.0
   - Sie wird im eeprom hinterlegt, mit einer Länge von 2 Byte, hier ist der Typ Integer --> der Wert wird mit Factors multipliziert bis ein Integerwert herauskommt
   - die Startadresse für den Wert liegt 7 Bit hinter der Startadresse für den Channel
   - intern in der Software wird der Wert als float_configtime mit einer Länge von 1Byte und 6Bit gespeichert, die Umrechnungsfaktoren sind 0.1,1,6,1000
   - zur Umrechnung von eeprom- Wert zu Softwarewert wird die Valuemap genutzt (vgl. device.pm)

Gruß gevoo

Hi,
soweit ist mir das auch klar. Allerdings verstehe ich das mit den Faktoren und der value_map nicht. Klar, ich kann mir das Coding betrachten, aber ich glaube, dass da was nicht stimmt. Könntest Du mal versuchen, genauer zu erklären, wie die Umrechnung geht?
Gruß,
   Thorsten

Hallo gevoo,
habe es jetzt nach update der 10_HM485 nochmal getestet, allerdings mit demselben Resultat. Am 23.11. hatte ich das letzte Mal einen restart gemacht. Wenn das der ausgelesene Wert ist, ist er definitiv falsch, da diese Zeit mit 64s im GUI angezeigt wird. Anbei das Log-File:

Zitataktuelle Version ist jetzt V 0.00.09 - 22.11.2015
2015-11-23_20:51:24 Jalousie_Define: testjal reference_running_time_top_bottom = 50
2015-11-23_20:51:24 Jalousie_Define: Jal_KU_Ost_03, 50, 50
2015-11-23_20:51:24 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2
2015-11-25_20:30:48 Jalousie_Set: testjal runter fahren auf 50
2015-11-25_20:30:48 Jalousie_SetWinkel: testjal winkel = 0
2015-11-25_20:30:48 Jalousie_SetWinkel: testjal deltaW = 0
2015-11-25_20:30:48 Jalousie_SetWinkel: testjal auf = 50 zu = 50
2015-11-25_20:30:48 Jalousie_Set: testjal level auf 50
2015-11-25_20:32:02 Jalousie_SetWinkel: testjal winkel = 90
2015-11-25_20:32:02 Jalousie_SetWinkel: testjal deltaW = 90
2015-11-25_20:32:02 Jalousie_SetWinkel: testjal auf = 50 zu = 50
2015-11-25_20:32:02 Jalousie_SetWinkel: testjal deltaZeit = 2 deltaLevel = 1
2015-11-25_20:32:02 Jalousie_SetWinkel: testjal Winkel auf 90 grad

Der Ist-Level war dann 88, der Winkel ca. 45..55.°.

Bei dem falschen Level habe ich die Vermutung, dass entweder
die in der GUI angezeigte Zeit für reference_running_time_top_bottom: 64 s. entweder gar nicht im device gespeichert ist sondern noch der Standardwert und der dann korrekt ausgelesen wird oder
das Modul den Wert nicht korrekt ausliest.
Das würde in beiden Fällen erklären, warum der Level (hängt ja von der Fahrzeit ab) nicht stimmt, nicht aber die große Abweichung von gewollt 50 auf Ist 88.

Beim falschen Winkel kann ich es mir nur aus einem Umrechnungsfehler erklären.

Hast Du einen Ansatz, was ich noch versuchen könnte?

Arbeite mich parallel in Perl ein, um Deinen Code besser verstehen zu können und selber Versuche zu machen.

Gruß Jürgen

@Thorsten,

wenn man entwicklen muss, muss das Programm ja auch Zugriff auf die device haben. Dann greife ich aber von 2 laufenden Instanzen auf die device zu. Das kann doch nicht gut gehen, denke ich.
Schaltest Du dann das laufende FHEM nab und fährst FHEM komplett auf der Entwicklungsumgebung oder schaltest Du im aktiven FHEM nur das Modul ab, an dem Du gerade entwickelst, um dieses dann auf der Entwicklungshardware laufen zu lassen? Oder noch ganz anders?

Von früher (Assemblerprogrammierung) kenne ich das so, dass ich ein komplettes Entwicklungssystem mit angeschlossenen device hatte und über Schalter / Taster die Ein/Ausgänge simuliert habe. Das geht ja hier aber nicht.

Vielleicht hast Du mir noch eine Tip, wie Du das machst.

Gruß Jürgen

Zitat von: bmwfan am 26 November 2015, 08:13:08
@Thorsten
Vielleicht hast Du mir noch eine Tip, wie Du das machst.

Ich habe einen zweiten RasPi, an dem ein komplett eigener RS485-Bus hängt. An den hänge ich dann HMW-Devices, die ich ansonsten nicht verwende. D.h. alles ist nur zum Test. Natürlich habe ich damit nicht mein komplettes System simuliert, aber zumindest die Teile, an denen ich gerade entwickle.

Zum anderen Problem mit den Fahrzeiten: Mich würde interessieren, wie das Jalousie-Modul die Fahrzeiten aus den Devices liest. Dazu gibt es nämlich kein Reading. D.h. man müsste relativ viel zu den Interna der Devices wissen und auch ausnutzen. Ich kann mir momentan nicht vorstellen, dass das so klappt.
Auch das Setzen von Werten in der Konfiguration eines Devices ist nicht ganz so einfach.
Ich habe mir mal überlegt, ob man für die Wired-Devices nicht so etwas ähnliches bauen sollte, wie für die HM-Funk Sachen. D.h. die Konfigurationen (d.h. der EEPROM-Inhalt) eines Devices würden dann als Readings bereit gestellt und könnten auch mit einem set-Befehl geändert werden.
Wird sowas gebraucht?

Gruß,
   Thorsten


Gruß,
   Thorsten

@Thorsten:
Danke für die Tips. Dann muss ja wohl ein 2.ter Raspi her und für das OG brauche ich sowieso noch einen HMLAN. Jalousiedevice habe ich auch noch.

ZitatFahrzeiten

Ich benutze das Modul 90_Jalousie.pm das, soweit ich weis, von gevoo stammt. Da bin ich mir aber nicht sicher.
Ich habe mir mit meinem bisherigen Wissen (Lesen, Testen, Fragen) folgendes zusammengereimt:
Die Fahrzeiten top->bottom und bottom->top gebe ich in der GUI ein. Werte siehe Anhang.
Diese müßten ja in das device geladen werden da es ansonsten nicht weis, wann es die Jalousie auf einem bestimmten level stoppen soll. Das funktioniert auch einwandfrei, wenn die Jalosuie direkt angesprochen wird.
Befehl:

Zitatset Jal_KU_Ost_03 level 50

Diese Werte liest das Modul aus und verwendet sie zur Berechnung der Zeitdauer, die die Jalousie fahren soll, bis die gewünschte Position erreicht ist. Nach dem Befehl

Zitatset testjal level 50

fährt die Jalousie allerdings nur auf den level 88.
In der Definition des Moduls define testjal Jalousie Jal_KU_Ost_03 2 2 gebe ich die Zeitdauer der Drehbewegung an. Damit und dem Wissen, ob die letzte Bewegung ab oder auf war kann das Modul den gewünschten Winkel ausrechnen und diese Zeitdauer lang einen Fahrbefehl an die Jalousie ausgeben.

So weit meine Theorie. Wenn jemandem ein Fehler auffällt, bitte melden. Schreiben in und lesen aus einem device ist für mich noch totales Neuland.

Die Ausleseroutine aus dem Modul 90_Jalousie.pm müßte diese sein:
sub Jalousie_Define($$$) {
my ( $hash, $def ) = @_;
# in dieser Version wird vorausgesetzt, daß zu Jalousie- Ansteuerung ein Rolloaktor
# benutzt wird
# Winkel 0 = geschlossen, Winkel $DrehWinkel = offen
my @a = split( "[ \t][ \t]*", $def );
my $name = $a[0];
my $reFloat ='^([\\+,\\-]?\\d+\\.?\d*$)'; # gleitpunkt 
Log3( $name, 3, "Name = $a[0], Parameter = $a[1] $a[2] $a[3] $a[4]");

if ( @a != 5) {
return "wrong syntax: define <name> Jalousie <Rolloaktor_03> <DrehzeitAb> <DrehzeitAuf>";
}
###################
# Aktor Werte ermitteln
my $aktor = $a[2];
my $drehAb = $a[3];
my $drehAuf = $a[4];
my $drehWinkel = $DrehWinkel; # 90 Grad Drehwinkel
   
# wenn aktor nicht definiert?
if ( !$defs{ $aktor} ) {
my $msg = "Jalousie_Define: $name: Unbekannter Aktor $aktor als Device festgelegt";
Log3 ( "Jalousie", 1, $msg);
return $msg;
}

# pruefen ob die angegebenen Zeiten mit der Config des Aktors uebereinstimmen
my $dabAnteil = 0;
my $daufAnteil = 0;
my $chHash = $defs{$aktor};
my $cHash  = HM485::ConfigurationManager::getConfigFromDevice($chHash, 0);
Logger( 'Jalousie_Define: ' . $name . " reference_running_time_top_bottom = " . $cHash->{reference_running_time_top_bottom}{value});
if ( defined( $cHash->{reference_running_time_top_bottom}{value}) && $cHash->{reference_running_time_top_bottom}{value}) {
if ( abs( $cHash->{reference_running_time_top_bottom}{value} - $drehAb) < 1) {
return "Falsche Zeitangaben in Jalousie Definition $name: DrehzeitAb > reference_running_time_top_bottom";
}
} else {
Log3 ( "Jalousie", 1, "Jalousie Zeit für Abwaertsbewegung nicht definiert!");
}

if ( defined( $cHash->{reference_running_time_bottom_top}{value}) && $cHash->{reference_running_time_bottom_top}{value}) {
if ( abs( $cHash->{reference_running_time_bottom_top}{value} - $drehAuf) < 1) {
return "Falsche Zeitangaben in Jalousie Definition $name: DrehzeitAuf > reference_running_time_bottom_top";
}
$daufAnteil = 100 * $drehAuf/ $cHash->{reference_running_time_bottom_top}{value};
} else {
Log3 ( "Jalousie", 1, "Jalousie Zeit für Aufwaertsbewegung nicht definiert!");
}

$hash->{Jalousie}{aktor} = $aktor;
$hash->{Jalousie}{drehZeitAb} = $drehAb;
$hash->{Jalousie}{ab} = $cHash->{reference_running_time_top_bottom}{value};
$hash->{Jalousie}{drehZeitAuf} = $drehAuf;
$hash->{Jalousie}{auf} = $cHash->{reference_running_time_bottom_top}{value};
$hash->{Jalousie}{winkel} = 0;
$hash->{Jalousie}{lastMove} = 'ab'; # merkt sich die letzte Bewegungsrichtung

Logger( 'Jalousie_Define: ' . $aktor . ', ' . $hash->{Jalousie}{ab} . ', ' . $hash->{Jalousie}{auf});

$modules{Jalousie}{defptr}{$name} = $hash;
Log3 ( "Jalousie", 1, "Jalousie mit Rolloaktor $aktor verbunden");
Logger( 'Jalousie_Define: ' . $name . ', ' . $aktor . ', ' . $drehAb . ', ' . $drehAuf);
# Readings
# Level gibt den Stand der Jalousie an: 0 = geschlossen, 100 = voll geoeffnet

# Winkel: gibt den Drehwinkel der Lamellen an: 0 = geschlossen, $DrehWinkel = offen

return undef;
}

So weit bin ich gekommen und versuche weiter herauszufinden, wo ich etwas ändern muss damit meine Jalousien auf das gewünschte level fahren und den gewünschten Winkel einstellen.

Gruß Jürgen

Hi,
die Zeile hier ist interessant:

Logger( 'Jalousie_Define: ' . $name . " reference_running_time_top_bottom = " . $cHash->{reference_running_time_top_bottom}{value});

Was steht denn da im Log?
Gruß,
   Thorsten

Mache schon den ganzen Abend daran herum und zeige mir die Parameter an verschiedenen Programmpunkten in die Log-Datei.
In der Zeile steht fast immer der Wert 50, ebenso wie in dem Wert bottom-top. Ein einziges Mal standen die in der GUO sichtbaren Werte (64 s. und 65s.) darin. Ich vermute somit, dass der Auslesebefehl schon korrekt ist, aber ein Timing-Problem vorliegt.
Das log mit den korrekten fahrzeiten:

Zitataktuelle Version ist jetzt V 0.00.09 - 22.11.2015
2015-11-26_20:39:56 Jalousie_Define: testjal reference_running_time_top_bottom = 64.00
2015-11-26_20:39:56 a[0]: testjal erster Wert des hash = testjal
2015-11-26_20:39:56 a[1]: nicht verwendet zweiter Wert des hash = Jalousie
2015-11-26_20:39:56 a[2]: Jal_KU_Ost_03 dritter Wert des hash = Jal_KU_Ost_03
2015-11-26_20:39:56 a[3]: 2 vierter Wert des hash = 2
2015-11-26_20:39:56 a[4]: 2 fünfter Wert des hash = 2
2015-11-26_20:39:56 Jalousie_Define: Jal_KU_Ost_03, 64.00, 65.00
2015-11-26_20:39:56 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2
2015-11-26_20:40:41 Jalousie_Set: testjal runter fahren auf 20
2015-11-26_20:40:41 Jalousie_SetWinkel: testjal winkel = 0
2015-11-26_20:40:41 Jalousie_SetWinkel: testjal deltaW = 0
2015-11-26_20:40:41 Jalousie_SetWinkel: testjal auf = 65.00 zu = 64.00
2015-11-26_20:40:41 Jalousie_Set: testjal level auf 20
2015-11-26_20:41:49 Jalousie_SetWinkel: testjal winkel = 90
2015-11-26_20:41:49 Jalousie_SetWinkel: testjal deltaW = 90
2015-11-26_20:41:49 Jalousie_SetWinkel: testjal auf = 65.00 zu = 64.00
2015-11-26_20:41:49 Jalousie_SetWinkel: testjal deltaZeit = 2 deltaLevel = 1.3
2015-11-26_20:41:49 Jalousie_SetWinkel: testjal Winkel auf 90 grad

Späteres log mit den "Standard"-Fahrzeiten:

Zitataktuelle Version ist jetzt V 0.00.09 - 22.11.2015
2015-11-26_21:08:42 Jalousie_Define: testjal reference_running_time_top_bottom = 50
2015-11-26_21:08:42 a[0]: testjal erster Wert des hash = testjal
2015-11-26_21:08:42 a[1]: nicht verwendet zweiter Wert des hash = Jalousie
2015-11-26_21:08:42 a[2]: Jal_KU_Ost_03 dritter Wert des hash = Jal_KU_Ost_03
2015-11-26_21:08:42 a[3]: 2 vierter Wert des hash = 2
2015-11-26_21:08:42 a[4]: 2 fünfter Wert des hash = 2
2015-11-26_21:08:42 Jalousie_Define: Jal_KU_Ost_03, 50, 50
2015-11-26_21:08:42 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2
2015-11-26_21:10:27 Jalousie_Set: 100 ReadingsVal des Levels aus device
2015-11-26_21:10:27 Jalousie_Set: testjal runter fahren auf 50
2015-11-26_21:10:27 Jalousie_Set: testjal level auf 50
2015-11-26_21:10:57 Jalousie_SetWinkel: testjal winkel = 90
2015-11-26_21:10:57 Jalousie_SetWinkel: testjal deltaW = 90
2015-11-26_21:10:57 Jalousie_SetWinkel: testjal auf = 50 zu = 50
2015-11-26_21:10:57 Jalousie_SetWinkel: testjal deltaZeit = 2 deltaLevel = 1
2015-11-26_21:10:58 Jalousie_SetWinkel: testjal Winkel auf 90 grad

Aber auch bei den korrekten Fahrzeiten hat der level nicht gepaßt. Muss noch ein weiterer Fehler vorliegen.

Gruß Jürgen

Ergänzung:
Das ist die Routine, die das device ausliest (mit meinen log-Befehlen):

Zitatmy $chHash    = $defs{$aktor};
   Logger( '$defs{$aktor}: ' . $chHash . " nachschauen, was das ist");
   my $cHash     = HM485::ConfigurationManager::getConfigFromDevice($chHash, 0);
   Logger( 'HM485::ConfigurationManager::getConfigFromDevice($chHash, 0): ' . $cHash . " nachschauen, was das ist");
   Logger( 'Jalousie_Define: ' . $name . " reference_running_time_top_bottom = " . $cHash->{reference_running_time_top_bottom}{value});

Und das steht im Log:

Zitataktuelle Version ist jetzt V 0.00.09 - 22.11.2015
2015-11-26_21:34:25 $defs{$aktor}: HASH(0x16e1ed8) nachschauen, was das ist
2015-11-26_21:34:25 HM485::ConfigurationManager::getConfigFromDevice($chHash, 0): HASH(0x332bec8) nachschauen, was das ist
2015-11-26_21:34:25 Jalousie_Define: testjal reference_running_time_top_bottom = 50

Wieder der Falsche Wert, aber mit den Werten HASH(0x....) kann ich nichts anfangen. Ich weis schon, dass dies Hexadezimalwerte sind, aber was stellen die dar?

Hi,
für mich sieht es auch so aus, dass die Werte richtig gelesen werden. In den Rest will ich mich jetzt nicht reinarbeiten, da muss vielleicht der Autor ran.
Gruß,
   Thorsten

Hallo Thorsten,

die Erklärung für

Zitat

Code Auswählen Erweitern

<conversion type="float_configtime" value_size="1.6" factors="0.1,1,60,1000"/>
  <conversion type="integer_integer_map">
      <value_map parameter_value="0xffff" device_value="0xc000" mask="0xc000"/>
  </conversion>

ist eigentlich was für Informatiker. Ich versuche es einmal als Praktiker:
Da nur ganzzahlige positive Werte gespeichert werden können gilt folgendes:
- ist SHORT_ONDELAY_TIME < 1/60 gilt der Faktor 1000 ( das ist ziemlich klein und damit wahrscheinlich nicht unbedingt von praktischem Wert).
- ist SHORT_ONDELAY_TIME >= 1/60 und SHORT_ONDELAY_TIME < 1 gilt Faktor 60
- ist SHORT_ONDELAY_TIME >= 1 und SHORT_ONDELAY_TIME < 49152 gilt Faktor 1 ( das entspricht 49152 = #C000 = 1100 0000 0000 0000) --> daher die 14 Bit
- ist SHORT_ONDELAY_TIME >= 49152 so gilt Faktor 0.1

In device.pm wird im Moment mit einer praktikablen Wertegröße gerechnet. Es wird davon ausgegangen, daß SHORT_ONDELAY_TIME >= 1 s ist bzw. 0.0 s als Sonderfall,
wenn nichts definiert ist.

Gruß gevoo

Hallo Jürgen,

In der Zeile:
my $cHash  = HM485::ConfigurationManager::getConfigFromDevice($chHash, 0);
wird der Channel- Hash für Channel 03 von Deiner Jalousie geholt. Solche Werte wie HASH(0x332bec8) sind nicht die Werte, die im Hash stehen, sondern das ist die Startadresse im Speicher.
Auf die Werte greiftst Du mit der nachfolgenden Zeile zu:
$cHash->{reference_running_time_top_bottom}{value}
Was soviel bedeutet wie: Gehe im Hash zur Abteilung reference_running_time_top_bottom und nimm dir das was dort im Speicher hinterlegt ist.
Der Configurationsmanager geht ( vgl. hmw_lc_bl1_dr.pm) in die Abteilung HMW_LC_BL1_DR -> channels -> blind -> paramset -> master -> parameter und ermittelt die Speicheradresse. Die wird als Hash zurückgegeben und bei uns als cHash bezeichnet.  Von der Adresse geht man Weiter im Configbaum bis zu reference_running_time_top_bottom wo im Speicher dessen Wert hinterlegt ist. Man könnte auch mit:
HMW_LC_BL1_DR -> {channels}{blind}{paramset}{master}{parameter}{reference_running_time_top_bottom}{value}
direkt auf den Wert zugreifen. Aber, da die ganze Validitätsprüfung schon im Configurationsmanager hinterlegt ist, wäre es dumm das nicht zu nutzen.
Soweit zur Theorie.
Wenn das 90_Jalousie.pm nicht die richtigen Werte ermitteln kann ( 50 ist nur ein Notbehelf, damit das Programm nicht abstürzt) könnte es folgende Ursachen haben.
- Die Definition von Deinem Rolloaktor liegt in der *.cfg hinter der Definition für die Jalousie.
- Die Intialisierung für den Rolloaktor dauert zu lange oder Deine Abfrage ist zu früh ( Ansichtssache).
- Dein Raspi ist mit anderen Sachen beschäftigt und hat keine Zeit dafür

Du könntest bitte einmal einen Auszug aus Deinem fhem-2015-11.log posten. Und zwar vom Start bis zur Definition der Jalousie.

Gruß gevoo

Hallo gevoo,

die Erklärung habe ich verstanden. Habe auch früher mit Referenzen gearbeitet. Diese Parameter sind doch entweder ein reading oder ein internal. Warum kann man denn nicht direkt darauf zurgreifen, wenn man den Namen des Parameters schon weis?

Anbei der Auszug aus dem log. Ist allerdings wochenweise statt monatsweise.

Zitat2015.11.26 21:34:16 0: Server shutdown
2015.11.26 21:34:16 4: CUL_send:  CUL_0X0 0     
2015.11.26 21:34:19 2: Perfmon: ready to watch out for delays greater than one second
2015.11.26 21:34:19 1: Including fhem.cfg
2015.11.26 21:34:23 1: Including ./FHEM/Sonstiges.cfg
2015.11.26 21:34:23 1: Including ./FHEM/Wohnzimmer.cfg
2015.11.26 21:34:24 1: Including ./FHEM/Jalousien.cfg
2015.11.26 21:34:24 1: Including ./FHEM/Arbeitszimmer.cfg
2015.11.26 21:34:24 1: Including ./FHEM/Flur_UG.cfg
2015.11.26 21:34:24 1: Including ./FHEM/Waschkueche.cfg
2015.11.26 21:34:24 1: Including ./FHEM/Garage.cfg
Prototype after '@' for main::Text2Speech_SplitString : @$$$$ at ./FHEM/98_Text2Speech.pm line 562, <$fh> line 387.
2015.11.26 21:34:25 1: Jalousie mit Rolloaktor Jal_KU_Ost_03 verbunden
2015.11.26 21:34:25 1: Including ./log/fhem.save
2015.11.26 21:34:27 0: Featurelevel: 5.7
2015.11.26 21:34:27 0: Server started with 149 defined entities (version $Id: fhem.pl 9993 2015-11-24 18:40:02Z rudolfkoenig $, os linux, user fhem, pid 5815)
2015.11.26 21:34:27 1: Perfmon: possible freeze starting at 21:34:20, delay is 7.493
2015.11.26 21:34:50 4: CUL_Parse: CUL_0 A 14 2F A270 27238A 31AE26 00E83A0000000004E30BB8F8 -78

und dazu das Log-File des Moduls:

Zitataktuelle Version ist jetzt V 0.00.09 - 22.11.2015
2015-11-26_21:34:25 $defs{$aktor}: HASH(0x16e1ed8) nachschauen, was das ist
2015-11-26_21:34:25 HM485::ConfigurationManager::getConfigFromDevice($chHash, 0): HASH(0x332bec8) nachschauen, was das ist
2015-11-26_21:34:25 Jalousie_Define: testjal reference_running_time_top_bottom = 50
2015-11-26_21:34:25 a[0]: testjal erster Wert des hash = testjal
2015-11-26_21:34:25 a[1]: nicht verwendet zweiter Wert des hash = Jalousie
2015-11-26_21:34:25 a[2]: Jal_KU_Ost_03 dritter Wert des hash = Jal_KU_Ost_03
2015-11-26_21:34:25 a[3]: 2 vierter Wert des hash = 2
2015-11-26_21:34:25 a[4]: 2 fünfter Wert des hash = 2
2015-11-26_21:34:25 Jalousie_Define: Jal_KU_Ost_03, 50, 50
2015-11-26_21:34:25 Jalousie_Define: testjal, Jal_KU_Ost_03, 2, 2

Da ich nur 2 verschiedene Laufzeiten für alle Jalousien habe, kann ich die Laufzeiten fest hinterlegen und muss sie nicht auslesen. Das wäre meine Notlösung, aber ein universelles Modul wäre mir lieber. Immerhin ist jetzt auch mein Entwicklerdrang erwacht und ich möchte mich mit Perl und der Hardware auseinandersetzen.  ;)

Zitat- Die Definition von Deinem Rolloaktor liegt in der *.cfg hinter der Definition für die Jalousie.

Liegt davor, da in Jalousie.cfg definiert. Ich weis, dass man das nicht macht (mehrere cfg) ist aber eine Anfängersünde meines Einstieges in FHEM. Jetzt will ich es nicht mehr ändern aus Sorge, dass dannn nichts mehr geht.

ZitatDie Intialisierung für den Rolloaktor dauert zu lange oder Deine Abfrage ist zu früh ( Ansichtssache).

Das kann ich doch nicht beeinflussen, da die Initialisierung beim Programmaufruf erfolgt oder verstehe ich das falsch?

Zitat- Dein Raspi ist mit anderen Sachen beschäftigt und hat keine Zeit dafür

Ich kann zwar die Auslastung generell überprüfen, aber wie das Monitoring des Raspi bei einer bestimmten Aktion (Rollo runterfahren) bzw. Zeitpunkt geht weis ich nicht.

Danke für Deine Hilfe und Erklärungen.
Gruß Jürgen

Hallo Jürgen,

Dein Rolloaktor ist noch nicht initialisiert beim Aufruf von Define Jalousie...
Deshalb können auch die Werte nicht ermittelt werden.
Abhilfe könnte ein at in Deiner *.cfg schaffen. In etwa so:

define SetJalousie at +00:01:00 {\
fhem("define testjal Jalousie Jal_KU_Ost_03 2 2");;
}
Damit wird die Definition um 1 Minute verzögert.

ZitatDiese Parameter sind doch entweder ein reading oder ein internal. Warum kann man denn nicht direkt darauf zurgreifen

Weil noch keiner die Schnittstelle programmiert hat.

ZitatIch weis, dass man das nicht macht (mehrere cfg) ist aber eine Anfängersünde meines Einstieges in FHEM.

Mache ich auch so, ist übersichtlicher.

Gruß gevoo

Hallo gevoo,

habe es jetzt mehrfach versucht.
1: Eingebaut in die Jalousie.cfg hinter dem define des device. Jalousie.cfg gespeichert. Dann fhem.cfg gespeichert. Keine Fehlermeldung.
2: Neustart und logs kontrolliert.
3: Die richtigen Werte werden ausgelesen (64 und 65 sec.), aber das define testjal ... steht jetzt nicht mehr in der Jalousie.cfg sondern in der fhem.cfg.
4: Nach nächstem Neustart kommt die Meldung:

Zitat2015.11.27 23:18:56 1: Including fhem.cfg
2015.11.27 23:19:00 1: Including ./FHEM/Jalousien.cfg
2015.11.27 23:19:00 1: Including ./FHEM/Sonstiges.cfg
2015.11.27 23:19:01 1: Including ./FHEM/Wohnzimmer.cfg
2015.11.27 23:19:02 1: Including ./FHEM/Arbeitszimmer.cfg
2015.11.27 23:19:02 1: Including ./FHEM/Flur_UG.cfg
2015.11.27 23:19:02 1: Including ./FHEM/Waschkueche.cfg
2015.11.27 23:19:02 1: Including ./FHEM/Garage.cfg
Prototype after '@' for main::Text2Speech_SplitString : @$$$$ at ./FHEM/98_Text2Speech.pm line 562, <$fh> line 370.
2015.11.27 23:19:02 1: Including ./log/fhem.save
2015.11.27 23:19:03 1: statefile: SetJalousie already defined, delete it first
2015.11.27 23:19:05 0: Featurelevel: 5.7

5: Jetzt sind wieder die Standardfahrzeiten (50 sec.) im Log.
6: Schaue ich in die Jalousie.cfg ist der Eintrag define SetJalousie... gelöscht und nur noch das define testjal in der fhem.cfg vorhanden.

Seltsames Verhalten. Wieso wird von FHEM ein define nach Ausführung gelöscht? Darf so etwas sein?

Gruß Jürgen

Hallo Jürgen,

Zitat1: Eingebaut in die Jalousie.cfg hinter dem define des device. Jalousie.cfg gespeichert. Dann fhem.cfg gespeichert. Keine Fehlermeldung.
2: Neustart und logs kontrolliert.
3: Die richtigen Werte werden ausgelesen (64 und 65 sec.), aber das define testjal ... steht jetzt nicht mehr in der Jalousie.cfg sondern in der fhem.cfg.

Hast Du eventuell "Save config" auf der Weboberfläche angeklickt?

Gruß gevoo

Zitat von: gevoo am 27 November 2015, 18:01:08die Erklärung für ist eigentlich was für Informatiker.

Ok. Irgendwo habe ich einen Zettel rumfliegen, auf dem mein Name steht und irgendwas von "Diplom". Auch das Wort "Informatik" ist drauf...

Zitat
Ich versuche es einmal als Praktiker:

Auch gut. Obiger Zettel ist relativ alt, seitdem habe ich das ganze fast nur in der Praxis ausgeübt.
SCNR...

Zitat
Da nur ganzzahlige positive Werte gespeichert werden können gilt folgendes:
- ist SHORT_ONDELAY_TIME < 1/60 gilt der Faktor 1000 ( das ist ziemlich klein und damit wahrscheinlich nicht unbedingt von praktischem Wert).
- ist SHORT_ONDELAY_TIME >= 1/60 und SHORT_ONDELAY_TIME < 1 gilt Faktor 60
- ist SHORT_ONDELAY_TIME >= 1 und SHORT_ONDELAY_TIME < 49152 gilt Faktor 1 ( das entspricht 49152 = #C000 = 1100 0000 0000 0000) --> daher die 14 Bit
- ist SHORT_ONDELAY_TIME >= 49152 so gilt Faktor 0.1

Wenn das so ist, dann müsste folgendes stimmen:

Wert in Realität	Wert im EEPROM
0.01s	10
0.1s	6
0.17s	10
5s	5
10s	10
50000s	5000

Ist das so gemeint? Wenn ja: Wie kann man unterscheiden zwischen 0.01s, 0.17s und 10s, wenn der interne Wert 10 ist?

Zitat
In device.pm wird im Moment mit einer praktikablen Wertegröße gerechnet. Es wird davon ausgegangen, daß SHORT_ONDELAY_TIME >= 1 s ist

Warum funktioniert es dann, wenn ich 0.2s eingebe? Das dürfte doch dann gar nicht gehen, oder?

Gruß,
   Thorsten

Zitat von: gevoo am 27 November 2015, 20:39:17Dein Rolloaktor ist noch nicht initialisiert beim Aufruf von Define Jalousie...
Deshalb können auch die Werte nicht ermittelt werden.
Abhilfe könnte ein at in Deiner *.cfg schaffen.

Dafür gibt es inzwischen ein Reading: configStatus. Erst wenn das auf "OK" steht kann man davon ausgehen, dass die EEPROM-Daten vom Device von FHEM gelesen wurden. (FHEM lädt den Kram beim Start jedesmal neu vom Device. Wie haben bei Wired ja kein Problem mit Sendekontingenten und so.)
configStatus kann noch folgende Werte annehmen:
PENDING: Das ist am Anfang, bevor das Interface initialisiert ist
READING: Währen die Daten gelesen werden
FAILED: Das kann man sich denken...
Letzteres bleibt nicht ewig stehen. Wenn etwas schief geht, dann pendelt es immer zwischen READING und FAILED, bis es irgendwann hoffentlich dann doch auf OK geht.
Das Reading wird auch geändert, wenn man "get ... config all" macht. Dann geht es auf READING und danach auf OK, wenn alles gut läuft.

ZitatWeil noch keiner die Schnittstelle programmiert hat.

Deswegen ja meine Frage, ob das gewünscht ist. Die Darstellung wird dadurch ggf. etwas unübersichtlicher, aber man kann die Werte halt einfacher lesen.

Gruß,
   Thorsten

Hallo Thorsten,

ZitatWenn das so ist, dann müsste folgendes stimmen:
Wert in Realität   Wert im EEPROM
0.01s   10
0.1s   6
0.17s   10
5s   5
10s   10
50000s   5000
Ist das so gemeint? Wenn ja: Wie kann man unterscheiden zwischen 0.01s, 0.17s und 10s, wenn der interne Wert 10 ist?

In etwa. Das wurde in device.pm Zeilen 1098- 1118 schon wunderbar gelöst.

Gruß gevoo

Zitat von: gevoo am 28 November 2015, 13:59:52
In etwa. Das wurde in device.pm Zeilen 1098- 1118 schon wunderbar gelöst.

Hi,
die Logik mit den Vergleichen kann ich nicht finden. Mir sieht das so aus, als ob das immer mit einem festen Wert multipliziert wird, egal
welcher Wert am Frontend eingegeben wird.
Ich glaube, dass ich da mal noch ein bisschen experimentieren muss.
Gruß,
   Thorsten

@gevoo:
Nach einigen Versuchen bin ich auf diese Methode gekommen, wie mir Änderungen in untergeordneten cfg-Dateien nicht mehr nach dem speichern verschwinden:
Zuerst die *.cfg speichern, dann fhem.cfg öffnen und speichern. Nach restart gibt es ein rotes Fragezeichen bei Save config auf der Weboberfläche. Dann das geklickt. So waren bisher meine Änderungen immer noch nach dem restart vorhanden.

Bis auf dieses Mal. Da war, wie geschrieben, die definition der testjal plötzlich in fhem.cfg, obwohl in Jlousie.cfg eingegeben. Hatte ich noch nie.

@Thorsten:
Als Beginner, zu denen ich mich noch zähle, wäre es einfacher, wenn man die konfigurierten Werte wie Fahrzeit ab... einfach über ein reading auslesen könnte. Was dann unübersichtlicher wird kann ich nicht beurteilen.

Als readings vom Rolloaktor

ZitatFW_VERSION 3.06
   IODev
   MODEL      HMW_LC_Bl1_DR
   NAME       Jal_KU_Ost_03

habe ich allerdings nur:

ZitatReadings:
     2015-11-28 07:50:41   direction       none
     2015-11-28 07:50:41   level           100
     2015-11-28 07:50:41   state           level_100
     2015-11-27 22:45:59   winkel          90
     2015-11-28 07:50:41   working         off

Zitat von: bmwfan am 28 November 2015, 16:48:58
@Thorsten:
Als Beginner, zu denen ich mich noch zähle, wäre es einfacher, wenn man die konfigurierten Werte wie Fahrzeit ab... einfach über ein reading auslesen könnte.

Hi,
mit der aktuellen dev-Version (0.7.33) geht das jetzt. Siehe auch hier: http://forum.fhem.de/index.php/topic,10607.msg367039.html#msg367039 (http://forum.fhem.de/index.php/topic,10607.msg367039.html#msg367039)
In der Regel sollten die Readings auch im fhem.save gespeichert werden. D.h. sie müssten von Anfang an verfügbar sein. (Nur halt nicht beim ersten Mal.) Allerdings ist es besser, wenn man auf configStatus = "OK" wartet.
Es müsste also z.B. beim Jalousieaktor ein Reading "R-reference_running_time_top_bottom" geben.
Gruß,
   Thorsten

Hallo,

Kann ich bestätigen mit der 0.7.33 siehts so aus:
Readings vom HMW_LC_Bl1_DR:

R-change_over_delay   0.50      2015-11-30 00:49:40
R-logging            on      2015-11-30 00:49:40
R-reference_run_counter   0      2015-11-30 00:49:40
R-reference_running_time_bottom_top   10.00   2015-11-30 00:49:40
R-reference_running_time_top_bottom   10.00   2015-11-30 00:49:40
direction            none   2015-11-30 01:01:19
level               0      2015-11-30 01:01:19
state            level_0   2015-11-30 01:01:19
working         off      2015-11-30 01:01:19

Gruß Robert

Hallo Jürgen,

damit vereinfacht sich das Jalousiee- Modul etwas  ;D

Gruß gevoo

Hallo Thorsten und Gevoo,

an beide ein dickes DANKE.

@Thorsten: Was gibt denn das reading Winkel genau an? Es kann ja nicht der tatsächliche Lamellenwinkel sein, da das device ja die Drehzeit und den ganzen Drehwinkel gar nicht kennt.

@gevoo: In Zeile 93 ist ein Klammerfehler. Muss korrekt so heißen:
if ( defined( ReadingsVal( $aktor, "R-reference_running_time_bottom_top", undef)) && ReadingsVal( $aktor, "R-reference_running_time_bottom_top", undef)) {

Werde morgen weiter testen.

Gruß Jürgen

Zitat von: bmwfan am 04 Dezember 2015, 21:43:37
@Thorsten: Was gibt denn das reading Winkel genau an? Es kann ja nicht der tatsächliche Lamellenwinkel sein, da das device ja die Drehzeit und den ganzen Drehwinkel gar nicht kennt.

Keine Ahnung. Normale HMW-Rolloaktoren haben das nicht. ...und wenn sie es hätten, dann wär's auf Englisch.
Gruß,
   Thorsten

Hallo Jürgen,

wenn das Modul einmal richtig läuft, soll der Winkel den tatsächlichen Winkel angeben. Er wird aus der Zeit, die sich die Lamellen drehen berechnet.

Gruß gevoo

Hallo gevoo,

da kommt wieder meine Unkenntnis durch. Ich war der Meinung, das die readings gerätespezifisch sind und in der Firmware vom Hersteller bereits festgelegt sind. Die Werte hinter den readings können dann auf einem EEPROM oder anderes Speichermedium im device geschrieben bzw. von dort ausgelesen werden.
Deiner Antwort nach, kommen die aber aus deinem Modul??? Da verstehe ich den Zusammenhang nicht, da ja über die verschiedenen 485er Module (10_HM485 ...) auf das device zugegriffen wird.
Kannst Du mir erläutern, was genau das 90_Jalousie.pm macht, das 10_HM485.pm, das 00_HM485_LAN.pm, communication.pm, configurationManager.pm ....?

Gruß Jürgen

Hallo Jürgen,

allgemein gesagt: ein Programmmodul macht das was man ihm beibringt.
In unserm speziellen Fall von 90_Jalousie.pm werden die Originaldaten des RolloAktors eingelesen und als Kopie im Hauptspeicher gehalten. Es werden weiterhin berechnete Werte hinzugefügt, als Readings angelegt und auch im Hauptspeicher gehalten. Weiterhin werden Daten zum RolloAktor übertragen und dessen Readings gespeichert, wie z.B. level. Da die Jalousie als Hardware körperlich nicht existiert, wird sie als Software nachgebildet, damit Du irgendwann einmal den Öffnungsgrad der Jalousie und den Drehwinkel direkt eingeben kannst.
Die Programmmodule 10_HM485.pm, das 00_HM485_LAN.pm, communication.pm, configurationManager.pm ... beziehen sich auf hardwareseitig wirklich, körperlich existierende  Geräte. Deshalb können diese auch in den Eeprom der Geräte schreiben oder von dort lesen.
Ich hoffe das hilft Dir?

Gruß gevoo

Hi,
ich vermute mal, dass 90_Jalousie.pm sowas macht wie "setreading <rolloaktor-kanal> Winkel <winkel>".
Man kann in FHEM praktisch von überall Readings in praktisch jedem Device setzen.
Gruß,
  Thorsten

@Thorsten,
bin gerade am Testen. Wie Du sagtest, ist das device noch nicht initialisiert, wenn das Modul die Daten auslesen will. Bekomme jetzt als R-reference_running_time_top_bottom und R-reference_running_time_bottom_top jeweils 0 ausgelesen. Wollte die Abfrage nach configStatus = ok einbauen, aber das reading steht nicht bei den "normalen" readings, sondern im Abschnitt Devhash. Wie frage ich hier den Status ab? Hast Du mir ein Code-Beispiel?

Zitatdevice     Jal_KU_Ost
   Readings:
     2015-05-30 20:10:21   IFTHEN          0:3
     2015-06-14 17:04:15   LEVEL           3
     2015-12-06 18:29:31   R-change_over_delay 0.50
     2015-12-06 18:29:31   R-logging       on
     2015-12-06 18:29:31   R-reference_run_counter 0
     2015-12-06 18:29:31   R-reference_running_time_bottom_top 65.00
     2015-12-06 18:29:31   R-reference_running_time_top_bottom 64.00
     2015-12-06 18:47:35   direction       none
     2015-12-06 18:47:35   level           76
     2015-12-06 18:47:35   state           level_76
     2015-12-05 13:21:33   winkel          90
     2015-12-06 18:47:35   working         off
   Devhash:
     CFGFN      ./FHEM/Jalousien.cfg
     DEF        0001076C
     FW_VERSION 3.06
     IODev      HM485_LAN
     MODEL      HMW_LC_Bl1_DR
     NAME       Jal_KU_Ost
     NR         97
     STATE      ACK
     TYPE       HM485
     channel_01 Jal_KU_Ost_01
     channel_02 Jal_KU_Ost_02
     channel_03 Jal_KU_Ost_03
     peer_act_0 channel_01 → Jal_KU_Ost_03
     peer_act_1 channel_02 → Jal_KU_Ost_03
     peer_sen_0 channel_03 ← Jal_KU_Ost_01
     peer_sen_1 channel_03 ← Jal_KU_Ost_02
     Readings:
       2015-12-06 18:29:31   R-central_address 00000001
       2015-12-06 18:29:31   R-logging_time  2.00
       2015-12-06 18:29:40   configStatus    OK
       2015-12-06 18:47:35   state           ACK
     Cache:

Gruß Jürgen

Hi,
configStatus ist ein Reading vom Device und nicht vom Kanal.
Gruß,
   Thorsten

So, bin wieder etwas weiter.

Es geht:

• Jalousie auf einen vorgegebenen Level fahren.
• Jalousie auf einen vorgegebenen Winkel stellen.
• Richtungsunabhängig, das heißt von unten und von oben.

Mußte allerdings etwas am Modul ändern, was dank der Hilfe aus dem Forum auch gelungen ist.

Was geht noch nicht so, wie ich es mir vorstelle:
Nach Eingabe eines Befehls, der einen level anfährt set testjal level 70 muss ich warten, bis der level auch erreicht ist bevor ich einen Befehl set testjal winkel 45 eingeben kann. Gebe ich den Befehl während der Fahrt der Jalousie ein, bleibt sie stehen. Den Grund verstehe ich schon, da ja letztendlich ein Winkel nichts anderes als ein umgerechneter level ist.

Also muss ich den Winkelbefehl so lange verzögern, bis der Fahrbefehl durchgeführt ist.
Zuerst wollte ich es auf PERL-Ebene mit "sleep" versuchen, habe aber noch rechtzeitig gelesen, dass dies FHEM blockiert.
Dann habe ich gelesen, dass es ein FHEM-sleep gibt. Allerdings ist mir unklar, wie ich dann den Befehl eingeben muss, da ja der Winkelbefehl eine variable Zeit (die Zeit, die die Jalousie braucht um in die neue Position zu fahren) verzögert werden muss. Über ein DOIF?

Ich hatte mir halt vorgestellt, mit einem Befehl set testjal 70 50 was bedeutet "set <name> <level> <winkel>" die Jalousie elegant steuern zu können, da ich ja alle Zeiten und berechneten level im Modul habe. Das wird ja so nicht gehen, da ja dann innerhalb des Moduls die Wartezeit abgewartet werden muss, bis der Befehl für die Winkelansteuerung an das device gesendet werden kann. Das blockiert dann aber FHEM.

Hat jemand eine Idee für eine elegantere Lösung des Problems?

Gruß Jürgen