stateRegex: wie manche Werte ignorieren

Begonnen von JoeALLb, 16 Januar 2018, 16:01:52

Vorheriges Thema - Nächstes Thema

JoeALLb

Hallo,
ich würde gerne gewisse Readings mit stateRegex ignorieren. Wenn die gemeinten Readings im Regex jedoch nicht getroffen werden, bekomme ich das ganze Reading im STATE
angezeigt. Gibt es dafür eine spezielle Schreibweise?
Die commandref bringt mich leider auch auf keine Idee...
Eine Ersetzung mit nichts also /.*// aktualisiert leider den state auf "", anstatt ihn einfach unverändert zu lassen. Bekomme ich hier irgend etwas wie "undev" hin?

sG
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Andi291

Poste bitte mal ein konkretes Beispiel - habe eine vage Idee.

docm

Ich glaube nicht, dass stateRegex das rchtige Werkzeug ist. Aber wie so oft gibt es ja in FHEM verschiedene Möglichkeiten.
Ich verwende am liebsten stateFormat.

Beispiel: Meine Heizkörpersteuerung kriegt folgendes Attribut

attr Wohnen.Heizung stateFormat {\
  "&nbsp ".ReadingsVal($name,"temp.soll-set","???")."&nbsp  >> &nbsp".ReadingsVal($name,"temp.ist-get","???");;\
}

und zeigt dann in etwa so etwas an: 21.50 °C >> 21.20°C

Die Variable $name enthält den Namen des aktuellen Devices, also hier Wohnen.Heizung.

Ungewollte Ereignisse lassen sich ansonsten auch mit eventOnUpdate ausblenden.

Viele Grüße
Andreas

JoeALLb

Zitat von: Andi291 am 16 Januar 2018, 19:23:22
Poste bitte mal ein konkretes Beispiel - habe eine vage Idee.

Anbei so ein Beispiel:
Damit kann ich alle Heizventile öffnen und schließen (über 5/3/0).
Nach erfolgreicher Schließung sendet der Heizungsaktor jedoch über 5/3/1 eine Heizungsanforderung (true oder false).
Diese würde ich im Status gerne ignorieren un dnur als Reading anzeigen.
mit stateCmd bekomme ich das schon hin, stateRegex wäre mir halt lieber gewesen, weshalb ich fragen wollte,
ob es dafür auch eine Lösung gibt.

defmod HeizungMaster2 KNX 5/3/0:dpt1.003:Status 5/3/1:dpt1.002:Heizungsanforderung
attr HeizungMaster2 devStateIcon closed:sani_heating_timer@grey auto:sani_heating_automatic@green
attr HeizungMaster2 eventMap /off:acutator-mode auto/\
on:acutator-mode closed/\
on:Ein/\
off:Aus/\

attr HeizungMaster2 stateRegex /status-set:enable/closed/ /status-set:disable/auto/ /.*//
attr HeizungMaster2 userReadings acutator-mode:status-set.* {   \
  my $reading = ReadingsVal($name,"status-set",undef);;\
  if ($reading =~ /enable/)\
    {\
      return "closed";;\
    }\
  else\
    {  \
     return "auto";;\
    }\
}
attr HeizungMaster2 webCmd acutator-mode
attr HeizungMaster2 widgetOverride devStateIcon:textField-long\
stateCmd:textField-long\
stateRegex:textField-long\
zComment:textField-long\
eventMap:textField-long\
widgetOverride:textField-long\
acutator-mode:uzsuToggle,auto,closed

setstate HeizungMaster2 auto


FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

JoeALLb

Zitat von: docm am 16 Januar 2018, 19:34:26
Ich verwende am liebsten stateFormat.

Ich hatte bisher mehr mit stateCmd gemacht. In der Commandref ist zwar ein Unterschied beschrieben, ich habe jedoch für mich noch keine festlegung,
wann das eine und wann das andere sinnvoller ist...
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Andi291

OK, jetzt hab ich es verstanden.

Mit StateRegex führt da kein Weg hin.
Ich hatte seinerzeit das gleiche Problem. Dafür habe ich StateCmd eingeführt.

Konkret:
attr HeizungMaster2 stateCmd {$state = sprintf("%s", ReadingsVal(HeizungMaster2,"status-get","undef"))}

Kommst Du damit klar?


docm

Oder das gleiche als stateFormat


attr HeizungMaster2 stateFormat {sprintf("%s", ReadingsVal(HeizungMaster2,"status-get","undef"))}


Der wesentliche Unterschied: stateFormat verändert nur das Internal STATE, was z.B. in der Weboberfläche angezeigt wird.
stateCmd verändert zusätzlich das Reading state.

Auf das sprintf kann auch getrost verzichtet werden. Und für das aktuelle Device nimm besser die Variable $name. Dann funktioniert es immer noch, wenn man später mal das Device umbenennt oder eine Kopie mit anderem Namen erzeugt.


attr HeizungMaster2 stateFormat {ReadingsVal($name,"status-get","undef")}


Viele Grüße
Andreas

JoeALLb

Danke euch beiden!!!
stateRegex war mir einfach sympatischer (und auf meinem kleinen rpi1 gefühlt performanter)... aber das andere funktioniert natürlich!!
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270