Neues Modul HMCCU für Homematic CCU

[Loredo]

die grundlage für die (korekten) readings sind die datenpunkte wie sie eq3 beschreibt (das ist ein definierter, dokumentierter standard bezogen auf homematic produkte).

Ich weiß, dieses Dokument habe IMHO ich ins Spiel gebracht; darauf beziehe ich mich seit Anbeginn 

die möchte ich schon gerne haben/sehen. die umgeschriebenen readings erzeuge ich nur um readings an gepflogenheiten in fhem anzupassen (mach einer bezeichnet diese fälschlicherweise als"standards"  ) , da dies das arbeiten mit einigen anderen modulen (wie dewpoint zb) erleichtert bzw eine einheitliche namensgebung geräteübergreifend erfmöglicht

Mir ist schon klar, warum man das macht (auch wenn es IMHO keine FHEM Gepflogenheiten sind, sondern zum übermäßigen Teil sinnvolle Änderungen in Richtung "Human readability"). Was mit nicht klar ist, wie man sich entscheiden soll, ein Reading doppelt zu führen und ein anderes nicht. Für mich ergibt sich daraus kein Mehrwert, wenn ich habe den Wert ja nach wie vor als umbenanntes Reading und was ich nicht umbenenne bleibt im eq-3 Original. Kann sicher jeder machen, wie sie/er möchte. Ich wollte nur verstehen wie man da logisch drüber entscheidet wann mit und wann ohne +.

[chris1284]

Ich wollte nur verstehen wie man da logisch drüber entscheidet wann mit und wann ohne +.

bei mir richtet sich das allein nach schnittmengen mit anderen devices und modulen (zb dewpoint übergreifende für hmccu, hms, weather usw).
des weiteren habe ich seit hmcuu eine tui instanz die ich, bei verzicht auf die eq3 readings, erstmal komplett überarbeiten müsste.  wenn ich lust und zeit hab das zu tun werde ich sicher auch das ein oder ander "+" entfernen. die config readings R-<Channel>.Datapoint  müsste man ja auch noch "übersetzen" um sich cul_hm anzugleichen

[Loredo]

des weiteren habe ich seit hmcuu eine tui instanz die ich, bei verzicht auf die eq3 readings, erstmal komplett überarbeiten müsste. 

Ok. Wir diskutieren hier aber doch IMHO, was wir als Standardvorgabe mit ins Template aufnehmen können. Eigene Bequemlichkeiten zählen da nicht dazu 
Bisher habe ich nicht gehört, warum man ins Default-Template etwas mit + aufnehmen müsste (außer wegen dem pct/level Kompatibilitätseintrag für LEVEL).

die config readings R-<Channel>.Datapoint  müsste man ja auch noch "übersetzen" um sich cul_hm anzugleichen

Das ist sicherlich eher die Kür, weil es für die Bedienung der Geräte nicht notwendig ist und man die Programmierung ja eher in der CCU vornimmt (das verstehe zumindest ich unter "Best of both worlds"). Wenn du dich aber daran wagen möchtest, nur zu 

[chris1284]

Eigene Bequemlichkeiten zählen da nicht dazu 

ähm das hat nichts mit bequemlichkeit zu tun. diese readingsnamen (die hmccu seit anbeginn der module pflegte und pflegt) waren und sind der standard der module. alles was darauf aufgebaut wurde sollte man nicht unter bequemlichkeit abtun und einfach abschneiden und sagen wer das noch will sei zu bequem alles wieder umzubauen.

jetzt eine Standardvorgabe ins template zu setzen die alles komplett umwirft was es bisher in hmccu gab wäre falsch, der parallele weg (+) der kompatibelste und beste.
das wäre so als würde man nun in cul_hm einfach von heute auf morgen datapoints als readings einsetzen und alle bisherigen readings entfernen-> großer mist

die readings im cul_hm-format sind wie ich finde immernoch als nettes feature zu sehen (für evtl bequeme leute die mal cul_hm einsetzten) und nicht als default-template (außer als 2. reading halt, denn die stören bestandsinstallationen nicht sollte man templates per default aktivieren ).

[fini]

Hallo,

ich habe HMCCU eingerichtet und HMCCUDEV für meine Wetterstation.
In HMCCUDEV habe ich datapoint mit 1.TEMPERATURE angelegt.

