HM-CC-TC und HM-CC-VD und HM-SEC-RHS

[martinp876]

Hallo Udo,

der TC meldet zwar die Temperatur-aenderung aber nicht warum.
Es waere also eine Auswertung der trigger-endpunkte notwendig um den Status zu schreiben. Das ist in CUL_HM nicht generell drin - und bedarf auch etwas performance. Daher scheue ich etwas davor. Werde einmal nachdenken....

Wirklich auswerten kann ich es aber nur, wenn immer die peerings korrekt aus den devices gelesen werden. Der Senso sagt nicht, an welchen Channel ersendet, nur welches Device. Nächstes Problem ist, dass ein TC an mehrere RS gepeert sein kann. Gibt in der Summe einen beachtlichen Aufwand.

Mal grübeln....

Gruss
Martin

[betateilchen]

Hallo Martin!

Mach Dir keinen allzu großen Streß wegen dieses Schönheitsfehlers. Die Technik an sich funktioniert ja. Es wäre halt schöner gewesen, anstatt den ??? etwas anderes zu sehen. Ich habe mal mit stateFormat getestet, da kann ich einfach den Status des Sensors in den WIndoRec darstellen, aber es wird nicht aktualisiert.

Schönen Sonntag,
Udo

[martinp876]

Hi Udo

ich habe einmal trigger-Events eingebaut -  Version 3441.

Du kannst die Anleitung lesen und Kommentieren.
Ansatz ist, die Peerliste des Senders herzunehmen und daraus ein Event in den Aktoren zu starten.
Da ein Aktor mehrere Trigger-Quellen haben kann gibt es:
trig_<src>:<value>
trigLast:<chan>

Du solltest beim winRec also auch den Wert des Triggers des RHS sehen.

Wenn du das nach state mappen willst, kannst du trigLast nehmen.
sollte man
trigLast:<chan> <value>

schreiben?

Das klappt alles nicht, wenn die perrlliste in FEHM eingelesen wurde

Gruß
Martin

[betateilchen]

Hallo Martin,

ich habe Deinen Beitrag jetzt mindestens 10 Mal gelesen - aber nichts verstanden. Was soll ich wo eingeben/sehen?

Ok - es war ein anstrengender Tag heute - ich bin müde. Vielleicht wird mir morgen klar, was Du möchtest.

[martinp876]

Hi,
ich dachte, du wolltest im TC WinRec sehen, dass ein RHS ausgelöst hat. Am besten im Status.

So weit ist die Lösung nicht, sollte aber mechanismen liefern, dass es der User schafft.

Der Ansatz ist Generell, also nicht nur für TC-RHS. Kommt ein trigger wird in dem gepeerten Aktoren ein Reading gesetzt.
Da ich aus performancegründen nicht alles durchsuchen will nehme ich die peerlist (genauer attr peerIDs) des Senders um die Aktoren zu finden.

Wenn dein RHS mit TC_Win gepeert ist UND die Daten in FHEM vorliegen (aus getConfig, dann save....) funktioniert es so

RHSx send trigger mit Wert 0|100|200  (=0/50%/100%)=zu/halb/offen
In TC-Win  
 - trig_RHSx:100
 - trigLast:RHSx

Im TC-Win kannst du mit stateFormat dann trigLast anzeigen

Trifft dies in etwa, was du sehen willst?

Gruß Martin

[betateilchen]

Hallo Martin,

also gepeert ist der RHS mit dem WinRec. Verstehe ich das richtig: Ich müsste dann im Event Monitor zwei neue Einträge mit den Triggern sehen, die ich dann auch als Reading im WinRec wiederfinde.

Muss ich heute abend nochmal drauf achten, gestern abend hatte ich jedenfalls nix derartiges festgestellt.

Danke erstmal!
Udo

[martinp876]

korrekt.

Falls mehrere Sensoren an den TC_WIN gepeert sind gibt es einen Eintrag pro Quelle und einen, der die letzte Quelle ausgibt.
Ausserdem wird der 'Wert' mit ausgegeben. Beim RHS ist es einer von 0/100/200, beim mdir ein dimmwert. Bei tastern ein '-', die liefern keinen Wert dazu.

Wenn du wissen willst, ob der TC_WIN aktiv ist, musst du alle 'trig_name' durchsehen. Ich habe keine Ahnung, was passiert, wenn ein TC_WIN mehrere peers hat, diesen auch noch verschiedene temperaturen zugewiesen sind. Raum zum Testen. Bei nur einem RHS ist dies einfach.

Bei bedarf kann ich bei Last auch noch den Wert angeben. Evtl Sinnvoll.

Gruss Martin

[betateilchen]

Ich habe keine neuen Readings im WindowRec. Ist mir langsam aber auch egal.

Code Auswählen Erweitern


