Homematic wired

[Jewe]

Hallo,

meine disconnects sind weg. Es liegt an den DLAN-Adaptern. Ich habe den Raspi und den RS485 Adapter direkt an die Fritzbox angeschlossen und nun funktioniert es.

Jens     

[Thorsten Pferdekaemper]

Aber wie stell ich die Fahrzeiten ein ? Aktuell sind diese grau hinterlegt. [EDIT funktioniert mit 0.7.33]

Prinzipiell muss man warten, bis configStatus auf "OK" steht. Vorher ist der Inhalt des EEPROM nicht mit dem Zustand in FHEM synchronisiert und man würde unter Umständen Blödsinn machen, wenn man eine Einstellung ändert.
...außerdem gab es bis 0.7.30 einen Bug, durch den die Konfiguration in den Kanälen gar nicht über die Oberfläche geändert werden konnte.

Gibt es eine Möglichkeit sich die Versions-Nummer (Version 0.7.32) vom Programm (10_HM485.pm) in FHEM anzeigen zu lassen ?.

Nein, dazu muss man die Datei öffnen. Geht das denn für andere Module? Dann würde ich das einbauen...

Wie updatet ihr euer HMW System (https://github.com/kc-GitHub/FHEM-HM485/tree/dev)
Momentan lade ich das ZIP herunter und entpacke es von Hand (7-Zip Editor).

Genau so. Ich arbeite aber daran, HMW in die "richtige" FHEM-Auslieferung zu bekommen. Dazu muss ich aber vor Allem noch einiges an Doku nachliefern. Da die beiden Module inzwischen recht viel können ist das nicht ganz so schnell erledigt.

Als letzes noch ein Großes LOB für die Arbeit am HMW SW-Modul, das Einrichten funktionierte reibungslos.

Vielen Dank!

Gruß,
   Thorsten

[Thorsten Pferdekaemper]

meine disconnects sind weg. Es liegt an den DLAN-Adaptern. Ich habe den Raspi und den RS485 Adapter direkt an die Fritzbox angeschlossen und nun funktioniert es.

Es kann gut sein, dass eine zu große Latenz im Netzwerk zu Problemen führt. Die Zentrale schickt immer mal wieder eine Meldung, um zu überprüfen, ob der Adapter noch da ist. Wenn die Antwort zu spät kommt wird angenommen, dass dem nicht so ist und das System versucht, sich neu zu verbinden.
Theoretisch könnte wahrscheinlich auf der FHEM-Seite den Timeout konfigurierbar machen. Allerdings würde das das Problem dann auf die Kommunikation mit den Devices verschieben. Diese erwarten nämlich auch eine Antwort innerhalb einer bestimmten Zeit. Es ist also wahrscheinlich besser, in solchen Fällen das Netzwerk zu "reparieren".
Gruß,
  Thorsten

[gevoo]

Hallo Thorsten,

nochmal danke für Deine Arbeit. Habe jetzt zufällig bemerkt, daß bei Version 0.7.32, die press_short nicht richtig funktionieren.
Auszug aus dem Log eines Rollo- Aktors HMW_LC_Bl1_DR bei verbose = 4:

Code Auswählen Erweitern

2015.12.03 16:30:12 3: WZRolloSued_Zu: Send key_sim_short: 0000D4E3_03
2015.12.03 16:30:12 4: WZRolloSued_03: HM485_ChannelDoUpdate
2015.12.03 16:30:12 4: WZRolloSued_03: direction -> none
2015.12.03 16:30:12 4: WZRolloSued_03: level -> 100
2015.12.03 16:30:12 4: WZRolloSued_03: working -> off
2015.12.03 16:30:14 4: WZRolloSued_03: HM485_ChannelDoUpdate
2015.12.03 16:30:14 4: WZRolloSued_03: direction -> none
2015.12.03 16:30:14 4: WZRolloSued_03: level -> 100
2015.12.03 16:30:14 4: WZRolloSued_03: working -> off

Eigentlich sollte das Rollo herunterfahren, aber es tut sich nichts. Vermute in der Zeile 1491 beim 10_HM485.pm stimmt etwas nicht.
Es kann sein, daß der Fehler auch schon bei vorhergehenden Versionen aufgetreten ist. Aber ich habe ihn erst jetz bemerkt.
Das Rollo sollte mit

Code Auswählen Erweitern

set WZRolloWest_Zu press_short
geschlossen werden.

Gruß gevoo

[Thorsten Pferdekaemper]

nochmal danke für Deine Arbeit. Habe jetzt zufällig bemerkt, daß bei Version 0.7.32, die press_short nicht richtig funktionieren.
Eigentlich sollte das Rollo herunterfahren, aber es tut sich nichts. Vermute in der Zeile 1491 beim 10_HM485.pm stimmt etwas nicht.
Es kann sein, daß der Fehler auch schon bei vorhergehenden Versionen aufgetreten ist. Aber ich habe ihn erst jetz bemerkt.

Hi,
ich hab mir das mal angeschaut. (Jetzt kapiere ich auch, was press_short und press_long als Befehl soll.)
Der Fehler war nicht ganz so einfach zu finden. Es war ein prinzipielles Problem in HM485::Device::translateValueToFrameData. Hier hat wohl gar nichts funktioniert, was aus einer Konstante und einem zusätzlichen Wert (in der Reihenfolge) besteht.
Ich habe gerade Version 0.7.35 ins Git (dev) geschoben. Probier's mal damit.
Gruß,
   Thorsten

[RobertD]

Hallo Thorsten,

kurze Frage
wie definier ich das Attribute Logfile richtig ?

Attributes:
HM485d_logfile     HMW-Gateway-%Y-%m.log

Wenn ich das eingebe landen immernoch zentral alle Meldungen im fhem.log.
habs momentan über HM485d_logVerbose "5" gelöst, das er mir das logfile (fhem.log) nicht zuspamed.

Hintergrund ist mein HMW System (Gateway) ist momentan im Testbetrieb, heißt: nicht 24h online, der fhem aber läuft auf einem anderen system 24h.
Wenn ich nun fhem updatete und neustarte, started der hmw daemon und schreibt im 10 Sekundentakt ins logfile (fhem.log) das er nicht connecten kann.
2015.12.02 00:43:16 3: HM485_LAN: Warte auf Initialisierung Gateway
2015.12.02 00:43:21 3: HM485_LAN: Warte auf Initialisierung Gateway
2015.12.02 00:43:26 3: HM485_LAN: Warte auf Initialisierung Gateway
2015.12.02 00:43:31 3: HM485_LAN: Warte auf Initialisierung Gateway
Was ja auch stimmt, nur wäre das nun super wenn er das in ein seperates Logfile wie oben definiert schreibt.

Gruß Robert

[gevoo]

Hallo Thorsten,

danke, funktioniert jetzt einwandfrei.

Gruß gevoo

[Thorsten Pferdekaemper]

wie definier ich das Attribute Logfile richtig ?
Attributes:
HM485d_logfile     HMW-Gateway-%Y-%m.log

Das sieht schon gut aus. Das müsste Dir eine Datei  HMW-Gateway-2015-12.log erzeugt haben, in der die Meldungen des HM485d Daemons landen.

Wenn ich das eingebe landen immernoch zentral alle Meldungen im fhem.log.

Das glaube ich nicht, siehe unten.

habs momentan über HM485d_logVerbose "5" gelöst, das er mir das logfile (fhem.log) nicht zuspamed.

HM485d_logVerbose "5" bedeutet, dass Du jetzt die maximale Menge an Logeinträgen bekommst. Du siehst sie nur nicht, da sie in der Datei HMW-Gateway-2015-12.log landen und nicht in der Haupt-Logdatei.

Wenn ich nun fhem updatete und neustarte, started der hmw daemon und schreibt im 10 Sekundentakt ins logfile (fhem.log) das er nicht connecten kann.
2015.12.02 00:43:16 3: HM485_LAN: Warte auf Initialisierung Gateway
2015.12.02 00:43:21 3: HM485_LAN: Warte auf Initialisierung Gateway
2015.12.02 00:43:26 3: HM485_LAN: Warte auf Initialisierung Gateway
2015.12.02 00:43:31 3: HM485_LAN: Warte auf Initialisierung Gateway
Was ja auch stimmt, nur wäre das nun super wenn er das in ein seperates Logfile wie oben definiert schreibt.

Diese Meldungen kommen nicht vom HM485d, sondern vom HM485_LAN. Steht ja auch so da. Dafür gibt es kein separates Logfile. Du kannst nur das Loglevel für den HM485_LAN runtersetzen mit "attr HM485_LAN verbose 0". Dann dürfte das Ding nichts mehr ins Log schreiben.
Gruß,
   Thorsten

[RobertD]

Hallo Thorsten,

danke für die Tipps mit dem Debug-Level.

Gruß Robert

[gevoo]

Hallo Thorsten,

habe die Version aus dem dev 0.7.35 für den Rolloaktor etwas angepasst. Da Du jetzt die Readings erweitert hast, hat sich das etwas vereinfacht.
Es betrifft nur die sub HM485_ProcessResponse aus 10_HM485.pm.
Wenn Du diese Datei mit der Versionsnummer 0.7.35a mit ins git-dev einspielen könntest?

Gruß gevoo

[Thorsten Pferdekaemper]

habe die Version aus dem dev 0.7.35 für den Rolloaktor etwas angepasst. Da Du jetzt die Readings erweitert hast, hat sich das etwas vereinfacht.

Hi,
ich habe zurzeit keinen Zugriff auf den ganzen Kram und kann mir auch nicht einfach die Änderungen anzeigen lassen. Ich kann mich frühestens in einer Woche darum kümmern.
Gruß,
Thorsten

[Tomili]

Hi !

Seit ewigen Zeiten komme ich nun endlich mal wieder dazu, mich um das Thema FHEM zu kümmern.
Habe mir inzwischen einen Raspberry PI 2 gekauft.

Habe gesucht und gesucht: finde aber die Anleitungen nicht mehr, wie ich die "Wired Version" von FHEM, um die es hier in diesem Forum geht, auf dem Raspberry PI 2 installiert werden müssen. Auch den Link zu den neuesten Versionen etc.

Kann mir da jemand helfen?

Gruss,
Tomili

[ManfredC]

Moin,

Habe gesucht und gesucht: finde aber die Anleitungen nicht mehr, wie ich die "Wired Version" von FHEM, um die es hier in diesem Forum geht, auf dem Raspberry PI 2 installiert werden müssen. Auch den Link zu den neuesten Versionen etc.

bleeding edge:

https://github.com/kc-GitHub/FHEM-HM485/tree/dev

stable:

https://github.com/kc-GitHub/FHEM-HM485/tree/master

Wiki:

http://www.fhemwiki.de/wiki/HomeMatic_Wired

und dieser kurze Thread hier 

HTH,

Manfred

[Tomili]

Hallo Manfred,

DANKE! Habe alles wieder hinbekommen.
Gleich das nächste Problem, dass ich trotz einiger Suche nicht lösen konnte:

EIn langer Tastendruck löst bei mir folgende Zeilen aus:
2015-12-18 22:59:51 HM485 Buero_Taster press_long: 11
2015-12-18 22:59:51 HM485 Buero_Taster press_long_11
2015-12-18 22:59:51 HM485 Buero_Taster press_long: 11
2015-12-18 22:59:51 HM485 Buero_Taster press_long_11
2015-12-18 22:59:51 HM485 Buero_Taster press_long: 11
2015-12-18 22:59:51 HM485 Buero_Taster press_long_11
2015-12-18 22:59:51 HM485 Buero_Taster press_long: 11
2015-12-18 22:59:51 HM485 Buero_Taster press_long_11
(......)

Meine Script:
Kueche_Taster_Buerowand_unten.*PRESS_LONG.* {
   if ( Value('WZ_Lampe') eq 'ON') {
      fhem("set WZ_Lampe off");
   } else {
      fhem("set WZ_Lampe on");
   }
}

Lässt aber nur das Licht flackern, bzw. an und ausgehen, solange ich auf dem Schalter bleibe. Das war bei einer äteren Version nicht. Wie umgehe ich nun, dass das Lich an und ausgeht?

Beim nächsten mal lange drücken ist dann eine "12". Scheint hochzuzählen, aber wenn ich auf dem Schalter bleibe, bleibt die Zahl.

Kann mir jemand helfen?

Gruss,
Tomili

[gevoo]

Hallo Manfred,

Deine vorhergehende Version war schon etwas älter. Ändere Dein Script in:

Code Auswählen Erweitern

Kueche_Taster_Buerowand_unten.*press_long.* {
   if ( Value('WZ_Lampe') eq 'on') {
      fhem("set WZ_Lampe off");
   } else {
      fhem("set WZ_Lampe on");
   }
}
Dann sollte es gehen.

Gruß gevoo