leider ändert sich der Wert der Temperatur nicht
1.TEMPERATURE -0.800000 2017-01-23 15:21:55
hmstate Initialized 2017-01-23 15:40:01
state Initialized 2017-01-23 15:21:15

Muss ich noch was setzen?

Ciao Fini

[zap]

Nachtrag:

Ich habe jetzt nochmals versucht hmstatevals zu erraten:

Das hat eigentlich nichts mit Erraten zu tun. Ich versuche mal, die Logik hinter hmstate zu beschreiben:

• Bei jeder Datenpunkt Änderung eines Geräts berechnet HMCCU hmstate neu.
• Die Neuberechnung ermittelt zunächst den aktuellen Wert aller Datenpunkte, die zum Muster "^(UNREACH|LOWBAT|LOW_BAT|ERROR.*|FAULT_REPORTING|SABOTAGE)$" passen.
• Im Anschluss werden die Datenpunkte "normalisiert", d.h. alle ERROR_xxx werden zu ERROR, alle FAULT_xxx werden zu FAULT, LOW_BAT zu LOWBAT. Außerdem werden die Werte true/false durch 1/0 ersetzt.
• Nun wird geprüft, ob einer der normalisierten Datenpunkte >0 ist, d.h. einen Fehler anzeigt. Dabei wird nach folgender Reihenfolge vorgegangen: 'UNREACH', 'ERROR', 'FAULT', 'SABOTAGE', 'LOWBAT'.
• Der erste Wert, der die Bedingung >0 erfüllt, ergibt das neue hmstate. Durch die Priorisierung ist gewährleistet, dass hmstate immer den kritischsten Wert beinhaltet. Da die Bedeutung der Fehlercodes (Werte > 0) je nach Gerätetyp unterschiedlich sein kann, holt sich HMCCU die entsprechenden Ersetzungen aus dem Attribut 'hmstatevals'. Für viele Gerätetypen habe ich in HMCCUConf.pm hmstatevals definiert. Man kann die Fehler darüber natürlich auch anders benennen, z.B. "err_xxx"
• Wenn keiner der Werte die Bedingung > 0 erfüllt, also kein Fehler vorliegt, wird hmstate = state gesetzt. Dabei werden natürlich die Standard Wertemappings aus substitute übernommen.

Ein globales Attribut ccudef-hmstatevals macht keinen Sinn, da wie gesagt die Bedeutung der Codes je nach Gerätetyp unterschiedlich ist. Ich könnte allerdings substitute berücksichtigen. Das würde hmstatevals obsolet machen (mal sehen).

Zum Thema Ausgestaltung des Attributs ccudef-readingname: Ich möchte nicht in den Defaults die Originaldatenpunkte ersetzen. Sonst werden Nutzer, die aus der CCU2 Umgebung kommen, noch mehr verwirrt. Insofern ist die Duplizierung von Readings m.E. ein guter Kompromiss. Es steht ja jedem frei, das Attribut an die eigenen Bedürfnisse anzupassen.

[zap]

Hallo,

ich habe HMCCU eingerichtet und HMCCUDEV für meine Wetterstation.
In HMCCUDEV habe ich datapoint mit 1.TEMPERATURE angelegt.

leider ändert sich der Wert der Temperatur nicht
1.TEMPERATURE -0.800000 2017-01-23 15:21:55
hmstate Initialized 2017-01-23 15:40:01
state Initialized 2017-01-23 15:21:15

Muss ich noch was setzen?

Ciao Fini

Verm. läuft der RPC-Server nicht. Wenn Dein HMCCU-Device "myccu" heißt, musst Du noch folgendes machen:

Code Auswählen Erweitern


attr myccu rpcserver on
attr myccu rpcport 2001
set myccu rpcserver on


Falls Du Homematic IP verwendest, ergänze setze rpcport auf 2001,2010

[Loredo]

ähm das hat nichts mit bequemlichkeit zu tun. diese readingsnamen (die hmccu seit anbeginn der module pflegte und pflegt) waren und sind der standard der module.

