Neues Modul HMCCU für Homematic CCU

[zap]

jetzt zeigt er alle Werte an ...
Aktualisiert werden aber nur die Channels 1
Bei statechannel steht auch nur 1
Wie bekomme ich Channel 1 und 2 hin?

Ändere mal bitte die Definition des Gerätes. Lasse die 1 am Ende weg. Der Statechannel spielt hier keine Rolle.

Achte bitte darauf, dass im HMCCU Device ccudef-readingfiltet = .* ist. Führe dann im HMCCUDEV Device mal den Befehl "get update" aus. Es sollten dann alle Readings angezeigt werden.

[zap]

@Loredo:

Eine Frage zu Deiner Funktion. Wenn man jetzt mal diesen Ausschnitt betrachtet:

Code Auswählen Erweitern


    # eval error parameters
    if ( defined( $p->{UNREACH} ) && $p->{UNREACH} =~ /^(1|true|dead)$/i ) {
        $stateHM = "unreachable";
    }

    # eval operational parameters
    elsif ( defined( $p->{TEMPERATURE} ) || defined( $p->{HUMIDITY} ) ) {
        ...
    }

    # eval warning parameters
   elsif ( defined( $p->{LOW_BAT} )
        && $p->{LOW_BAT} =~ /^(1|true|low)$/i )
    {
        $stateHM = "warn_battery";
    }


Dann wird m.E. ein LOWBAT niemals in stateHM signalisiert, da die operational parameters immer existieren.
Daher war mein Ansatz: Wenn Fehler oder Warnings existieren, setze hmstate auf diese. Wenn nicht, setze hmstate = state. Letzteres hat den Nachteil, dass keine Kombination von Werten möglich ist. Könnte man aber so ändern:

1. Wenn ein Fehler existiert, setze hmstate auf den Fehler (so wie jetzt)
2. Wenn ein Warning existiert, setze hmstate auf das Warning (so wie jetzt)
3. In allen anderen Fällen setze hmstate = STATE. Das kann man dann per stateFormat individuell festlegen.

[fini]

Ändere mal bitte die Definition des Gerätes. Lasse die 1 am Ende weg. Der Statechannel spielt hier keine Rolle.

Achte bitte darauf, dass im HMCCU Device ccudef-readingfiltet = .* ist. Führe dann im HMCCUDEV Device mal den Befehl "get update" aus. Es sollten dann alle Readings angezeigt werden.

habe es noch mal angelegt
define Wetterstation HMCCUDEV NEQ0343659
jetzt erscheinen nur die Channels 1 und werden auch aktualisiert

ccudef-readingfiltet = .*, was bedeutet das?
habe ich eingetragen
jetzt steht unter Attributes zusätzlich:
ccudef-readingfilter .* deleteattr

noch eine Frage, mit deficeinfo kommt:
CHN NEQ0343659:0 Wetterstation:0
  DPT {b} BidCos-RF.NEQ0343659:0.UNREACH = false [RE]
  DPT {b} BidCos-RF.NEQ0343659:0.STICKY_UNREACH = false [RWE]
  DPT {b} BidCos-RF.NEQ0343659:0.CONFIG_PENDING = false [RE]
  DPT {b} BidCos-RF.NEQ0343659:0.LOWBAT = false [RE]
  DPT {n} BidCos-RF.NEQ0343659:0.RSSI_DEVICE = 1 [RE]
  DPT {n} BidCos-RF.NEQ0343659:0.RSSI_PEER = 212 [RE]
  DPT {b} BidCos-RF.NEQ0343659:0.DEVICE_IN_BOOTLOADER = false [RE]
  DPT {b} BidCos-RF.NEQ0343659:0.UPDATE_PENDING = false [RE]
