HMCCU 5.0 Beta verfügbar

[zap]

Ein weiteres Update:

Die Definition von HMCCUCHN Devices ist nun komfortabler. Man definiert wie gehabt das Device, z.B. einen Wandthermostaten (in Kanal 2 liegen die Datenpunkte für die Steuerung): Hier hat der Kanal 2 in der CCU den Namen Thermostat-2

define myTH HMCCUCHN Thermostat-2

Schon bei der Definition werden die Readings aktualisiert. Danach führt man einmal "set defaults" aus:

set myTH defaults

Anhand der Kanalrolle setzt HMCCUCHN nun alle notwendigen Attribute und definiert Buttons, Slider etc.

Der 2. Schritt wird demnächst überflüssig.

[martinp876]

mein Fehler - ich habe ein paar Zeilen eingebaut (nicht problematisch!) Das erzeugt die Verschiebung.
Hier die Referenz:

Code Auswählen Erweitern

foreach my $c (keys %{$objects->{$a}}) {
next if (($clType eq 'HMCCUCHN' && "$c" ne "$chnNo" && "$c" ne "0" && "$c" ne "d"));

my $chnAddr = "$a:$c";
my $devDesc = HMCCU_GetDeviceDesc ($ioHash, $chnAddr, $clHash->{ccuif});
my $chnType = defined($devDesc) ? $devDesc->{TYPE} : HMCCU_GetChannelRole ($clHash, $c);

# Loop over all parameter sets
foreach my $ps (keys %{$objects->{$a}{$c}}) {
# Loop over all parameters
                next;        ##<<< Eigeneinbau - bricht ab damit das System bootet
foreach my $p (keys %{$objects->{$a}{$c}{$ps}}) {##<<< Zeile 4498!!!!
my $v = $objects->{$a}{$c}{$ps}{$p};

02.21: 21.februar

Ich gehe davon aus, dass ein Link ohne Parameter auch kein Parameterset LINK besitzt.

klar. Ich wollte sagen, es gibt Links(peers) ohne Parameter-sätze.

Die Parameter selbst werden tatsächlich noch nicht auf Gültigkeit geprüft.

Ist ja auch nicht das Erste - wird aber sicher noch kommen

HMCCU >istMasterFür> HMCCURPCPROC >IstMasterFür> HMCCUDEV >IstMasterFür> HMCCUCHN

ein(nicht mein) Ansatz.

HMCCU ist der zentrale Vermittler, der alle Interfaces kennt.

Das ist nur ein Teil seiner Aufgaben.

HMCCU hat einige Aufgaben. Somit ist die HMCCU ggf nur Cache.
1) RPC-PROC ist ein Interface zur HMCCU. Mehr nicht - sollte man bestmöglich verbergen.
2) HMCCU ist ein IO für die Devices. (channel/device bitte definieren)
==> ab hier könnte man sich entkopplen - oder auch nicht.
3) HMCCU stellt Variablen und Scripten zu verfügung. Das ist ein ganz anderer Level. Diesen würde ich in jeden Fall einer eigenen Intanz zuordnen. Einer Instanzgruppe
3a) sollten Scripten/Variablen der CCU verwaltet werden
3b) falls dem so ist müssen Querverbindungen dargestellt werden
3c) unklar, welchen Level der Scripten man darstellen will/kann. Hier kenne ich mic nicht aus.
=> in jedem Fall ist das eine eigene Gruppe von Entities.

[martinp876]

Ein weiteres Update:

hört sich gut an - super-cool sogar. Allerdings kann ich nicht testen da mein System abstürzt an der betreffenden Zeile.

[zap]

mein Fehler - ich habe ein paar Zeilen eingebaut (nicht problematisch!) Das erzeugt die Verschiebung.
Hier die Referenz:

Code Auswählen Erweitern