Die neuen Attribute ccudef-readingsname und ccudef-substitude gehören aber nicht dazu. Warum soll jemand, der neu startet es unbequemer haben als jemand, der schon länger HMCCU benutzt? Ein Neuling versteht nicht, weshalb ein und derselbe Wert doppelt unter zwei Namen auftaucht und dass nun er derjenige sein soll, der sich das aus dem Standard-Attribut raus konfigurieren muss (und erstmal gar nicht weiß wie das geht).

Wenn du eine neue Funktion zusätzlich verwenden willst, musst du damit rechnen, dass du zusätzlichen Aufwand hast. Folglich ist es nur fair, dass du dir die + Zeichen an die richtigen Stellen schreiben musst, weil auch nur du weißt, wo du das haben willst und warum du es brauchst.

Es besteht ja überhaupt keine Gefahr, du musst ja bei einem bestehenden Setup explizit ccudef-readingsname und ccudef-substitude setzen. Da hast du dich vorher eh informiert, wozu du das willst, nicht?

die readings im cul_hm-format sind wie ich finde immernoch als nettes feature zu sehen (für evtl bequeme leute die mal cul_hm einsetzten) und nicht als default-template (außer als 2. reading halt denn die stören bestandsinstallationen nicht)

Das sehe ich anders.

In der Tat hat es nämlich hier ganz sicher nichts mit Bequemlichkeit zu tun, sondern zum Beispiel


a) mit der Notwendigkeit Values verständlich darzustellen, um besser erkennen zu können, was sie bedeuten (ein Wert 0-3 sagt nicht viel aus). Es macht keinen Sinn, dass jeder sich selbst in die eq-3 Dokumentation einlesen muss, nur um die selbe Information daraus zu extrahieren, wie alle anderen.

b) damit Homematic Geräte mit anderen Geräten kombinierbar zu machen, ohne dass sich jeder den Aufwand dafür wieder allein im stillen Kämmerlein machen muss, obwohl 100erte andere die selbe Aufgabe lösen oder schon gelöst haben. Da fallen mir sofort meine aktuellen Projekte powerMap und Unit zu ein... ohne hmstatus stateHM sinnlos. Andere Modulautoren geben sich auch immens Mühe damit, dass sie sich in das FHEM Ökosystem möglichst gut eingliedern. Ich will einfach nicht begreifen, warum das hier so schwer zu verstehen ist...

c) um vorhandene Codeschnipsel aus der Community übernehmen zu können, ohne sie ins kleinste Detail verstehen zu müssen.

d) schnelle Erfolgserlebnisse zu haben, damit FHEM Spaß macht und man sich langsam vortasten kann (ich weiß, ist selbst Rudi egal).


Ist ja schön, dass es euch Spaß macht beim Zusammenfassen aller Lichter aus Homematic, HUE und FS20 in einer Structure die HMCCU Geräte einzeln und jedes für sich so mit eventmap und co umzubiegen, dass der Gruppenstatus richtig erzeugt wird. Sowas ist doch unnötige, sich noch potenzierende Arbeit.

   
• Die Neuberechnung ermittelt zunächst den aktuellen Wert aller Datenpunkte, die zum Muster "^(UNREACH|LOWBAT|LOW_BAT|ERROR.*|FAULT_REPORTING|SABOTAGE)$" passen.

Kann man das flexibel machen, damit mein theoretisches Beispiel damit funktioniert? Ich möchte den Gerätestatus abgebildet haben, nicht den Fehlerstatus. Außerdem ist nicht generell alles was >1 ein echter Fehler, sondern ggf. nur eine Warnung und die möchte ich nicht bei jedem Gerät priorisiert angezeigt haben.
Sabotage z.B. will man auch unberücksichtigt lassen können, wenn man einen Bewegungsmelder hat, der nirgends montiert ist.

   
• Im Anschluss werden die Datenpunkte "normalisiert", d.h. alle ERROR_xxx werden zu ERROR, alle FAULT_xxx werden zu FAULT, LOW_BAT zu LOWBAT. Außerdem werden die Werte true/false durch 1/0 ersetzt.

Das ist eher schlecht, weil der nummerische Wert der Datenpunkte jeweils unterschiedliche Bedeutung haben kann. Siehe mein hypothetisches Beispiel wie hmstatevals in etwa aussehen müsste.

   
• Nun wird geprüft, ob einer der normalisierten Datenpunkte >0 ist, d.h. einen Fehler anzeigt. Dabei wird nach folgender Reihenfolge vorgegangen: 'UNREACH', 'ERROR', 'FAULT', 'SABOTAGE', 'LOWBAT'.

