Wired

Hallo,

ich steige gerade neu in die HomeMatic ein und habe mich bereits ein gutes Stück eingearbeitet. Momentan habe ich alles versuchsweise auf dem Tisch, um das System kennenzulernen.

-CCU2: Ver: 2.25.15
-3x HM-WDS30-OT2-SM
-3x HM-CC-RT-DN
-2x HM-TC-IT-WM-W-EU
U.A. habe ich auch einige wired-Komponenten:
-2x HMW-LC-Sw2-DR FW-Ver.3.06
-1x HMW-IO-12-Sw14 FW-Ver.1.00

Die Sw2-DR sollen in Keller und Garage eingesetzt werden (deswegen Wired). Mit dem IO-12-Sw14 will ich u.a. Zustände von Kontakten überwachen.

Nun ist mir bei meinen Versuchen aufgefallen, dass nach dem wieder In Betrieb nehmen der wired-Komponenten (Netzspannung anlegen) die Zustände nicht von der CCU abgefragt oder von den Komponenten gesendet werden. Alle folgenden Änderungen werden angezeigt, auch Ausgänge lassen sich schalten - RS485 und LAN sind also OK. Der Effekt tritt auch auf, wenn die Verbindung, z.B. LAN-seitig, unterbrochen wird, eine Änderung direkt an den Komponenten getätigt wird und die Verbindung wieder hergestellt ist. Kommunikation funktioniert nach kurzer Zeit, aber die Änderungen während der Unterbrechung werden nicht gemeldet. So eine Unterbrechung im LAN oder am BUS ist ja möglich. Nur sollten die Zustände dann nachträglich übermittelt werden.

Wie kann ich die wired- Komponenten dazu bringen, die Zustände zyklisch zu melden, wie es z.B. die Thermostaten über BidCos-rf tun?

So wie es jetzt ist, kann ich ja nie sicher sein das die Zustände meiner zu überwachenden Kontakte und Schaltzustände die sind, die angezeigt werden.

Hallo Al.Andy,

hast du eventuell schon geprüft, ob es zum Wired-Gerät eine 'Erweiterte Anzeige' gibt bei der man dann eventuelle einen Klicker für eine "Zyklische Statusmeldung" setzen kann?

Freischalten der 'Erweiterte Anzeige':
HM-UI aufrufen; "Einstellungen->Benutzerverwaltung"; Benutzer "Admin" 'bearbeiten'; Klicker bei 'Modus vereinfachte
Verknüpfungskonfiguration aktivieren:' AUS-schalten und noch den Button "Einstellungen übernehmen" drücken.

Bei den "Funk-Wandthermostaten HM-TC-IT-WM-W-EU" gibt es dann 'plötzlich' eine ganze Menge mehr Einstellmöglichkeiten.

Gruß
Sternthaler

Hallo Sternthaler,

danke für die Tipps.
Den "vereinfachten Modus" habe ich natürlich ziemlich als Erstes deaktiviert. Ich will ja wissen was alles geht :p .
Die beiden wired-Typen, die ich bis jetzt habe, haben nicht viel zum einstellen.

Der HMW-IO-12-Sw14-DR hat gar nichts als Gerät. Nur bei den Kanälen kann man Betriebsmodi (analog/digital u.s.w.) ändern.

Der HMW-LC-Sw2-DR hat nur „Zeit nach der Logging-Meldung verschickt wird“ was default auf 2,0 Sekunden steht. Bei seinen Schaltern (Kanal 3, 4) kann man „Logging“ aktivieren oder deaktivieren. Mit denen habe ich gespielt.
Ergebnis:
Aktiviert - > die Änderungen werden bei bestehender Verbindung zur ccu gemeldet
Deaktiviert - > die Änderungen werden bei bestehender Verbindung nicht zur ccu gemeldet

Dann habe ich einiges über Skripte probiert.
1. Über die Datenpunkte der Komponenten:

WriteLine(dom.GetObject("HMW-LC-Sw2-DR MEQ1397074:4").DPByHssDP("STATE").Value());

Damit bekomme ich den Zustand, den die ccu „glaubt“ zu kennen. Mit und Ohne Verbindung der Komponenten zur ccu. Ändert sich ein Zustand während der Unterbrechung (Bedienung direkt am Gerät), wird der auch nach herstellen der Verbindung nicht aktualisiert, wenn ich den Script aufrufe.

2. Über den Status des Kanals ohne Datenpunkt:

WriteLine(dom.GetObject("HMW-LC-Sw2-DR MEQ1397074:4").State());

Komponente Verbunden, Schalter an:
Liefert „true“ ; WebUI zeigt „Ein“

Komponente nicht Verbunden, Schalter an:
Liefert „false“ ; WebUI zeigt weiterhin „Ein“