foreach my $c (keys %{$objects->{$a}}) {
next if (($clType eq 'HMCCUCHN' && "$c" ne "$chnNo" && "$c" ne "0" && "$c" ne "d"));

my $chnAddr = "$a:$c";
my $devDesc = HMCCU_GetDeviceDesc ($ioHash, $chnAddr, $clHash->{ccuif});
my $chnType = defined($devDesc) ? $devDesc->{TYPE} : HMCCU_GetChannelRole ($clHash, $c);

# Loop over all parameter sets
foreach my $ps (keys %{$objects->{$a}{$c}}) {
# Loop over all parameters
                next;        ##<<< Eigeneinbau - bricht ab damit das System bootet
foreach my $p (keys %{$objects->{$a}{$c}{$ps}}) {##<<< Zeile 4498!!!!
my $v = $objects->{$a}{$c}{$ps}{$p};


Mein liebster Perl-Fehler. Wann tritt der Fehler auf? Nach dem Start der RPC Server? Wenn ja, dann vermutlich bei der Aktualisierung aller Devices. Das kannst Du verhindern, indem Du im I/O Device im Attribut ccuflags das Flag noInitialUpdate setzen.

Kannst Du bitte Deinen Eigenbau durch folgende Zeilen ersetzen:

Code Auswählen Erweitern


if (ref($objects->{$a}{$c}{$ps}) ne 'HASH') {
   HMCCU_Log ($clHash, 2, "a=$a, c=$c, ps=$ps");
}
next;


Zur Erklärung: Diese Funktion aktualisiert Readings. Der Hash $objects enthält die zu aktualisierenden Werte:

$objects->{deviceAdresse}{Kanalnummer}{ParameterSet}{ParameterName} = Wert

Falls der Code oben keinen Hinweis auf die Ursache liefert, hilft nur Data::Dumper.

[martinp876]

Werde ich machen. Geloggt hatte ich schon vor 2 Wochen. Die grundsätzliche funktion ist sowieso klar

Der workaround hört sich mies an. Die datenstruktur ist korrupt. Fragt fich ob ich alte daten habe bzw diese beim aufstarten nicht korrekt in object abgebildet werden,....
Eigentlich speichert fhem alle readings in readings. Du hast hier wieder einmal einen eigenen Mechanismus.... Eine eigene welt neben fhem.... Hm... Aber das ist wohl deine komplette struktur.

Faktisch hat die ebene ps gefehlt. Das reading war bereits in ps anstelle von p. Die ps ebene fehlt komplett bei mir

[zap]

Ich habe nochmal ein Update eingestellt. Bitte stelle sicher, dass Du alle 4 Module aktualisierst und FHEM neu startest.

In der problematischen Funktion wird nun ein Stacktrace mitgeloggt, falls eine Ebene im Hash fehlt. Dann kann ich sehen, in welcher Funktion die Datenstruktur falsch zusammengebaut wird.

Wenn bei Dir die Paramset Ebene komplett fehlt, vermute ich, Du benutzt bei einem der Module eine alte Version.

[martinp876]

Ich kopiere nach so einem Update immer alle deine files in das System und mache einen reboot. Alles andere wäre nicht reproduzierbar.

Jetzt jendenfalls klappt es. 

Mal sehen
1) get config
  a) alle peers scheinen vorhanden - ok
      - peerNamen  sind noch nicht enthalten - es sind die Adressen.
  b) Reihenfolge: Master würde ich zuerst ausgeben (bessere Lesbarkeit)
  c) eine Liste der Peers sollte vor den Links stehen (Lesbarkeit)
  d) optional: eine andere Darstellungsform wäre eine Tabelle in der die Links in Spalten ausgegeben werden, Register in Zeilen. Geschmackssache!( mein klarer Favorit)
2) get datapoint
  - wenn kein Datenpunkt vorhanden ist sollte das Kommando nicht verfügbar sein.
  - alles prima!
3) get defaults
  - mir noch unklar, was hier bestehen bleiben wird.