2013-07-19 17:30:59 HMLAN HMUSB RCV L:0C N:86 F:A4 CMD:41 SRC:Melder_Balkon DST:127000 0145C8 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:69 NEXT:200) (,CFG,BIDI,RPTEN)
2013-07-19 17:31:00 HMLAN HMUSB SND L:0D N:86 F:80 CMD:02 SRC:127000 DST:Melder_Balkon 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
2013-07-19 17:31:00 CUL_HM Melder_Balkon offen
2013-07-19 17:31:00 CUL_HM Melder_Balkon contact: offen (to HMUSB)
2013-07-19 17:31:01 HMLAN HMUSB RCV L:0C N:87 F:B0 CMD:41 SRC:Melder_Balkon DST:wz_FHT 0145C8 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:69 NEXT:200) (,BURST,BIDI,RPTEN)
2013-07-19 17:31:01 CUL_HM Melder_Balkon offen
2013-07-19 17:31:01 CUL_HM Melder_Balkon contact: offen (to wz_FHT)
2013-07-19 17:31:01 HMLAN HMUSB RCV L:0A N:87 F:80 CMD:02 SRC:wz_FHT DST:Melder_Balkon 00 (ACK) (,RPTEN)
2013-07-19 17:31:02 CUL_HM wz_FHT CommandAccepted: yes


[martinp876]

Hi,

Das Reading kommt, wenn im Melder_Balkon der wz_FHT als peer eingetragen ist, also

attr Melder_Balkon peerIDs 1D919A03

Da sie gepeert sind sollte das Attribut so stehen

Gruss Martin

[betateilchen]

Das ist doch aber schon lange so?

(http://up.picr.de/15233076af.png)

Das einzige Reading im WIndowRec ist die peerList

(http://up.picr.de/15233081kg.png)

[martinp876]

Hi Udo,

bist du auf der neusten SW?

Wenn ich simuliere klappt es.
1) der Aktor-Channel muss im Attr peerIDs eingetragen sein (ist der Fall bei dir)
bei mir:
attr FB2_Btn_01 peerIDs    00000000,172A8503
2) nach dem Trigger (bei mir ein remote-sender) werden folgende Trigger geschrieben:

2013-07-20 14:21:04.794 CUL_HM th_WindowRec trig_FB2_Btn_01: -
2013-07-20 14:21:04.794 CUL_HM th_WindowRec trigLast: FB2_Btn_01

der Level ist bei mir '-' da es ein remote ist - der liefert keinen. Dein RHS sollte hier eine Zahl einstellen.
Somit ergibt sich
Internals:
   DEF        172A8503
   NAME       th_WindowRec
   NR         97
   STATE      trig:FB2_Btn_01
   TYPE       CUL_HM
   chanNo     03
   device     th
   Readings:
     2013-07-20 14:21:04   trigLast        FB2_Btn_01
     2013-07-20 14:21:04   trig_FB2_Btn_01 -


Wie gesagt, dass ist nicht auf den TC beschränkt, das ist generell - alle Sensor/aktor peerings

Kann es sein, dass du nicht die Aktuelle SW hast?

Gruss Martin

[betateilchen]

Martin,

der WIndowRec hat hier NOCH NIE irgendeinen Event ausgelöst. Hast Du das wirklich mit einem TC getestet oder ist auch der WindowRec bei Dir nur ein Dummy?

Ja, ich bin auf dem aktuellen Softwarestand.

Code Auswählen Erweitern

# CUL HomeMatic handler
# $Id: 10_CUL_HM.pm 3452 2013-07-19 09:52:46Z martinp876 $

Viele Grüße
Udo

[martinp876]

Hi Udo,

klar hat das der TC_WindowRec noch nie gemacht. Und macht der jetzt auch nicht. Trigger ist der RHS.
Es funktioniert so:
Sendet ein Device einen Trigger (RHS,Remote,mdir,...) wir in dessen peerListe nachgesehen, wer diese empfangen soll. Jeder potentielle Empfänger bekommt ein Reading, dass ein Trigger an ihn versant wurde.
Steht also beim RHS der TC_WindowRec in der Liste wird dort der Trigger eingetragen.

Es ist also unabhängig vom TC_WindowRec. Der ist komplett passiv.
getestet habe ich mit einer "remote", nicht mit einem RHS. Da wäre schon ein unterschied, da hier eine message mit "parameter" kommt, bei einer remote nicht.

=> Du solltest bei ALLEN aktoren-channels ein entsprechendes "trig..." erhalten, wenn eine remote auslöst.
=> falls es bei allen remote geht, bei RHS aber nicht werde ich es noch einmal untersuchen
=> welche Version von CUL_HM hast du?

Du kannst einmal mit HMinfo nachsehen, ob es irgendwo steht:
set hm param -c trigLast

prüfe bitte noch einmal. Interessant wäre, ob der level korrekt mit kommt.

Zum Verfahren: Ich bin noch an überlegen, es etwas restriktiver zu machen - nur wenn das Device auch in der destination auftaucht... mal sehen.

Gruss Martin

[betateilchen]

=> Du solltest bei ALLEN aktoren-channels ein entsprechendes "trig..." erhalten, wenn eine remote auslöst.

Dann müsste ja auch im Stellantrieb ein trig... auftauchen, da der vom Climate gesteuert wird? Da ist auch nix zu sehen.

=> welche Version von CUL_HM hast du?

hatte ich doch oben schon geschrieben, die Version von gestern.

set hm param -c trigLast

Code Auswählen Erweitern

param done:
 param list


[martinp876]

ok - klar.
das Problem war, dass dein RHS channel UND device in einer entity ist. Hatte ich nicht bedacht, sollte in 3462 gelöst sein.

der trigger wird/kann nicht in climate gemeldet werden, da der RHS mit winrec gepeert wird. Ansonsten könnte ich keine generelle Lösung anbieten.

Gruss Martin