Das ist zu unflexibel bzw. zu generell. Bei FAULT_REPORTING sind auch Warnungen enthalten und nicht nur Fehler. 6/LOWBAT ist nur eine Warnung und ist weniger wichtig als der Gerätestatus insgesamt, 4/COMMUNICATION_ERROR kann immer mal vorkommen, hindert u.U. aber nicht daran das Gerät generell noch zu bedienen und ist deshalb ebenfalls nicht entscheidend für den Gerätestatus.

   
• Der erste Wert, der die Bedingung >0 erfüllt, ergibt das neue hmstate. Durch die Priorisierung ist gewährleistet, dass hmstate immer den kritischsten Wert beinhaltet. Da die Bedeutung der Fehlercodes (Werte > 0) je nach Gerätetyp unterschiedlich sein kann, holt sich HMCCU die entsprechenden Ersetzungen aus dem Attribut 'hmstatevals'. Für viele Gerätetypen habe ich in HMCCUConf.pm hmstatevals definiert. Man kann die Fehler darüber natürlich auch anders benennen, z.B. "err_xxx"

Nach dieser Beschreibung müsste dein Reading hmerrorstate benannt werden. Das ist nicht das, wovon ich die ganze Zeit spreche.
Ich kann damit nicht mein myHMCCUstate() in 99_myUtils ersetzen, obwohl du der Meinung bist, dass das zu 100% möglich wäre. Ich kann mir das nur so erklären, dass du es dir gar nicht näher angeschaut hast. Ich hoffe daher, dass mein Beispiel für hmstatevals weiter vorne ein besseres Beispiel darüber gibt, was passieren soll.

   
• Wenn keiner der Werte die Bedingung > 0 erfüllt, also kein Fehler vorliegt, wird hmstate = state gesetzt. Dabei werden natürlich die Standard Wertemappings aus substitute übernommen.

Das ist irgendwie nichts halbes und nichts ganzes, denn den Gerätestatus erst an dieser Stelle zu erfahren ist für die Gerätesteuerung nichts mehr wert. Du könntest genauso gut "no error" reinschreiben.

Das hat eigentlich nichts mit Erraten zu tun.

Doch. Denn wie du erkennen kannst, hast du mit deiner Aussage "du kannst damit komplett deine Funktion in 99_myUtils ersetzen" ganz andere Erwartungen ausgelöst. Die Dokumentation des Attributs hmstatevals gab das aber nicht her. Nach deiner ausführlichen Beschreibung weiß ich nun auch weshalb aber leider auch, weshalb es mir eher sinnfrei erscheint (möge mir gerne jemand sagen, was er mit hmstate jetzt wirklich besser machen kann, als die eq-3 Originalreadings entsprechend auszuwerten).

[fini]

Verm. läuft der RPC-Server nicht. Wenn Dein HMCCU-Device "myccu" heißt, musst Du noch folgendes machen:

Code Auswählen Erweitern


attr myccu rpcserver on
attr myccu rpcport 2001
set myccu rpcserver on


Falls Du Homematic IP verwendest, ergänze setze rpcport auf 2001,2010

habe jetzt alles noch mal neu eingerichtet
der Wert der Temperatur ändert sich nicht
ist immer -0.700000
müsste aber -0.800000 sein

[zap]

Ganz ehrlich: Ich verstehe das unten überhaupt nicht. Ist das der Inhalt eines ccudef-substitute? Wenn ja: Du möchtest also überhaupt keine separaten substitutes mehr in einzelnen Devices definieren, sondern alles über ein globales ccudef-substitute abhandeln? All diese Datenpunkte werden ja niemals in einem Gerät gleichzeitig vorkommen.

Oder meinst Du ein globales hmstatevals, in dem Du festlegen kannst, dass in einem Reading hmstate z.B. drin stehen kann "die Aussentemperatur ist gerade xy Grad"?

Eine globale Festlegung wird nicht möglich sein. Der Wert ERROR=1 kann bei Gerätetyp A eine andere Bedeutung haben als bei Typ B. Bei Wertemengen von identischen Datenpunkten gibt es Unterschiede zwischen HM-IP und klassischem HomeMatic. Deshalb können ccudef-readingname und ccudef-substitute nur Datenpunkte und Werte enthalten, die für alle Typen gelten.