4) deviceDesc
  a) Namen: es ist die Entity description. Device ist ... eben der device-level
  b) Namen... fehlen. Das JEQ0116737:1 ist bei mir ein HMc_raEss_1. Ich denke der 1. Eintrag sollte der Namen sein?
      Channel JEQ0116737:1 HM-LC-Bl1PBU-FM JEQ0116737:1 [BLIND]
  c) Unnötige Einträge sollten unterdrückt werden. Parent wird genau in dieser Maske ausgegeen - und in der Überschrift...
     - PARENT: JEQ0116737
     - PARENT_TYPE: HM-LC-Bl1PBU-FM
     - Devicetyp im channel ist sowieso im Device enthalten
    => einfach einmal ansehen, was schlicht klar oder doppelt (3-fach,...) ist
    => make the information smart - es sind immer die gleichen Einträge, also nicht device/channel individuell
5) deviceInfo
  a) wie überall auch hier channel 0 - nicht notwendig (unser streitpunkt)
  b) in jeder Zeile steht "BidCos-RF.JEQ0116737". Das kann man weglassen, steht schon in der Überschrift
  c) hier werden noch alle Kanäle angezeigt
6) paramsetDesc
  a) es sollte ein Trenner vorhanden sein, damit man diese Liste nach Excel kopieren kann. Space ist schon einmal drin. Aber das kommt auch in den Literals vor. Schwierig... Evlt mit Tab als trenner arbeiten
    die Liste ist so schwer handelbar... wenn man sich eine Übersicht bauen will.
  b) DFLT ist nicht bei Liternals als Nummer nicht lesebar - keiner weiss was "8" ist. Ist DFLT dann sinnvoll?
  c) UNIT ist nicht immer vorhanden. Schlecht für die Erstellung einer Tabelle.

Die Set kommandos sehen schon gut aus. Allerdings verstehe ich noch nicht alle, muss ich mir einmal zeit nehmen.
Bei 'pct' sollte immer einen Slider haben. Es ist notwendig auch ein Reading "pct" zu erstellen (auch wenn dopplet) - das braucht FHEM um den Slider zu 'Füllen'

Schon einmal super!!

[martinp876]

Habe mal in die Attribute geschaut. Flag showlinkreadings passt vom namen nicht.
Klare wortwahl konsequent durchziehen so lange du noch kannst.
Das schow sind sicher register oder config. Also immer wenn du config meinst schreibe config. Oder register - geht m.e. synonym. Register ist ein oder mehrere werte. Config ist die Gesamtzeit der register ( mein Vorschlag)
Readings.... Nicht mit values verwechsel. Datapoint sind die Zustands werte welche du über values erhältst...!?
Masterreadings geht also nicht. Könnten alle values der masterebene sein.

Ziel sollte es sein: hat man die semantik der Begriffe erfasst kann man den befehl oder das attribut ohne docu nutze  und deuten. Selbst nach dem lesen ist es schnell vergessen.
Ist kleinkarriert. Aber die schlamperei zu beginn ist extrem schwer nach einführung auszubügeln. Es lohnt sich.

[martinp876]

Ich fange einmal an, mit einem RT-IP operational zu werden.