CHN NEQ0343659:1 Wetterstation:1
  DPT {f} BidCos-RF.NEQ0343659:1.TEMPERATURE = -0.700000 [RE]
  DPT {i} BidCos-RF.NEQ0343659:1.HUMIDITY = 99 [RE]
  DPT {b} BidCos-RF.NEQ0343659:1.RAINING = false [RE]
  DPT {f} BidCos-RF.NEQ0343659:1.RAIN_COUNTER = 112.395000 [RE]
  DPT {f} BidCos-RF.NEQ0343659:1.WIND_SPEED = 1.200000 [RE]
  DPT {i} BidCos-RF.NEQ0343659:1.WIND_DIRECTION = 100 [RE]
  DPT {i} BidCos-RF.NEQ0343659:1.WIND_DIRECTION_RANGE = 67 [RE]
  DPT {i} BidCos-RF.NEQ0343659:1.SUNSHINEDURATION = 227 [RE]
  DPT {i} BidCos-RF.NEQ0343659:1.BRIGHTNESS = 0 [RE]
  DPT {f} Luftfeuchte Max Heute = 99.000000 [RWE]
  DPT {f} Luftfeuchte Min Heute = 99.000000 [RWE]
  DPT {f} Temp Max Heute = -0.600000 [RWE]
  DPT {f} Temp Min Heute = -3.400000 [RWE]
  DPT {f} Wind Max Heute = 4.800000 [RWE]
  DPT {f} Wind Max Gestern = 5.400000 [RWE]
  DPT {f} Sonnenminuten Heute = 154.000000 [RWE]
  DPT {f} Sonnenstunden Heute = 2.566667 [RWE]
  DPT {f} Sonnenstunden Gestern = 2.750000 [RWE]
  DPT {f} Temp Max Gestern = 4.000000 [RWE]
  DPT {f} Temp Min Gestern = -3.600000 [RWE]
  DPT {f} Luftfeuchte Max Gestern = 99.000000 [RWE]
  DPT {f} Luftfeuchte Min Gestern = 78.000000 [RWE]
  DPT {f} Helligkeit gefiltert = 0.006399 [RWE]
  DPT {f} Regen heute = 0.000000 [RWE]
  DPT {f} Regen gestern = 0.295000 [RWE]

wie bekomme ich noch Luftfeuchte Max Heute, Luftfeuchte Min Heute u.s.w. angezeigt?

ach so, danke für deine Hilfe!

[zap]

Mach mal bitte folgendes:

attr d_ccu ccudef-readingfilter .*
get Wetterstation update

Welche Readings werden jetzt angezeigt (ggf. Seite im Browser neu laden).

[fini]

Mach mal bitte folgendes:

attr d_ccu ccudef-readingfilter .*
get Wetterstation update

Welche Readings werden jetzt angezeigt (ggf. Seite im Browser neu laden).

hab ich gemacht. sieht jetzt so aus:

[chris1284]

der sensor hat nur folgende datenpunkte
TEMPERATURE float
HUMIDITY intege
RAINING boolean 
RAIN_COUNTER float
WIND_SPEED float
WIND_DIRECTION
WIND_DIRECTION_RANGE
SUNSHINEDURATION integer
BRIGHTNESS integer

Luftfeuchte Max Heute, Luftfeuchte Min Heute u.s.w. angezeigt?

das sind sicher errechnete werte wie beim ks300 in fhem und wären dann durch dich/ddas modul zu erstellen (eigentlich logisch weil der sensor ja für max/min/avg werte in der lage seinmüsste werte zu speichern und damit zu rechnen was er sicher nicht kann)

für die regenwerte kannst du sicher das modul rain nutzen https://fhem.de/commandref.html#rain , so hast du rain tag/stunde/gesamt. sowas bräuchts dann halt auch für hum und temp

sind denn die max/min/avg in der ccu zu sehen?

[Loredo]

Wenn man jetzt mal diesen Ausschnitt betrachtet:
[...]
Dann wird m.E. ein LOWBAT niemals in stateHM signalisiert, da die operational parameters immer existieren.

Das ist für LOWBAT auch gewollt so. LOWBAT ist nichts, was mich daran hindert das Gerät weiterhin zu bedienen. Es ist lediglich ein/e Warnung/Hinweis, der aber für die Bedienung keine Rolle spielt. Eine Benachrichtigung, dass eine Batterie schwächer wird, muss separat gehandhabt werden. Nur unmittelbare Fehler, die mich tatsächlich daran hintern ein Gerät zu bedienen, sollen höher priorisiert sein (UNREACH=1, ERROR>1, einige von FAULT*).

Wie gesagt mein Ziel ist es den Bedienstatus in einem kummulierten Reading logisch zusammenzufassen. Es eignet sich nicht nur für devStateIcon, aber wenn dir das hilft, denk dabei an devStateIcon. Wenn die Batterie schwach ist, muss natürlich noch immer ein Icon angezeigt werden, welches eine Aktion auslöst. Wenn ich aber nur weiß, dass die Batterie schwach ist, kenne ich den aktuellen Zustand des Gerätes nicht mehr und kann weder eine sinnvolle Aktion hinterlegen noch ein Icon richtig darstellen.

Letzteres hat den Nachteil, dass keine Kombination von Werten möglich ist.