Nachtrag:

Ich habe jetzt nochmals versucht hmstatevals zu erraten:

Code Auswählen Erweitern


UNREACH!1:unreachable;
FAULT_REPORTING!1:err_VALVE_TIGHT;
FAULT_REPORTING!2:err_ADJUSTING_RANGE_TOO_LARGE;
FAULT_REPORTING!3:err_ADJUSTING_RANGE_TOO_SMALL;
FAULT_REPORTING!5:err_UNSPECIFIED;
FAULT_REPORTING!7:err_VALVE_ERROR_POSITION;
ERROR_OVERHEAT!1:err_overheated;
ERROR_OVERLOAD!1:err_overloaded;
ERROR_REDUCED!1:err_reduced;
ERROR!1:err_1;
ERROR!2:err_2;
ERROR!3:err_3;
INHIBIT!1:locked;
DIRECTION!1:up;
DIRECTION!2:down;
DIRECTION!3:undefined;
WORKING!1:working;
MOTION!0:noMotion;
MOTION!1:motion;
LEVEL!0:off;
LEVEL!(1-99):??;
LEVEL!100:on;
STATE!.*:??;
VALVE_STATE!.*:??;
ACTUAL_TEMPERATURE!.*:??;
CONTROL_MODE!.*:??;
TEMPERATURE!.*:+T: ??;
HUMIDITY!.*:+H: ??;
WIND_SPEED!.*:+W: ??;
RAIN_COUNTER!.*:+R: ??;
RAINING!.*:+IR: ??;
WIND_DIRECTION!.*:+WD: ??;
WIND_DIRECTION_RANGE!.*:+WDR: ??;
SUNSHINEDURATION!.*:+S: ??;
BRIGHTNESS!.*:+B: ??;
FAULT_REPORTING!6:warn_battery;
LOW_BAT,LOWBAT!1:warn_battery;
ERROR!4:warn_battery;
UNREACH!0:ok;

Wie man dabei sieht, fehlt es an der Möglichkeit das bereits per ccudef-substitude umgewandeltes Value hier 1-zu-1 durchzureichen, wenn der Datenpunkt existiert (Beispiele LEVEL, STATE, VALVE_STATE, ACTUAL_TEMPERATURE, CONTROL_MODE). Deshalb die ?? in dem Beispiel.
Außerdem fehlt es für die ganzen WEATHER Datenpunkte daran diesen einen Präfix voranzustellen und sie hintereinander zu ergänzen. Die Notation dazu habe ich jetzt einfach mal erraten.
LEVEL>100 müsste auch noch so abgefangen werden, dass sich der Status dann gar nicht ändert und der vorherige LEVEL Wert erhalten bleibt.

Disclaimer: Das obige Beispiel funktioniert (derzeit) gar nicht, also z.B. auch nichtmal für Bewegungsmelder mit dem Datenpunkt MOTION.


Gruß
Julian

[fini]

Ganz ehrlich: Ich verstehe das unten überhaupt nicht. Ist das der Inhalt eines ccudef-substitute? Wenn ja: Du möchtest also überhaupt keine separaten substitutes mehr in einzelnen Devices definieren, sondern alles über ein globales ccudef-substitute abhandeln? All diese Datenpunkte werden ja niemals in einem Gerät gleichzeitig vorkommen.

Oder meinst Du ein globales hmstatevals, in dem Du festlegen kannst, dass in einem Reading hmstate z.B. drin stehen kann "die Aussentemperatur ist gerade xy Grad"?

Eine globale Festlegung wird nicht möglich sein. Der Wert ERROR=1 kann bei Gerätetyp A eine andere Bedeutung haben als bei Typ B. Bei Wertemengen von identischen Datenpunkten gibt es Unterschiede zwischen HM-IP und klassischem HomeMatic. Deshalb können ccudef-readingname und ccudef-substitute nur Datenpunkte und Werte enthalten, die für alle Typen gelten.

ich möchte einfach nur die Aktuelle Aussentemperatur 
Egel wie ... dachte nur es geht so wie in den beiden Bildern.
Wenn es anders geht?
Wind, Sonne u.s.w. sollen auch noch kommen.
Die  Werte möchte ich dann in die Tablet UI einbinden.