get deviceDesc ist m.E. zu ausgibig. Schon durch die Anzahl der Kanäle wird das Fenster zu breit und unbedienbar. dabei ist die Info auch noch redundant (und sowieso ständig in den Internals.
Also mein Vorschlag
Device 000A18A996E9DA HmIP-eTRV-2 000A18A996E9DA [HmIP-eTRV-2]
  AES_ACTIVE: 1
  AVAILABLE_FIRMWARE: 0.0.0
CHILDREN: 000A18A996E9DA:0,000A18A996E9DA:1,000A18A996E9DA:2,000A18A996E9DA:3,000A18A996E9DA:4,000A18A996E9DA:5,000A18A996E9DA:6,000A18A996E9DA:7
  CHILDREN: 000A18A996E9DA:0,:1,:2,:3,:4,:5,:6,:7
oder
  CHILDREN: name_0,name_1,name_2,name_3,name_4,..
DIRECTION: NONE
  FIRMWARE: 2.0.2
  FIRMWARE_UPDATE_STATE: UP_TO_DATE
  FLAGS: Visible
  PARAMSETS: MASTER,SERVICE
  RF_ADDRESS: 10083543
  ROAMING: 0
  RX_MODE: ALWAYS,LAZY_CONFIG
  SUBTYPE: TRV
  UPDATABLE: 1
Channel 000A18A996E9DA:0 HmIP-eTRV-2 000A18A996E9DA:0 [MAINTENANCE]
  AES_ACTIVE: 1
  DIRECTION: NONE
  FLAGS: Visible
  PARAMSETS: MASTER,VALUES,SERVICE
  PARENT: 000A18A996E9DA
  PARENT_TYPE: HmIP-eTRV-2
  RF_ADDRESS: 0
  ROAMING: 0
  RX_MODE:
  UPDATABLE: 1
Channel 000A18A996E9DA:1 HMc_hc_1 HmIP-eTRV-2 000A18A996E9DA:1 [HEATING_CLIMATECONTROL_TRANSCEIVER]
  AES_ACTIVE: 1
  DIRECTION: SENDER
  FLAGS: Visible
  LINK_SOURCE_ROLES: CLIMATE_CONTROL
  PARAMSETS: MASTER,VALUES,LINK,SERVICE
  PARENT: 000A18A996E9DA
  PARENT_TYPE: HmIP-eTRV-2
  RF_ADDRESS: 0
  ROAMING: 0
  RX_MODE:
  UPDATABLE: 1


Nachdem das ganze Systemaitsch ist sollte es einfach machbar sein.

[martinp876]

next: Schaltlisten / Wochenpläne.
Die ausgegebene Liste der Wochenpläne ist (sicher klar) indiskutablen. Eine Registerliste ist nicht mehr lessbar und die Zahlen sowieso nicht.

Code Auswählen Erweitern

   P1_ENDTIME_FRIDAY_1 = 360
    P1_ENDTIME_FRIDAY_10 = 1440
    P1_ENDTIME_FRIDAY_11 = 1440
    P1_ENDTIME_FRIDAY_12 = 1440
    P1_ENDTIME_FRIDAY_13 = 1440
    P1_ENDTIME_FRIDAY_2 = 540
    P1_ENDTIME_FRIDAY_3 = 1020
    P1_ENDTIME_FRIDAY_4 = 1320
    P1_ENDTIME_FRIDAY_5 = 1440
    P1_ENDTIME_FRIDAY_6 = 1440
    P1_ENDTIME_FRIDAY_7 = 1440
    P1_ENDTIME_FRIDAY_8 = 1440
    P1_ENDTIME_FRIDAY_9 = 1440

a) die Sortierung. P1_ENDTIME_FRIDAY_1 => P1_ENDTIME_FRIDAY_01 zwingend erforderlich in dieser Darstellung
b)  P1_ENDTIME_FRIDAY_01 = 360 =>  P1_ENDTIME_FRIDAY_1 = 06:00 in Uhrzeit umwandeln
c) optional: Werte nach dem ersten "1440" können entfallen, da sie ignoriert werden.

Code Auswählen Erweitern

P1_ENDTIME_FRIDAY_1 = 360
P1_TEMPERATURE_FRIDAY_1 = 17.0

d) Kombinieren der Uhrzeit mit der Temperatur
P1_FRIDAY_1 = 17.0 06:00
Temperatur besser vor der Zeit angeben. Ich habe es wie von eq3 anders herum gemacht - das verwirrt quasi alle (incl mir)

und
e) Ein Tag in einer Zeile
e1) stoppen nach der 24:00 eingabe
e2) immer fixe stringlänge (leading '0')
P1_Friday = 17.0 06:00 24.0 22:00 05.0 24:00
=> die Eingabe (set datapoint) sollte hier entsprechend gemacht werden.
=> das ist demnach eine Abweichung von der strikten Datapoint ein/ausgabe. Aber bei der Länge der Listen ist dies unabdingbar. So ist es nicht lesbar