Es geht ja nicht nur darum Werte zu kombinieren oder umzubenennen. Es geht auch darum aktuelle Werte 1-zu-1 durchzureichen, wenn die Reihenfolge entsprechend gewählt ist. Also z.B. LEVEL. Wenn der Rollladen aber gerade bedient wird und hoch oder runter fährt oder eine Leuchte gerade dimmt, dann ist DIRECTION wichtiger angezeigt zu werden (oder hilfweise WORKING, wenn es kein DIRECTION gibt). Genau das bildet meine Funktion ab.
Da du ja auch Rollladen Aktoren hast, hier einmal ein Beispiel, was du auch bei dir ausprobieren kannst, um es besser zu verstehen (mein Aktor ist kopfüber eingebaut, daher entspricht 100=offen und 0=zu):

Code Auswählen Erweitern


defmod LR_ShutterSouth HMCCUCHN JEQ0109322:1
attr LR_ShutterSouth userattr g_shutters g_shutters_map structexclude
attr LR_ShutterSouth IODev CCU2
attr LR_ShutterSouth alias Rollladen Süd
attr LR_ShutterSouth ccuscaleval LEVEL:0:1:0:100
attr LR_ShutterSouth cmdIcon up:control_arrow_upward stop:time_manual_mode down:control_arrow_downward
attr LR_ShutterSouth devStateIcon 100|off:fts_window_2w:level%2055 0|on:fts_shutter_100@green:level%2055 1[0-9].*:fts_shutter_90@orange:level 2[0-9].*:fts_shutter_80@orange:level 3[0-9].*:fts_shutter_70@orange:level 4[0-9].*:fts_shutter_60@orange:level 5[0-9].*:fts_shutter_50@orange:level 6[0-9].*:fts_shutter_40@orange:level 7[0-9].*:fts_shutter_30@orange:level 8[0-9].*:fts_shutter_20@orange:level 9[0-9].*:fts_shutter_10@orange:level [1-9].*:fts_shutter_0@orange:level out|down|closing:control_arrow_downward@orange:stop in|up|opening:control_arrow_upward@orange:stop OK|ok|Ok:general_ok@green:stop unreachable:light_question err.*:light_exclamation
attr LR_ShutterSouth event-on-change-reading .*
attr LR_ShutterSouth event-on-update-reading level,pct,Activity
attr LR_ShutterSouth eventMap /datapoint STOP 1:stop/datapoint LEVEL:level/datapoint LEVEL:pct/datapoint LEVEL 100:off/datapoint LEVEL 100:in/datapoint LEVEL 100:open/datapoint LEVEL 100:up/datapoint LEVEL 0:on/datapoint LEVEL 0:out/datapoint LEVEL 0:close/datapoint LEVEL 0:down/
attr LR_ShutterSouth g_shutters g_HSE_Shutters
attr LR_ShutterSouth g_shutters_map pct:0:closed pct:100:open pct:\b[1-9]\b:halfopen pct:\b[1-9][0-9]\b:halfopen
attr LR_ShutterSouth genericDeviceType blind
attr LR_ShutterSouth group Fenster & Türen
attr LR_ShutterSouth icon fts_shutter
attr LR_ShutterSouth powerMap {\
  'stateHM' => {\
                 '*' => '0.5',\
                 'down' => 121,\
                 'unreachable' => 0,\
                 'up' => 121,\
               }\
}
attr LR_ShutterSouth room HMCCU,Homekit,Wohnzimmer
attr LR_ShutterSouth siriName Living Room Blind
attr LR_ShutterSouth sortby 2
attr LR_ShutterSouth stateFormat stateHM
attr LR_ShutterSouth structexclude g_LR_Shutters:devStateIcon|webCmd|group|structexclude|icon
attr LR_ShutterSouth userReadings stateHM:^(?!stateHM).* { return myHMCCUstate($name,1);; }
attr LR_ShutterSouth verbose 3
attr LR_ShutterSouth webCmd pct:up:stop:down
attr LR_ShutterSouth widgetOverride control:slider,0,5,100 pct:slider,0,5,100 level:slider,0,5,100


Ich habe noch ein paar Screenshots angehängt.

Könnte man aber so ändern:

1. Wenn ein Fehler existiert, setze hmstate auf den Fehler (so wie jetzt)
2. Wenn ein Warning existiert, setze hmstate auf das Warning (so wie jetzt)
3. In allen anderen Fällen setze hmstate = STATE. Das kann man dann per stateFormat individuell festlegen.