[Loredo]

Ganz ehrlich: Ich verstehe das unten überhaupt nicht. Ist das der Inhalt eines ccudef-substitute?

Nein, aber schön, dass sich die ganzen Attribute und Varianten inzwischen auch verwirren 

Ist das der Inhalt eines ccudef-substitute?

Nein, ich rede hier nicht von ccudef-substitude, sondern vom Attribut hmstatevals.
Es handelt sich um meinen Versuch dir in deiner Sprache bzw. fiktiver HMCCU-Notation zu erklären, wie mein Custom Script myHMCCUstate() zur Erzeugung eines Reading namens "stateHM" funktioniert und wie HMCCU's hmstate funktionieren und was es können sollte. Was du in dem Beitrag siehst, den du gerade zitiert hast, ist der Inhalt des Attributs hmstatevals, sofern es so funktionieren würde, wie ich es nach deiner "geht doch alles damit" Aussage erwartet habe.

Ich habe eigentlich alles verlinkt, aber die muss man natürlich auch anklicken. 
Dieser Versuch der Erklärung war also wohl leider vergeblich 

Wenn ja: Du möchtest also überhaupt keine separaten substitutes mehr in einzelnen Devices definieren

Doch, aber selbstverständlich! Das muss immer möglich sein für Ausnahmen.

sondern alles über ein globales ccudef-substitute abhandeln? All diese Datenpunkte werden ja niemals in einem Gerät gleichzeitig vorkommen.

Ich möchte selbstverständlich alles möglichst an einer einzigen Stelle konfigurieren und nur die Ausnahmen an den Geräten selbst.
Das mache ich ja jetzt auch schon so und es funktioniert auch prima über ccudef-substitude (wobei ich noch nicht probiert habe substitute jetzt mit einer Ausnahme an einem Gerät zu definieren).
Dass nicht alle Datenpunkte gleichzeitig bei einem einzelnen Gerät vorkommen können ist ja gerade das tolle: Ist es vorhanden greifen die Einstellungen, ist es nicht vorhanden macht es auch nichts das zentral mit drin zu haben, damit es für andere Geräte greifen kann.

Ich wundere mich gerade etwas darüber, dass es an dieser Stelle nun gerade so zu funktionieren scheint, wie ich es erwartet habe, es aber offenbar gar keine Absicht ist. Das macht mir etwas Sorgen...

Oder meinst Du ein globales hmstatevals, in dem Du festlegen kannst, dass in einem Reading hmstate z.B. drin stehen kann "die Aussentemperatur ist gerade xy Grad"?

Ein Attribut ccudef-hmstatevals wäre sehr wünschenswert, um nicht den selben Text bei jedem HMCCU.+ Device im Attribut hmstate stehen zu haben.
Ich will aber da keinen Langtext rein schreiben, ist aber sicher schön, wenn man es könnte.

Die von mir beschriebene Logik lässt sich eigentlich extrem einfach in myHMCCUstate() nachvollziehen. Die fiktive hmstatevals Notation habe ich nur deshalb geschrieben, weil ich annahm, dass es für dich leichter wäre nachzuvollziehen. Ich habe ja auch extra noch hier beschrieben, was von der Logik-Reihenfolge passieren soll (die Punkte beschriftet mit 1., 2., 3., 4., 4a., 5., 6.). Hast du das wenigstens gelesen und verstanden?

Ich weiß auch nicht was ich noch machen soll, um es dir zu erklären.  Nachdenken und nachvollziehen müsstest du es schon selbst.

Eine globale Festlegung wird nicht möglich sein. Der Wert ERROR=1 kann bei Gerätetyp A eine andere Bedeutung haben als bei Typ B. Bei Wertemengen von identischen Datenpunkten gibt es Unterschiede zwischen HM-IP und klassischem HomeMatic.

Wir reden über ccudef-hmstatevals, ja? Gut.

