HM-Sec-RHS und HM-CC-RT-DN sprechen (meistens) nicht mehr miteinander

Begonnen von Omega, 04 Oktober 2014, 10:32:40

Vorheriges Thema - Nächstes Thema

frank

ZitatZufallsbedingt erkennt mal der eine oder der andere Thermostat das geöffnete Fenster.
wie meinst du das? nach deinem log von gestern sollten die thermostate den fk korrekt erkennen und den fensterzustand auf dem display anzeigen. nur dein fhem (logs) bekommt nicht alles mit.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Omega

Folgende Aufzeichnungen habe ich gestern parallel zum Log gemacht (wollte ich eigentlich auch aufschreiben, hatte ich dann aber leider vergessen)

Wz.Fenster_Drehgriff   (EE = Thermostat_Essecke, TV = Thermostat_TV)
Open      Led: Rot
      EE:      ok (zeigt Fenster-offen-Symbol, desired Temp = 16.0)
      TV:      ok (zeigt Fenster-offen-Symbol, desired Temp = 16.0)

Closed   Led: Rot
      EE:       ok (Fenster-offen-Symbol weg, desired Temp = 21.5)
      TV:      ok (Fenster-offen-Symbol weg, desired Temp = 21.5)

Open      Led: Rot
      EE:      ok
      TV:      ok

Tilted      Led: Rot
      EE:       ok
      TV:       ok

Closed:   Led: Rot
      EE:       ok
      TV:      Fehler (zeigt Fenster-offen-Symbol. Desired Temp = 16.0)

Open      Led: Rot
       EE:      ok
               TV:      ok

Closed   Led: Rot
      EE:      ok
      TV:      Fehler (zeigt Fenster-offen-Symbol. Desired Temp = 16.0)

Soweit ich mich noch entsinne, habe ich danach den Test beendet und die Daten zusammengestellt.
Später, bei weiteren Tests, hatte ich immer einen Fehler, mal bei EE, mal bei TV. Manchmal wurde eine richtige Einstellung erst bei Umstellen auf Tilted erkannt.
Das größte Problem ist wohl, dass es kein eindeutiges Verhalten gibt (außer, dass die Led nach dem Schalten immer Rot leuchtet anstatt grün).

Gruß
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

frank

nach dieser liste hast du 2 fehler am tv-thermostat. jedes mal hat der fk die message an den thermostat gesendet, aber fhem konnte keine bestätigung empfangen. demnach wurde auch nichts gesendet. eigentlich dachte ich, die devices würden mehrere versuche des sendens machen. trotzdem bleibt die frage der roten led, obwohl alles funktioniert. ist der fk noch irgendwo anders als peer eingetragen?

2014.10.04 18:08:35.389 0: HMLAN_Parse: HMLAN1 R:E21E7DC   stat:0000 t:0107CD3F d:FF r:FFBB     m:6A A041 21E7DC 22EC4D 012D00

2014.10.04 18:11:53.153 0: HMLAN_Parse: HMLAN1 R:E21E7DC   stat:0000 t:010AD1E2 d:FF r:FFBC     m:70 A041 21E7DC 22EC4D 012F00


bei dir gibt es definitiv funkprobleme. warum auch immer. störfelder (wlan, dect, mikrowelle, tv, andere komponenten)? fhem sieht teilweise die antworten eines thermostat auf die zustandsmeldung des fk an den thermostat. die auslösende zustandsänderungsmeldung des fk aber nicht.

also erst einmal damit beginnen, dass fhem alles empfangen kann. ein erster schritt. sonst ist loggen auch nur spekulation.

edit: voraussetzung über "update" aktualisiertes fhem.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

franky08

@frank
Ich denke der Hinweis auf Update wird den Fehler beheben. Wenn man im Forum, in verschiedene Threads schaut, hat es oft an veralteten Modulen gehangen. Oft wird auch davon ausgegangen das die Installation von fhem 5.5 auf dem neusten Stand ist, ohne zu wissen das, dass der Stand von ca. einem Jahr ist.

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

frank