1. ok.
2. ist genau nicht gewollt.
3. Das würde vermutlich zu einer Schleife führen. Es genügt auch nicht, weil die Prioritäten abhängig vom Betriebsstatus sowie vom Vorhandensein eines Datenpunktes abhängt (letzteres weil man das ja vornehmlich gerne zentral pflegen will und pro Device nur in Ausnahmefällen). Eigentlich hatte ich ja deshalb schon einen Vorschlag gemacht, wie ccudef-hmstatevals aussehen könnte. Das müsste doch nur von links nach rechts abgearbeitet werden so wie alle anderen Attribute auch. Auch die Sache mit dem + hast du schon, es müsste dabei eben nur alles bisherige mit ".=" angeknüpft werden. Es fehlen dann nur noch Platzhalter um zu signalisieren, dass ein Value 1-zu-1 durchgereicht werden soll und optional mit Text drum herum. Es ist doch wirklich schon fast alles da an Logik aus den anderen Attributen.

[fini]

der sensor hat nur folgende datenpunkte
TEMPERATURE float
HUMIDITY intege
RAINING boolean 
RAIN_COUNTER float
WIND_SPEED float
WIND_DIRECTION
WIND_DIRECTION_RANGE
SUNSHINEDURATION integer
BRIGHTNESS integer
das sind sicher errechnete werte wie beim ks300 in fhem und wären dann durch dich/ddas modul zu erstellen (eigentlich logisch weil der sensor ja für max/min/avg werte in der lage seinmüsste werte zu speichern und damit zu rechnen was er sicher nicht kann)

für die regenwerte kannst du sicher das modul rain nutzen https://fhem.de/commandref.html#rain , so hast du rain tag/stunde/gesamt. sowas bräuchts dann halt auch für hum und temp

sind denn die max/min/avg in der ccu zu sehen?

das sind Systemvariablen die mit einen  Programm berechnet werden.
Ja, die Werte sind in der CCU zu sehen.

----------------------------------------------------------------------------
Habe die Werte jetzt mit get d_ccu vars hinbekommen

Jetzt bleibt noch, wie bekomme ich die Werte der Readings in die TabletUI?

[chris1284]

Jetzt bleibt noch, wie bekomme ich die Werte der Readings in die TabletUI?

na einbauen wie alle anderen readings, per label zum beispiel (

<div data-type="label" data-device="d_ccu" data-get="Luftfeuchte Max Gestern" data-unit=" %" ></div>

)eigentlich sollten die widget mit den leerzeichen im readingsnamen klar kommen, wenn nicht musst du diese variablen halt per userreadings (am besten im wettermast device) vernünftig anlegen oder in der ccu vernünftig benamen

[zap]

Einfach  mal die Doku lesen von Tablet UI könnte auch hilfreich sein. 

[fini]

moin,

hab noch ein Problem, seit den anlegen der Systemvariablen mit get d_ccu vars werden diese unter Readings  angezeigt, aber nicht aktualisiert.
get update habe ich schon gemacht ...

[chris1284]

ich denke du musst diese regelmäßig abholen (get d_ccu vars in ein at das alle 5 minuten läuft oder ein notify auf eine aktualisierung des wettermast-device in fhem welches dann get d_ccu vars ausführt und die aktuellen werte holt).

alternativ das program auf der ccu nach dem es die werte neu berechnet hat sagen es soll die werte in fhem setzen( per telnet oder url zB) wenn die ccu sowas kann

[fini]

ich denke du musst diese regelmäßig abholen (get d_ccu vars in ein at das alle 5 minuten läuft oder ein notify auf eine aktualisierung des wettermast-device in fhem welches dann get d_ccu vars ausführt

kannst du mir erklären, wie man dat genau macht?
danke für die Hilfe!

Fini

[Yil]

hi zap,

zwei HM-LC-Sw1PBU-FM (Unterputz Schaltaktoren) melden mir seit kurzem im reading 0.LOWBAT den Wert 1, den ich üblicherweise (bei Batterie betriebenen Homematic Komponenten) mit on interpretiere. Müsste ich das hier anders auslesen/intrepretieren (per subsitutue), oder kannst Du das beheben?

VG Yil

Darf ich da nochmal nachfragen. Problem ist, dass der Wert 1 ein Notify zur Batteriewarnung auslöst - da diese Komponenten keine Batterie haben, stimmt das natürlich nicht.

VG Yil

[zap]

moin,

hab noch ein Problem, seit den anlegen der Systemvariablen mit get d_ccu vars werden diese unter Readings  angezeigt, aber nicht aktualisiert.
get update habe ich schon gemacht ...

Die RPC Schnittstelle der CCU aktualisiert keine Systemvariablen. Am einfachsten in FHEM ein AT Device anlegen und get vars ausführen lassen