Der ERROR Wert hat sicherlich unterschiedliche Bedeutung. Das heißt aber nicht, dass ich nicht global zumindest festlegen könnte, dass dort einfach nur ein Text wie err_1, err_2 und so weiter stehen kann. Wenn ich es dabei genauer haben wollen würde, dann könnte ich ja im Gerät eine spezifischere Definition hinterlegen.
Bei wem ein Mix auf HM-IP und HM-Classic zu Überschneidungen führt, kann ja dann andere Definitionen an den Geräten selbst hinterlegen oder ganz auf die ccudef-Variante verzichten.

Deshalb können ccudef-readingname und ccudef-substitute nur Datenpunkte und Werte enthalten, die für alle Typen gelten.

Das hat jetzt nichts mit hmstatevals zu tun, daher verwirrt mich der Satz an dieser Stelle.
Grundsätzlich hast du hier Recht. "können" wäre aber besser als "sollten" gelten, denn es kann für viele Installationen trotzdem Sinn machen das zu tun. Ich habe in ccudef-readingname auch STATE mit drin, um die führenden Ziffern zu entfernen, weiß aber, dass ich dabei aufpassen muss. Das ist auch nichts, was ich für ein Default-Setting vorschlagen würde, was HMCCU mitliefert.

[zap]

ich möchte einfach nur die Aktuelle Aussentemperatur 
Egel wie ... dachte nur es geht so wie in den beiden Bildern.
Wenn es anders geht?
Wind, Sonne u.s.w. sollen auch noch kommen.
Die  Werte möchte ich dann in die Tablet UI einbinden.

Mein Beitrag bezog sich auf die laufende Diskussion mit Loredo. Das hat nichts mit Deinem Problem zu tun. In Deinem Fall:

Wann hast Du das letzte Update von FHEM gemacht? Mach bitte ein "update check" und prüfe, ob Dir 88_HMCCU.pm bzw. HMCCUConf.pm als Update angeboten werden. Wenn ja, mache ein update.
Alternativ: Setze das Attribut ccudef-readingfilter im HMCCU-Device auf .*

Um den RPC-Server wieder ans Laufen zu bekommen, stoppe FHEM, kille die übrig gebliebenen fhem.pl Prozesse und starte wieder FHEM.

P.S. wer hat hier im FHEM Forum eigentlich damit angefangen, alle Fragen zu einem Modul in den gleichen Thread zu packen? Ich habe das bisher in keinem anderen Forum so extrem erlebt wie hier. Wenn ich hier Threads sehe mit >1000 Beiträgen und >100000 Aufrufen, kann ich nur den Kopf schütteln. Und diese Threads gibt es reichlich.
Aber das nur am Rande. Und keine Angst, ich lesen und schreibe hier weiterhin, auch wenn ich es besser finden würde, wenn man für separate Probleme separate Threads starten würde.

[Chris8888]

ich möchte einfach nur die Aktuelle Aussentemperatur 
Egel wie ... dachte nur es geht so wie in den beiden Bildern.
Wenn es anders geht?
Wind, Sonne u.s.w. sollen auch noch kommen.
Die  Werte möchte ich dann in die Tablet UI einbinden.

Hi, müsste da nicht noch ein "attr device event-on-change-reading .*" hin?
VG
Christian

[fini]

Mein Beitrag bezog sich auf die laufende Diskussion mit Loredo. Das hat nichts mit Deinem Problem zu tun. In Deinem Fall:

Wann hast Du das letzte Update von FHEM gemacht? Mach bitte ein "update check" und prüfe, ob Dir 88_HMCCU.pm bzw. HMCCUConf.pm als Update angeboten werden. Wenn ja, mache ein update.
Alternativ: Setze das Attribut ccudef-readingfilter im HMCCU-Device auf .*

Um den RPC-Server wieder ans Laufen zu bekommen, stoppe FHEM, kille die übrig gebliebenen fhem.pl Prozesse und starte wieder FHEM.

P.S. wer hat hier im FHEM Forum eigentlich damit angefangen, alle Fragen zu einem Modul in den gleichen Thread zu packen? Ich habe das bisher in keinem anderen Forum so extrem erlebt wie hier. Wenn ich hier Threads sehe mit >1000 Beiträgen und >100000 Aufrufen, kann ich nur den Kopf schütteln. Und diese Threads gibt es reichlich.
Aber das nur am Rande. Und keine Angst, ich lesen und schreibe hier weiterhin, auch wenn ich es besser finden würde, wenn man für separate Probleme separate Threads starten würde.

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?