ZitatOft wird auch davon ausgegangen das die Installation von fhem 5.5 auf dem neusten Stand ist,
leider wahr, obwohl schon seit einiger zeit folgendes dabei steht:

ZitatDownload

    Last released version: (as of 2013-09-29): fhem-5.5.tar.gz, fhem-5.5.deb, fhem-5.5-fb7390.image, fhem-5.5-fb7270.zip
    See the CHANGED file for the change history or the svn log for a more detailed log.
    Note: the FHEM development is a continuous one, and a release is only a starting point for the update process. Please use the update command to get the most recent version, especially if you want to report issues in the forum.
    Nightly SVN version: a tarball, or from the fhem commandline via update.

das zeigt dann immer wieder das globale problem mit dem "lesen" auf. vielleicht sollte das mal jemand rot einfärben.  ;)

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

nicht rot - kann ich nicht sehen ;) - blau ist besser im Kontrast zu schwarz  :D

Omega

Gleich 2 x Frank - das ist gut...

Version ist (sollte zumindest sein lt. meinen Aufzeichnungen) vom 01.10.2014 (sowohl notice ... als auch update)

Folgende Moduldaten habe ich:
# $Id: fhem.pl 6425 2014-08-19 20:55:00Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 6478 2014-08-28 15:01:04Z martinp876 $
# $Id: 70_EGPM.pm 5344 2014-03-27 20:06:31Z alexus2033 $
# $Id: 17_EGPM2LAN.pm 5344 2014-03-27 20:06:31Z alexus2033 $
# $Id: 01_FHEMWEB.pm 6447 2014-08-24 07:38:52Z rudolfkoenig $
# $Id: 92_FileLog.pm 5876 2014-05-16 19:54:51Z rudolfkoenig $
# $Id: 00_HMLAN.pm 6471 2014-08-27 12:32:38Z martinp876 $
# $Id: 98_HMinfo.pm 6468 2014-08-27 08:13:42Z martinp876 $
./FHEM/99_MyUtils.pm: No such file or directory
# $Id: 73_PRESENCE.pm 6341 2014-08-01 21:56:21Z markusbloch $
# $Id: 99_SUNRISE_EL.pm 5851 2014-05-13 19:39:03Z rudolfkoenig $
# $Id: 98_SVG.pm 6446 2014-08-23 10:09:44Z rudolfkoenig $
# $Id: 99_Utils.pm 6446 2014-08-23 10:09:44Z rudolfkoenig $
# $Id: 90_at.pm 5319 2014-03-25 10:11:47Z rudolfkoenig $
# $Id: 98_autocreate.pm 6436 2014-08-21 05:40:35Z rudolfkoenig $
# $Id: 98_dummy.pm 4934 2014-02-15 08:23:12Z rudolfkoenig $
# $Id: 91_eventTypes.pm 6428 2014-08-20 11:51:27Z rudolfkoenig $
# $Id: 91_notify.pm 6371 2014-08-07 05:33:37Z rudolfkoenig $
# $Id: 33_readingsGroup.pm 6262 2014-07-16 07:46:03Z justme1968 $
# $Id: 98_structure.pm 6401 2014-08-13 07:00:48Z rudolfkoenig $
# $Id: 98_telnet.pm 4844 2014-02-08 07:54:03Z rudolfkoenig $
# $Id: 91_watchdog.pm 5622 2014-04-24 08:04:29Z rudolfkoenig $



hmmmm...
Ein erneutes update bringt nichts - auch nicht den Hinweis: nothing to do,
ein update check dagegen listet etliche Module auf. Da eh schon alles egal ist, habe ich ein update force ausgelöst. Der rödelt gerade vor sich hin....
und FHEM "stirbt". Ich hoffe mal, dass update force direkt den notwendigen restart auslöst.
War anscheinend so, FHEM ist wieder da und jetzt nach einem update check auch mit der Meldung: nothing to do. OK: dann ist bei den vorherigen Updates tatsächlich was schiefgelaufen aber jetzt sollte alles ok sein.