f) Praktisch ist es, die Wochentage zu nummerieren. Das ist zum Sortieren notwendig
P1_1_MONDAY
P1_2_TUESDAY
...

[zap]

Ich werde Deine Hinweise morgen mal der Reihe nach angehen. Vorab 2 Punkte:

- Ich hatte ja schon mal erwähnt, dass ich mich zunächst auf die funktionalen Dinge konzentriere und die Schleifchen bei den reinen Bildschirmausgabe-Befehlen (get xyDesc) später kommt. Ich habe es aber nicht vergessen
- Wenn Du ein neues Device anlegst, sollten automatisch einige Attribute gesetzt werden, auch Widget Attribute. Bestehende Devices, die beim Starten aus der fhem.cfg definiert werden, müssen einmalig mit "set defaults" aktualisiert werden. Das setzt dann nachträglich die Attribute.

[martinp876]

Rt temperaturen:
A) auch wenn die values set_point_temperature u.ä. heisen solltest du dies desired-temp nennen. Und actual measured-temp. Es gibt mehrere module welche Heizung unterstützen und quasi alle thermostate in fhem ansteuern. Hier ist es sinnvoll und wünschenswert für gleiche readings die selben Namen zu verwenden. Auch ich musste einst anpassen
B) für Temperatur einstellungen sollte es einen slider geben.
C) wo wir beim Thema sind: sollten nicht alle schreibbaren VALUES ein eigenes kommando habe ? Ich habe es aktuell nicht geprüft... VALUES mit literals sollten eine dropdown liste erhalten. So bspw der mode beim rt
Es gibt sicher Ausnahmen. So kann man beim dimmer level die Rampe Zeit, level und ontime angeben. Dies muss atomar gesendet werden. Also eine Ausnahme, ein multiparameter kommando. Die Frames welche in xml beschrieben sind müssen implementiert werden. Allerdings habe ich noch nicht gesehen, wie du sie der ccu entlocken kannst

[martinp876]

Habe set defaults gemacht. Es existiert für den rt nicht.
Ich hoffe, das in zukunft nicht zu brauchen. Die standart kommandos müssen schlicht eingebaut werden, ungefragt. Der user kann weitere on top implementieren, keine Frage. Deswegen werden die normale  nicht angefasst. Der user sollte in fhem hinreichend optionen haben, alles zu verbiegen. Hmccu muss und sollte hier nichts neues anbieten, was es schon gibt, nur um es noch einmal neu anzubieten.

[zap]

Ich habe leider kein IP Thermostat. Das ist alles recht leicht in HMCCUConf.pm konfigurierbar. Kannst Du mir bitte die Rolle von dem Kanal sagen? Ist das HEATING_CLIMATECONTROL_TRANSCEIVER?

Ich kann das rel. einfach einbauen.

[thomas.z]

Moin,
nach allerlei Kampf mit mehreren Geräten vom Typ HMCCUDEV für virtuelle HmIP-Heating Geräte (s. https://forum.fhem.de/index.php/topic,108902.0.html) habe ich den Eindruck, dass die Dokumentation verbessert werden könnte, indem man angibt, auf welche Events, die von der CCU geliefert werden, die regex der ccureadingffilter angewendet werden (bzw. wie man die für ein Gerät ermitteln kann). Ich bin lange davon ausgegangen, dass bei einem virtuellen Gerät auch nur die Liste von "get deviceinfo"  betrachtet wird. Alternativ schlage ich vor, HMCCU so zu ändern, dass das nur die o. g. devicenfo Daten betrachtet werden. Das würde zumindest meiner Intuition folgen, da das virtuelle Gerät ja unter anderem den Rest verbergen soll.
Ansonsten kann ich mit HMCCU jetzt genau das machen, was ich möchte. Danke dafür!
Gruß
Thomas