Schalter an Komponente aus während keine Verbindung besteht:
Liefert „false“ ; WebUI zeigt weiterhin „Ein“ (erwartungsgemäß)

Komponente wieder Verbunden, Schalter aus:
Liefert „false“ ; WebUI zeigt „Aus“

Daraufhin habe ich alle wired-Kanäle in ein Gewerk „wired“ gesteckt und das probiert:

string itemID;

foreach(itemID, dom.GetObject("wired").EnumUsedIDs())

{

WriteLine(itemID # dom.GetObject(itemID).State());

}

Das return lässt ein paar Sekunden auf sich warten, aber es werden alle Zustände aktualisiert. Das könnte man in regelmäßigen Abständen ausführen lassen (ohne „WrineLine“). Fraglich, ob das Verhalten in zukünftigen FW-Versionen noch das Selbe ist.
Wäre schön, wenn ohne Verbindung nicht „false“ sondern z.B. „null“ käme. Dann könnte man darauf reagieren.

Kennt jemand eine Möglichkeit, eine Störung dieser Art zu erkennen und zu melden? Z.B. mit einem Kommunikationstest zu den Komponenten?

Gruß
Al.Andy

Grüß dich Al.Andy,

da hast du ja auch schon einiges an 'Feldforschung' betrieben.

Ich bin sicher, dass du den extrem wichtigen Unterschied zwischen Value() und State() verstanden hast.
Dein Text ".. den die ccu 'glaubt' zu kennen .." sagt mir, dass du den Unterschied kennst.

Und genau da liegt der Hase im Pfeffer!
Wenn du nun vor hast, dass du per TIMER-Script die Statuswerte mit dem State() holen willst, ist die Idee an sich ja nicht schlecht, ABER du 'verbrennst' die zuläßige Funkzeit.
Dieser tatsächlich von der CCU2 eingehaltene gesetzlich vorgeschriebene Dutycycle von 1% pro Stunde. Das sind ja nur 36 Sekunden.
Und die CCU2 hat ja überhaut nichts zu funken :(

Ist es tatsächlich so, dass es heißt:
" -> „Logging“ aktivieren oder deaktivieren. -> "
und
" Deaktiviert - > die Änderungen werden bei bestehender Verbindung nicht zur ccu gemeldet " ????
-> Was hat denn der Begriff "Logging" bitte schön mit den Daten zu tun? Hier ist wohl wieder ein Spezialfall der eQ-3-Softwaremitarbeiter vorhanden :(

Aus deinem Test bei:

1. Über die Datenpunkte der Komponenten:
(Value())
und:
".. wird der auch nach herstellen der Verbindung nicht aktualisiert, wenn ich den Script aufrufe."
-> kann ich nur schließen, das die 'sendende Seite' noch nicht einmal speichert, dass sie eigentlich etwas zu Melden hat wenn sie bei einem Verbindungsverlust einen zu sendenden Statuswechsel bekommt.
Kenne ich. Ist typisch auch bei anderen Geräten!
Ich hatte von eQ-3 dann den 'heißen' Tipp bekommen, dass ich die Anzahl der Sendeversuche ja auf 10 setzen kann.
Sehr produktiv ist das nicht. Geschweige denn verläßlich.


Aus deinem Test bei:

2. Über den Status des Kanals ohne Datenpunkt:
(State())
und:
"Komponente wieder Verbunden, Schalter aus:"
"Liefert „false“ ; WebUI zeigt „Aus“"
-> bin ich etwas überrascht.
Du fragst AKTIV per State() nach der Info vom Datenpunkt und die CCU2 übernimmt das korrekt gelesene Ergebnis nicht auch in die WebUI???
Kannst du diesen Test nochmal wiederholen und in der WebUI die Ansicht neu anzeigen? Ich denke, dass du das schon gemacht hast. Aber sicher ist sicher ;)
Das geht doch gar nicht!!!

-> Und hierzu etwas widersprüchlich ist dabei dein Text aus:
"Daraufhin habe ich alle wired-Kanäle in ein Gewerk „wired“ gesteckt .."
plus
"WriteLine(itemID # dom.GetObject(itemID).State());"
plus
".. aber es werden alle Zustände aktualisiert."
-> Hast du nun die Datenpunktwerte nur in der Ausgabe vom "Script testen" gesehen, oder wurden die Status-Werte doch in der WebUI nach dieser Loop aktualisiert?

Von dir:
"Wäre schön, wenn ohne Verbindung nicht „false“ sondern z.B. null“ käme. Dann könnte man darauf reagieren."
-> Von mir: Oh ja, wer will das nicht.
Hallo eQ-3. Schon mal (darüber) nachgedacht?

Von dir:
"Kennt jemand eine Möglichkeit, eine Störung dieser Art zu erkennen und zu melden?"
Von mir:
Eventuell ist das hier auf deine Anforderungen ausbaubar:
http://homematic-forum.de/forum/viewtopic.php?f=31&t=24618
Es werden Statusmeldungen bearbeitet und die meldenden Gerätschaften sind im Script bekannt.
Möglicherweise machst du dir eine numerische Systemvariable pro Gerät die vom Script dann 'automatisch' hoch und runter gezählt wird wenn das Gerät eine Störung meldet.
Ich glaube aber, dass es nicht ausreichen wird, da ja die CCU keine Statusmeldung erhalten kann wenn der Gerätesender zu senden versucht aber eben nicht durchkommt.
Wahrscheinlich kann das Script nur Probleme erkenne, wenn die CCU selbst aktiv eine Verbindung zum Gerät fordert.
Also doch alle Geräte zyklisch per State() anpingen???

--------
Noch mal zum Dutycycle:
In meiner Kiste habe ich die zyklichen Einschaltvorgänge von bis zu 8 Aktor-Kanälen nun auf einen 5 Minuten-Takt gelegt da ich bei 3 Minuten schon einige Funk-Ausfälle hatte. (LogDatei der Kiste)
Bei meiner Heizung arbeite ich auch aus Sicherheitsgründen zyklisch.
- Erst Timer vom Aktor auf 8 Minuten setzen (2 Sensormeldungen),
- dann Aktor einschalten.
Fallen CCU2 und/oder der Sensor aus, dann schalten sich zumindest die Aktororen von alleine ab. (bis zu 54A)

Und ein bei mir beliebter Testvorgang.
Beim "Script testen" wartet man ja immer eine Ewigkeit und man weiß nicht ob und dass etwas passiert.
Ich nutze am Anfang und am Ende von allen zu testenden Scripten grundsätzlich:
WriteLine("Tu was Startzeit " # system.Date("%F %X"));
WriteLine("Hab getan Endezeit " # system.Date("%F %X"));
Dann ist man immer überrascht wie schnell das Script fertig ist und nur die 'merkwürdige' Umgebung schnarcht.

Gruß
Sternthaler

26.01.2017 Korrektur: Nicht 3,6 sondern 36 Sekunden sind die Dutyzeit pro Stunde.

Hallo Sternthaler,

die Sache mit dem Dutycycle kann ich so nicht stehen lassen, da es sich um RS485- und nicht RF-Komponenten handelt. Grundsätzlich ist das aber für mich verständlich.
Ob ich das so auc mit RF-Komponenten abfragen kann, habe ich noch nicht getestet. Ich habe noch ein HM-MOD-EM-8 auf dem Tisch. Mit dem könnte ich das mal bei Gelegenheit testen. Die Ergebnisse müssen sich aber auch nicht automatisch auf andere RF-Komponenten übertragen lassen.

Zu Deiner Frage der Statusaktualisierung: Ja, sie werden auch in der WebUI aktualisiert (allerdings nicht sofort automatisch, sondern erst nach dem neuen Aufrufen der Gerätes in "Status/Gerät") und nicht nur im Skript. Das genügt mir aber auch um sie werite Verarbeiten zu können. Die Aktualisierung der WebUI scheint durch ein Event angestoßen zu werden.

Schade: als ich mich vor den Anschaffungen mit Homematic beschäftigt habe, klang das bidirektionale Protokoll vielversprechend. Gerade bei den kabelgebundenen Komponenten hatte ich mehr erwartet da der Funkkanal nicht beansprucht wird. Eine zylkische statusmeldung wäre wohl kein Problem. Muss ja nicht im Sekundentakt sein.

Das Thema durchzieht viele Foren zu fast allen Produkten um die Betriebssicherheit wesentlich zu erhöhen.

Gruß
Al.Andy

Grüß dich Al.Andy,

upps, das mit deinen Wired-Geräten und dann hoffentlich keinem DutyCycle ist mir jetzt echt peinlich :(
Soll nicht wieder vorkommen. Liegt wohl daran, dass ich im Schaltschrank nur Funk-Komponenten verbaut habe und ich deshalb so 'empfindlich' bin.

Immerhin wird aber die UI zumindest nach manueller Aktualisierung doch mit dem Status vom Kanal nachgepflegt. Und wer sitzt schon immer vor der Kiste um das zu beobachten? (Außer den Stunden und Nächten in denen man mal wieder eine gute Idee hat!)

Zum gezielten Abfragen der Hardware mit dem State()-Befehl gibt es auch einige Anmerkungen, und auch Testvorschläge, die darauf hindeuten, dass State() wohl teilweise auch nur ein Fake von eQ-3 ist.
elotek weist in seinem letzten Beitrag Sehr gut oder doch nur gut? darauf hin, dass State() nicht vom 8-Kanal-Sender liest.
Es scheint wohl einige Geräte zu geben die nicht willig sind.

Aber welche???

Gruß Sternthaler