Auf ein Neues:
Leider nein. Led immer Rot bei jedem Schaltvorgang.
Beim 1. Öffnen lief TV wieder auf Fehler. Bei den folgenden Schaltvorgängen danach waren zumindest die Anzeigen an den Thermostaten ok.
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

franky08

Ich hatte damals ähnliche Probleme mit einigen HM-SEC-SC-2, da lag es an der Firmware. Mit Firm. 2.4 zeigte er brav grün, die mit Firm. 2.2 zeigten rot. Habe das Ganze dann über virtuelle Buttons gelöst. Geht bestimmt auch, wenn du das über eine vccu machst (vccu stellt ja auch virtuelle Buttons bereit). Nur wie das mit den peeren dann ist, weis ich nicht mehr so genau, da hat aber Martin bestimmt die Lösung parat. Ich denke du peerst den Drehgriff mit einem virtuellen Button der vccu und den RT ebenfalls mit dem virt. Button der vccu. Ob das stimmt weis ich leider nicht. Ich hab mir damals "händisch" virtuelle Buttons ohne vccu angelegt (gab es zu der Zeit noch nicht). Das Ganze geht bei mir dann über ein notify.
Fenster_Kueche {if(Value("Fenster_Kueche") eq "closed" && Value("KuecheWindow") eq "open")
{fhem "set Kueche_Heizung burstXmit; set myVirtualHM_Btn1 postEvent closed; set KuecheWindow closed"}
elsif (Value("Fenster_Kueche") eq "open" && Value("KuecheWindow") eq "closed")
{fhem "set Kueche_Heizung burstXmit; set myVirtualHM_Btn1 postEvent open; set KuecheWindow open" } }


VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

Omega

@franky08: Bin ziemlicher FHEM-Anfänger – also m.E. noch viel zu weit entfernt, um eine VCCU zu definieren + virtuelle Buttons und was weiß ich noch...
Trotzdem danke.


Ich habe jetzt folgende Tests gemacht: den Wz. Fenster_Drehgriff habe ich aus den Peerings entfernt, danach ein unpair.

Danach habe ich einen weiteren Sensor (HM-Sec-SC-2 mit Firmware 2.4) eingerichtet.
Solange der Sensor mit keinem Thermostat gepeert ist, funktioniert er einwandfrei (Led ist grün nach jedem Schaltvorgang). Nachdem ich ihn mit den Thermostaten gepeert habe, war bei jedem Schaltvorgang die Led wieder rot. Allerdings wurde der Schaltvorgang als solches von den Thermostaten immer einwandfrei umgesetzt. Da ich den Sensor noch nicht montiert habe, habe ich ihn mal dicht an den Thermostaten / HMLAN-Adapter und auch mal weit entfernt geschaltet – ohne Unterschied, d.h. für mich erst einmal: kein Funkproblem.
Danach habe ich den SC2 mit jedem Thermostat einzeln verbunden – auch hier kein Unterschied: Led immer rot.

Nach meinem letzten Versuch (erneute Neueinrichtung mit getconfig und Anlerntaste nach jedem einzelnen Schritt) hatte ich bei hm configCheck immer folgende Fehlermeldung:

configCheck done:

Register changes pending
    Wz.Thermostat_Essecke
    Wz.Thermostat_TV


Ich hatte immer gewartet, bis CMDs_done, bevor ich weitergemacht hatte. Auch ein set Wz.Thermostat_Essecke mit anschließendem Drücken der Anlerntaste bzw. set Wz.Thermostat_Essecke_ WindowRec mit anschließendem Drücken der Anlerntaste haben die Fehlermeldung nicht beseitigt. Auch ein Warten über Nacht brachte keine Änderung.

