HM-CC-RT-DN und peering

Begonnen von bugster_de, 05 Februar 2017, 18:56:24

Vorheriges Thema - Nächstes Thema

bugster_de

Hi,

nach etwas gefummele ist mein neuer HM-CC-RT-DN (Thermostat) nun mit der HM-LGW-O-TW-W-EU gepaired. Ich kann über den Channel 04 die Solltemp, die Istz-Temp, die Motorstellung Wochenprogramme etc. alles machen. Channel 01 liefert mir den Ist-Wert. Also alles gut soweit.

Nun wollte ich die Channels aber peeren und das geht nicht. Ich lege wie beschrieben einen virtuelles HM_Device mit einem Channel an und machen dann an diesem Channel das peering
set HM_VIRT_BTN01 peerChan 0 HM_450197_remote single set

Und nun passiert folgendes
- am virtuellen Button sehe ich die PeerID des remote channels --> richtig
- der Remote Channel sagt mir aber weiterhin unpeered. Das attribut peerIDs steht auch auf 00000000 --> falsch (?)
  wenn ich nun am virtuellen Button auf shortPress drücke passiert nichts (ausser dass sich der State des virtuellen BTNs ändert)
- wenn ich nun am Weather Channel die 8-stellige HM-ID des virtuellen Buttons in das Attribut peerIDs manuell eintrage und dann am virtuellen Sensor dann auf shortPress drücke, dann hat das Thermometer Device sogar auf einmal 1 CMD Pending. Dieser CMD geht aber nie raus und blockiert mir nu alles

Ich blicks nicht. Ist meine Denkweise falsch?

Zielsetzung: ich würde gerne im FHEMWeb eine brauchbare Oberfläche zur Bedienung des Thermostaten machen und ausserdem das bereits bestehende Wandthermometer (nicht HM) als virtuellen Sensor einfügen wollen.

Danke für eure Hilfe !

vbs

Probier mal ein getConfig auf den RT zu machen. Danach sollten dann die Register gefüllt sein.

bugster_de

#2
EDIT
zu früh gefreut. Das Peering klappt nun beim Remote Channel aber nicht bei Weather Channel. Sobald ich beim Weather Channel peere oder unpeere schickt er zwar am Device die CMDs los, aber dann geht er auf MISSING ACK.
Wenn ich damm am Weather Channel mal das Attribut peerIDs lösche und nochmal getconfig mache, ist das Attribut inkl. dem vorhin nicht erfolgreichen Peering-Channel wieder da?! Das heiß er saugt sich das irgendwo doch aus den Registern?

Die exackt gleiche Prozedur am remote Channel klappt ohne Probleme



D A N K E !!!

Das wars gewesen :-)

vbs

Au weia :) Ich weiß nicht, was passiert wenn man händisch in diese Peer-Readings rein greift, die normalerweise von FHEM verwaltet werden. Ich würde nicht ausschließen, dass man da auch mal etwas kaputt macht.

Folgende Ideen hätte ich noch:
- im Zweifel das/die Geräte in FHEM löschen neu PAIREN
- benutze HMINfo um einen configCheck zu machen. Das sollten dann keine Fehler/Inkonsistenzen angezeigt werden.

bugster_de

Hi,

Danke. Ich habe die Geräte bereits mehrfach in Werksreset und neu gepairt. Zeigt keinen Unterschied.

Das HM_Info Device bei getConfig zeigt mir nur folgendes:
peer list incomplete. Use getConfig to read it.
    incomplete: HM_450197_Climate:

peer not verified. Check that peer is set on both sides
    THERM_BZ_Weather p:virtual_Temp_Sens


Spannend ist das deshalb, da HM_450197 der Name des devices im Autocreate war, bevor ich es nach THERM_BZ umbenannt habe.

vbs

Zitat von: bugster_de am 05 Februar 2017, 18:56:24
- wenn ich nun am Weather Channel die 8-stellige HM-ID des virtuellen Buttons in das Attribut peerIDs manuell eintrage und dann am virtuellen Sensor dann auf shortPress drücke, dann hat das Thermometer Device sogar auf einmal 1 CMD Pending. Dieser CMD geht aber nie raus und blockiert mir nu alles
Also "CMD Pending" blockiert eigentlich nichts im System. Das heißt nur, dass ein Kommando noch zum Versenden bereit gehalten wird. Das wird versendet, sobald das Gerät sich das nächste Mal meldet.

Zitat von: bugster_de
HM_450197_Climate
Aber das Gerät muss es dann offenbar noch geben oder? Gib mal "list" ein und gucke mal, ob da noch ein paar alte Geräte rumflitzen.

Ich würde mal auf den RT ein "set clear" aufrufen und dann nochmal getConfig. Dann guck mal, ob im Remote-Kanal des RT das Peering korrekt eingetragen ist, oder nicht.

bugster_de

Hi,

ja hab die Teile gefunden. Waren noch da und gehörten auch zum device.

Im remote Channel kann ich alles machen so wie es sein soll: ich kanne peeren, unpeeren, die Register ändern etc. Und nun habe ich bei ShortPress dort die Funktion "Auto" und bei LonPress die Funktion "Solltemp = 17". Alles so wie es sein soll.