Danach habe ich folgendes gemacht:
•   FHEM gestoppt
•   Mit der Homematic-Software HMLAN wieder auf AES-Kommunikation umgestellt
•   Mit dem HM-Konfigurator die Thermostaten und den Fensterkontakt angelernt und anschließend eine direkte Geräteverknüpfung eingerichtet. Danach war bei jedem Schaltvorgang die Led Grün  :) – so, wie es sein soll.
•   Mit der Homematic-Software HMLAN die AES-Kommunikation wieder deaktiviert
•   FHEM gestartet
•   Hm configCheck: Fehler waren weg  :)
•   Fensterkontakt geschaltet: Led waren wieder Rot nach jedem Schaltvorgang  >:( >:( >:( .

Jetzt bin ich mit meinem Latein endgültig am Ende. Bei der Originalsoftware läuft die Kommunikation richtig, unter FHEM läuft (bei identischen Geräte-Einstellungen) etwas falsch.
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

franky08

#24
Hallo Omega, die Bestätigung mit grün, beim Fensterkontakt habe ich bei mir nur über "Umwege" hinnbekommen. Definiere dir unbedingt eine vccu:
http://forum.fhem.de/index.php/topic,23008.0.html

Dann peerst du deinen Fensterkontakt mit dem vccu, dass Pairing lässt du so wie es ist. Dann bekommt der Fensterkontakt von vccu eine Bestätigung und quittiert mit grün.
Hier im Forum, unter Homematic findest du etliches zu vccu.

P.S. Sonst ist mit deiner Konfiguration alles OK, da brauchst du nicht weiter drüber nachzugrübeln

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

frank

ZitatBei der Originalsoftware läuft die Kommunikation richtig, unter FHEM läuft (bei identischen Geräte-Einstellungen) etwas falsch.
das kann dann nur die kommunikation zwischen fk und fhem (hmlan) sein. wenn du den fk entpairst, müsste er also grün anzeigen. seltsam.  ???

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

franky08

#26
@frank
Das hängt mit der Firmware zusammen, die auf dem Sec-SC ist. Habe das vor langer Zeit mit Martin mal durchgetestet und müsste hier im Thread zu finden sein. Es gab unterschiedliche Firmwareversionen, mit mancher ging es, grün und mit einer anderen rot. Aber was wie war weis ich jetzt nicht mehr.

Müsste das hier gewesen sein:

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

P.s. Wie ich gerade sehe, gab es mit der Firm. 2.4 allerdings nie Probleme. Nur die 2.2 war zickig

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

frank

ZitatNur die 2.2 war zickig
und wie es aussieht auch die 2.1 vom rhs.

ist ja ein schönes durcheinander. da hast du aber fleissig pairen und peeren geübt.   ;D

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Omega

Ok – zunächst habe ich flüchtig den 12-seitigen Threat zu VCCU quergelesen.
Danach den Artikel Virtueller_Controller_VCCU im Wiki. Verstanden habe ich dennoch nicht, was mir eine VCCU bringt, solange ich nur ein einziges IO-Device (mein HMLAN) verwende?

Dann zum Verständnis meine Sicht.
Ich definiere eine VCCU. Ok, ich habe dann zusätzlich ein virtuelles Device. Das kann aber doch nicht senden, dass kann nur mein HMLAN.
Wenn ich meinen Fensterkontakt mit der VCCU peere. OK. Woher wissen dann aber die Thermostate, dass es beim Schalten für sie etwas zu tun gibt? Vermutlich muss ich also auch die Thermostate irgendwie an die VCCU anbinden. Wie?
Muss ich dann meine ganzen anderen Geräte auch an die VCCU anbinden? Oder geht das sowohl als auch?

Ich fühle mich etwas überfordert, mit meinen geringen FHEM-Kenntnissen ein Thema anzugehen, dass bisher anscheinend überwiegend nur von Profis durchgeführt wurde, zu dem wohl eine Wiki-Seite noch aussteht und zu dem konkrete Beispiele einer kompletten Einrichtung (und damit meine ich anfängerfreundlich Befehl für Befehl) noch nicht vorhanden sind (zumindest habe ich keine gefunden). Es wird ja immer gerne auf die Anfängerdokumentation verwiesen (verstehe ich) – aber über eine VCCU habe ich da nichts gefunden. Mir ist auch klar, dass hier ganz viel auf freiwilliger Basis erstellt wird – das finde ich auch toll und ich bin dankbar dafür.

Im Moment kann ich mich nicht entscheiden, wie ich weitermache. Das muss erst mal sacken.

Viele Grüße
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html