Wenn ich aber am Climate Channel mal get reg all mache, dann kriege ich nur:
THERM_BZ_Weather type:thermostat -
list:peer register         :value
   1:      sign             :off


Mittels regSet sign kann ich zwar auch zwischen on / off umschalten aber mehr nicht.
Da müssten doch mehr Register sein, oder?

vbs

Nee das ist normal. Die einzige Aufgabe des Weather-Kanals ist meines Wissens die Ist-Temperatur eines externen Sensors zu empfangen. Find ich daher plausibel, dass es da nur das sign-Register gibt.

Wenn du "get THERM_BZ_Weather getList" machst, dann siehst du alle Register, die FHEM zu dem Device kennt. Außerdem würdest du es in HMInfo's configCheck sehen, wenn FHEM Register-Daten zu einem Device fehlen.

bugster_de

#8
EDIT:
ZitatWenn du "get THERM_BZ_Weather getList" machst, dann siehst du alle Register, die FHEM zu dem Device kennt.

get THERM_BZ_Weather getList
er sagt mir dann:
Unknown argument getList, choose one of cmdList param reg regList regTable regVal saveConfig



Das mit dem Weather Channel ist eh nicht so wichtig; kann ich mich mal irgendwann drum kümmern. Wichtiger war mir der remote Channel, so dass ich mit einem einfachen Kommando die Modi "abwesend" und "Anwesend" als Regelstrategie im Gerät schalten kann und das geht ja jetzt.

Danke !

vbs


bugster_de

auf die regList Abfrage kommt das hier:
list:         register | range              | peer     | description
1: sign             |     literal        |          | signature (AES) options:off,on


liest sich für mich so, als ob er nur ein Register hat, mit dem man AES ein bzw. ausschalten kann. Würde natürlich erklären warum man da keinen virtuellen Tempsensor drauf peeren kann. Ich frage mich aber, ob da nicht mehr Register sein müssten?

vbs

Doch klar kann man da einen (virtuellen) Sensor peeren. Genau das ist ja der (einzige?) Sinn des Kanals ;)
Zitat von: vbs am 05 Februar 2017, 23:02:51
Nee das ist normal. Die einzige Aufgabe des Weather-Kanals ist meines Wissens die Ist-Temperatur eines externen Sensors zu empfangen. Find ich daher plausibel, dass es da nur das sign-Register gibt.

Ich glaube da FHEM einfach, dass es nicht noch andere Register gibt. Warum meinst du, dass es mehr geben müsste?

bugster_de

ZitatWarum meinst du, dass es mehr geben müsste?
Nimm mal meine folgende Antwort nicht so ernst; ich bin mir immer noch nicht sicher, dass ich Homematic wirklich verstanden habe.

Mein bisheriges Verständiss:
ein HM Kanal hat verschiedene Register (also quasi Variablen im HM Gerät). Auf jede dieser Register kann ich lesend zugreifen, um raus zu finden, was da so drin steht. Manche Register muß ich einmalig beschreiben um eine Konfiguration abzulegen (z.B. bei den Rolladen-Aktoren das driveTurn Register).
Und andere Register möchte ich quasi permamnent mit neuen Daten versorgen oder den aktuellen Inhalt auslesen. Dazu hat FHEM (auch) das peering, damit zwei Kanaäle von unterschiedlichen Devices auch ohne Zentrale kommunizieren können.
Und genau dieses Setup mache ich mir doch beim Weather-Channel zu Nutze: ein Device stellt die aktuelle Temp. bereit (in meinem Fall ein virtuelle HM  Sensor) und übermittelt ihn dann an seine gepeerten Register (in diesem Fall der Heizkörper Thermostat). Sprich der Sensor schreibt seine aktuelle Temperatur in den Heizkörper Thermostat
Wenn dem so ist, dann hätte ich jetzt erwartet, dass ich im Weather Channel auch ein Register sehe, auf welches der Temperaturwert geschrieben wird.

Ich habe mal spasseshalber ein paar andere HM Geräte mit regList und get reg all ausgelesen (Rolladenaktoren). Bei Devices die nicht gepeert sind sehe ich alle möglichen Register (also entsprechend meiner Theorie). Der Eintrag in der Spalte peer ist leer. Bei Devices bei denen ich was gepeert habe sehe ich die gleichen Register und in der Spalte peer steht die entsprechende 8-stellige des Nummer Gegen-Peer drin. Ich dachte bisher auch, dass ich genau daran erkennen kann, ob das peering oder auch unpeering erfolgreich war.

Oder habe ich was grundsätzlich falsch verstanden?

vbs

Da liegst du eigentlich ziemlich richtig, denk ich. Aber an einer Stelle hast du einen Fehler, der auch deine Frage erklärt: Register sind _nur_ dafür da,  _Konfigurationsparameter_ abzulegen. Diese Register liegen im Flash-Speicher der Geräte. Dort werden nie volatile Werte wie Ist- oder Soll-Temperatur abgelegt. Diese werden nur im RAM der Geräte gehalten. Darum wirst du solche Werte nie in Registern finden.
An dem Wetter-Kanal gibt es nur eine Sache zu konfigurieren: Verschlüsselung per AES (sign). Darum gibts da auch nur das eine Register.