Neues Modul HMCCU für Homematic CCU

Begonnen von zap, 19 August 2015, 19:45:30

Vorheriges Thema - Nächstes Thema

zap

Ich lade die Tage mal eine Version mit erweiterter Logging Funktion hoch, damit wir das Problem eingrenzen können. In der Zwischenzeit könntest Du bitte mal die Definition der Devices mit Attributen posten oder mir per Forum Mail schicken?
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

ToM_ToM

Hallo Zap,

die Definition der Devices sieht so aus

#HMCCU
define CCU2 HMCCU homematic-ccu2
attr CCU2 ccureadingfilter .*
attr CCU2 rpcserver on

#Küche - Thermostat
define HM_KU_Thermostat HMCCUDEV LEQ1076554 4
attr HM_KU_Thermostat IODev CCU2
attr HM_KU_Thermostat statechannel 4

#Küche - Fenster
define HM_KU_Fenster HMCCUDEV MEQ0752141 1
attr HM_KU_Fenster IODev CCU2
attr HM_KU_Fenster statechannel 1


Viele Grüße und frohe Weihnachten.
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

ToM_ToM

Ich habe jetzt auch nochmal einen Schalter eingebunden aber auch von dem bekomme ich keine automatischen Events in FHEM.
Die Einrichtung mache ich gerade bei meinen Eltern. Leider bin ich nur über Weihnachten hier und muss danach wieder fahren.

VG, Thomas
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

zap

#138
Weihnachtsupdate von 88_HMCCU.pm eingecheckt. Bitte unbedingt die neue Version aus Sourceforge installieren! Behebt einen Bug beim Update von Client Devices, der unter bestimmten Konstellationen auftreten kann.

In HMCCU Device das Loglevel auf 1 setzen. Bei Loglevel = 2 werden alle Events vom RPC Server protokollert (nur für Fehlersuche geeignet, produziert je nach Anzahl der CCU Devices viele Logeinträge).

Vergesst das mit dem Logging, muss erst die Module auf Verbose / Log3 umstellen, bevor ich das wieder aktiviere.

@Tom_Tom: Deine Konfig passt soweit. Attribut ccureadingfilter ist per default .*, kann also auch weggelassen werden. Ich würde das Attribut immer nur bei Client-Devices setzen, da sich die sinnvollen Readings je nach Gerätetyp unterscheiden.

Einige Beispiele für den Einsatz der Module:

Definition eines Heizungsthermostaten (Einstellung der Zieltemperatur mit set devstate):


define HM_KL_AZ_HZ HMCCUDEV KL-AZ-HZ
attr HM_KL_AZ_HZ IODev d_ccu
attr HM_KL_AZ_HZ ccureadingfilter (LOWBAT|TEMPERATURE)
attr HM_KL_AZ_HZ ccustate T: KL-AZ-HZ.4.ACTUAL_TEMPERATURE° D: KL-AZ-HZ.4.SET_TEMPERATURE°
attr HM_KL_AZ_HZ stateFormat {HMCCU_State($name)}
attr HM_KL_AZ_HZ statechannel 4
attr HM_KL_AZ_HZ statedatapoint SET_TEMPERATURE
attr HM_KL_AZ_HZ stripnumber 1


Definition eines Wandthermostaten (Ohne Einstellmöglichkeit der Zieltemperatur, nur Auswertung Temperatur und Luftfeuchte):


define HM_KL_AZ_TH HMCCUDEV KL-AZ-TH
attr HM_KL_AZ_TH IODev d_ccu
attr HM_KL_AZ_TH ccureadingfilter (^HUMIDITY|^TEMPERATURE|^SET_TEMPERATURE|^LOWBAT$)
attr HM_KL_AZ_TH ccustate T: KL-AZ-TH.1.TEMPERATURE° H: KL-AZ-TH.1.HUMIDITY% D: KL-AZ-TH.2.SET_TEMPERATT
URE° P: DEWPOINT°
attr HM_KL_AZ_TH devStateIcon OK:10px-kreis-gruen Error:10px-kreis-rot Initialized:10px-kreis-gelb
attr HM_KL_AZ_TH stateFormat {HMCCU_State($name)}
attr HM_KL_AZ_TH statechannel 2
attr HM_KL_AZ_TH statedatapoint TEMPERATURE
attr HM_KL_AZ_TH stripnumber 1
attr HM_KL_AZ_TH substitute LOWBAT!(0|false):no,(1|true):yes
attr HM_KL_AZ_TH userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-AZ-TH.1.TEMPERATURE", "KL-AZ-TH.1.HUMIDITY","n/a")}


Definition eines Readonly Fenstersensors:


define HM_TF_SZ_Fenster1 HMCCUCHN TF-SZ-Fenster1:1 readonly
attr HM_TF_SZ_Fenster1 IODev d_ccu
attr HM_TF_SZ_Fenster1 devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
attr HM_TF_SZ_Fenster1 substitute STATE!(0|false):closed,(1|true):open;;LOWBAT!(0|false):no,(1|true):yes


Definition einer Schaltsteckdose (ein/ausschalten mit set devstate on/off):


define HM_ST_WZ_Bass HMCCUDEV ST-WZ-Bass
attr HM_ST_WZ_Bass IODev d_ccu
attr HM_ST_WZ_Bass ccureadingfilter (STATE|LOWBAT|ON_TIME)
attr HM_ST_WZ_Bass ccureadings 1
attr HM_ST_WZ_Bass devStateIcon on:10px-kreis-gruen off:10px-kreis-rot Initialized:10px-kreis-gelb
attr HM_ST_WZ_Bass statechannel 1
attr HM_ST_WZ_Bass statevals on:true,off:false
attr HM_ST_WZ_Bass substitute STATE!true:on,false:off,1:on,0:off;;LOWBAT!true:yes,false:no

2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

ToM_ToM

#139
Hey, ich habe das Weihnachtsupdate installiert, aber leider auch ohne Erfolg.
Habe das System neu gestartet, den RPC Server per attribute gestartet (hat auch eine Prozess-ID und läuft).
Anschließend ca. 5 Minuten gewartet, aber keine Daten kamen.
Dann habe ich get devicelist ausgeführt, einige Minuten gewartet, aber nichts passiert.
Dann im angelegten Device (Thermostat) get channel 4 ausgeführt und die korrekten Readings bekommen.
Ich habe dann am Thermostat die Temperatur verstellt. Diese wird mir auch in der Homematic-Oberfläche korrekt angezeigt. Jedoch leider immer noch nicht in FHEM.

FHEM - Log-Eintrag aktualisiert sich permanent. Aber die Änderungen die ich mache (egal ob am Thermostat oder in der HM-Web-Oberfläche) werden nicht empfangen.

2015.12.25 20:33:28 1: HMCCU: RPC server started with pid 1861
2015.12.25 20:35:19 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:24 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:29 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:34 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:39 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:44 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:49 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:54 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:59 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:36:04 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:36:09 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:36:14 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:36:32 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.CONTROL_MODE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.FAULT_REPORTING
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.BATTERY_STATE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.VALVE_STATE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.BOOST_STATE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.ACTUAL_TEMPERATURE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.SET_TEMPERATURE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_TEMPERATURE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_START_TIME
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_START_DAY
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_START_MONTH
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_START_YEAR
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_STOP_TIME
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_STOP_DAY
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_STOP_MONTH
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_STOP_YEAR
2015.12.25 20:54:17 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:22 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:27 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:32 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:37 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:42 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:47 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:52 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:57 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:02 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:07 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:12 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:18 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:23 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:28 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:33 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:38 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:43 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:48 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:53 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:58 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:56:03 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:56:08 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:56:13 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:56:18 1: HMCCU: Received no events from CCU since 180 seconds


Sorry dass ich dir keine positive Nachricht hinterlassen kann.

Viele Grüße, Thomas.
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

ToM_ToM

Hey, ich habe jetzt mal statt des DNS Namens der CCU die IP-Adresse eingetragen und schon geht es. :)
Darauf wäre ich vorher nie gekommen, da er ja die ganze Zeit als Status "Ok" angezeigt hatte.

Viele Grüße und noch schöne Weihnachten :)
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

lukasbastelpeter

#141
Guten Abend zusammen, ich habe jetzt meine "Entwicklungs-/Bastelumgebung" soweit aufgebaut.
Wenn ich via FHEm meinen Aktor in der CCU schalte, schaltet der zwar noch, FHEM stürzt aber ab.
Das Log verweist auf:

http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/HMCCU/88_HMCCUDEV.pm#l236

"Undefined subroutine &main::usleep called at ./FHEM/88_HMCCUDEV.pm line 236."


Meine Config:

Zitat
define CCU HMCCU 192.168.20.XXX
attr CCU ccureadings 1
attr CCU rpcserver on

define ccu.AZ.Aktor.Tuer.1 HMCCUDEV XXXXXXXXX 1
attr ccu.AZ.Aktor.Tuer.1 IODev CCU
attr ccu.AZ.Aktor.Tuer.1 statechannel 1
attr ccu.AZ.Aktor.Tuer.1 statevals on:true,off:false
attr ccu.AZ.Aktor.Tuer.1 substitute true:on,false:off,1:on,0:off



Kann mir jemand weiter helfen?

BTW: Ich kann Systemvariablen via FHEM setzen, also die Richtung funktioniert einwandfrei, so wie ich das verstehe, wartet FHEM vergeblich auf eine Bestätigung, dass die Aktion durchgeführt wurde und gibt dann enttäuscht auf?







EDIT #1:

Nach frischer Energie bin ich auf den Trichter gekommen, dass die Funktion usleep() in Time::HiRes steckt; das werde ich noch mal drüber bügeln und berichten.
-> Bringt nix!

EDIT #2:

Edit: Bringt doch was, wenn man es dann in der 88_HMCCUDEV.pm noch "used"
->
Zitatuse Time::HiRes qw( sleep);
noch in den Header und jetzt lüppt et. 8)
# Raspberry Pi
# Homematic, Z-Wave
# HUE, Tradfri
# Harmony
# ESP8266  Basteleien per MQTT

lukasbastelpeter

#142
Nach meiner kleinen Odyssee im Post darüber habe ich jetzt noch folgende Fragen:

#1 Ich habe vor alle Homematic-Komponenten an der CCU anzumelden und Änderungen an FHEM "gepusht" zu bekommen -> Das funktioniert im Moment so "lala" für mich zeitlich willkürlich.
-> Ich habe es soweit verstanden, dass der RCP-Server quasi die Events gepusht bekommt, diese in die Queue steckt und FHEM sich alle X Zeiteinheiten dort das neuste rausbekommt.

Kann ich jetzt dieses X möglichst klein bestimmen? Ich hätte z.B. einige zeitkritische Sachen die ich gerne direkt in FHEM hätte. Z.B. sobald bei Abwesenheit die Tür auf geht möchte ich bei Dunkelheit Licht einschalten. Diese Logik möchte ich aber (gerne) in FHEM implementieren.(Ich finde das geklicke nicht so schön und es sollen noch IT-Devices mit an gehen).


#2 Das RCPServer Attribut der CCU steht immer wieder auf off, müsste das nicht on sein?
-> Selbst wenn ich es manuell auf on setze ist es einige Minuten später wieder off?!

#3 Eine Mischung aus #1-> Wieso ist der "state" in FHEM nachdem ich ihn via FHEM gesetzt habe bei einem Schaltaktor z.B. "OK" und nich "On" oder "Off"? das müsste mit einem get doch machbar sein oder? Bzw. ist wahrscheinlich schon so eingebaut aber funktioniert bei mir nicht?
# Raspberry Pi
# Homematic, Z-Wave
# HUE, Tradfri
# Harmony
# ESP8266  Basteleien per MQTT

zap

Zitat von: lukasbastelpeter am 25 Dezember 2015, 22:19:50
Edit: Bringt doch was, wenn man es dann in der 88_HMCCUDEV.pm noch "used"
-> noch in den Header und jetzt lüppt et. 8)

Keine Ahnung, warum bei mir usleep ohne use Timer::Hires funktioniert. Aber danke für den Hinweis. Baue es ein und checke die neuen Versionen von 88_HMCCUCHN und 88_HMCCUDEV heute noch ein.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

zap

#144
Zitat von: lukasbastelpeter am 26 Dezember 2015, 13:56:23
#1 Ich habe vor alle Homematic-Komponenten an der CCU anzumelden und Änderungen an FHEM "gepusht" zu bekommen -> Das funktioniert im Moment so "lala" für mich zeitlich willkürlich.
-> Ich habe es soweit verstanden, dass der RCP-Server quasi die Events gepusht bekommt, diese in die Queue steckt und FHEM sich alle X Zeiteinheiten dort das neuste rausbekommt.

Ja, so funktioniert das. Das X kannst Du per Attribut rpcinterval setzen. Im FHEM GUI lässt das Werte von 3, 5 und 10 Sekunden zu. Default ist 5. Wenn Du das Kommando attr ... direkt eintippst, kannst Du auch andere Werte einsetzen. Wird m.W. nicht geprüft. Bitte beachten: In den ersten drei Minuten nach Starten des RPC Servers kommen keine Events!

Zitat
#2 Das RCPServer Attribut der CCU steht immer wieder auf off, müsste das nicht on sein?
-> Selbst wenn ich es manuell auf on setze ist es einige Minuten später wieder off?!

Da stimmt was nicht. HMCCU prüft alle X Sekunden (siehe oben #1), ob der RPC-Server noch läuft. Wenn nicht setzt er das Attribut auf "off". Außerdem wird das Internal RPCPID in HMCCU auf 0 gesetzt und RPCPRC auf "none". Scheint so, als würde der RPC Server abschmieren. Schau Dir bitte mal die ccurpcd.log und das fhem log an (grep HMCCU). Läuft der RPC Server noch (ps -ef | grep ccurpcd)

Zitat
#3 Eine Mischung aus #1-> Wieso ist der "state" in FHEM nachdem ich ihn via FHEM gesetzt habe bei einem Schaltaktor z.B. "OK" und nich "On" oder "Off"? das müsste mit einem get doch machbar sein oder? Bzw. ist wahrscheinlich schon so eingebaut aber funktioniert bei mir nicht?

Im HMCCU oder in einem HMCCUDEV/HMCCUCHN Device? In HMCCU ist das so. Dafür ist das IO Device auch nicht gedacht. Da bekommt state immer den Status (also OK/Error) des letzten Befehls. In einem HMCCUCHN oder HMCCUDEV Device sollte state allerdings tatsächlich den Status des Gerätes annehmen. Dazu solltest Du zunächst mit "attr statechannel" den Kanal definieren, der den Status liefert bzw. den Status setzt. Wenn der zugehörige Datenpunkt nicht "STATE" heißt, kannst Du den mit dem Attribut "statedatapoint" bestimmen. Hier nochmal zwei Beispiele:

Zunächst eine einfache Schaltsteckdose (nur die State relevanten Attribute):


define HM_ST_WZ_Bass HMCCUDEV ST-WZ-Bass
# Der folgende Kanal enthält den Datenpunkt STATE
attr HM_ST_WZ_Bass statechannel 1
# Im set devstate Befehl werden on/off in true/false übersetzt und an die CCU geschickt
attr HM_ST_WZ_Bass statevals on:true,off:false
# Im get devstate Befehl (und bei Events) werden true/1/false/0 durch on/off ersetzt und in state gespeichert
attr HM_ST_WZ_Bass substitute STATE!true:on,false:off,1:on,0:off;;LOWBAT!true:yes,false:no


Ein Heizthermostat mit SET_TEMPERATURE als State-Datenpunkt:


define HM_G_AZ_HZ HMCCUDEV G-AZ-HZ
attr HM_G_AZ_HZ statechannel 4
attr HM_G_AZ_HZ statedatapoint SET_TEMPERATURE
# Bei Anzeige der Zieltemperatur in state soll nur eine Nachkommastelle angezeigt werden
attr HM_G_AZ_HZ stripnumber 1

2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

lukasbastelpeter

#145
Ok, nach einigen Boots scheint der RCP durch zu laufen.
Wenn ich in der HMCCU ein get devicelist mache, was passiert dann?
Werden die Devices dann irgendwo aufgelistet?
Bei mir nicht :(

In den Bildern habe ich das jetzt mal umgesetzt, in dem Reading scheint der STATE anzukommen,
aber leider nicht als "State"... HILFE! :o ;)

# Raspberry Pi
# Homematic, Z-Wave
# HUE, Tradfri
# Harmony
# ESP8266  Basteleien per MQTT

ToM_ToM

Hallo Zusammen,

ich versuche gerade die Daten in der TabletUI anzuzeigen. Aber ich weiß nicht so recht was ich abfragen muss.
Kann mir jemand helfen?

<div data-type="thermostat"
data-device="HM_KU_Thermostat"
data-get="datapoint 4.SET_TEMPERATURE"
data-set="datapoint 4.SET_TEMPERATURE"
data-temp="HM-CC-RT-DN%20LEQ1076554.4.ACTUAL_TEMPERATURE"
data-min="0"
data-max="50"
class="cell">
</div>


Ich habe jetzt alle möglichen Kombinationen ausprobiert.
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

zap

#147
Zitat von: ToM_ToM am 26 Dezember 2015, 17:33:00
Hallo Zusammen,

ich versuche gerade die Daten in der TabletUI anzuzeigen. Aber ich weiß nicht so recht was ich abfragen muss.
Kann mir jemand helfen?

<div data-type="thermostat"
data-device="HM_KU_Thermostat"
data-get="datapoint 4.SET_TEMPERATURE"
data-set="datapoint 4.SET_TEMPERATURE"
data-temp="HM-CC-RT-DN%20LEQ1076554.4.ACTUAL_TEMPERATURE"
data-min="0"
data-max="50"
class="cell">
</div>


Ich habe jetzt alle möglichen Kombinationen ausprobiert.

In "data-get" und "data-temp" kommt nur das Reading rein, während in "data-set" der Befehl angegeben werden muss. Bei mir sieht ein Wandthermostat (Vorsicht, andere Kanäle als das Heizkörperthermostat) in Tablet-UI so aus:


<div data-type="thermostat"
   data-device="HM_KL_SZ_TH"
   data-get="KL-SZ-TH.2.SET_TEMPERATURE"
   data-temp="KL-SZ-TH.1.TEMPERATURE"
   data-set="datapoint 2.SET_TEMPERATURE"


Und so sehen meine Readings aus:


Readings:
     2015-12-26 17:47:16   DEWPOINT        11.4
     2015-12-26 17:47:16   KL-SZ-TH.1.HUMIDITY 63
     2015-12-26 17:47:16   KL-SZ-TH.1.TEMPERATURE 18.6
     2015-12-26 17:46:55   KL-SZ-TH.2.SET_TEMPERATURE 21.0
     2015-12-26 17:47:16   state           18.6


Ein Problem in Deinem Fall könnte das Leerzeichen im Readingname von "data-temp" sein. Hast Du mal %20 durch ein einfaches Blank ersetzt?
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

zap

#148
Zitat von: lukasbastelpeter am 26 Dezember 2015, 17:29:47
Wenn ich in der HMCCU ein get devicelist mache, was passiert dann?
Werden die Devices dann irgendwo aufgelistet?
Bei mir nicht :(

get devicelist erzeugt keine Ausgabe. Es wird lediglich das Internal "DevCount" im IO Device auf die Anzahl der von der CCU gelesenen Geräte und Kanäle gesetzt. Mit get devicelist dump erfolgt eine Auflistung aller Kanäle im FHEM Fenster.

get devicelist wird beim Define des IO Devices automatisch ausgeführt. Nach einem Reload von 88_HMCCU muss es manuell ausgeführt werden. Ebenso, wenn in der CCU ein neues Gerät angelernt wurde oder sich an einem vorhandenen Gerät etwas geändert hat.

Zitat
In den Bildern habe ich das jetzt mal umgesetzt, in dem Reading scheint der STATE anzukommen,
aber leider nicht als "State"... HILFE! :o ;)

mmm, darüber muss ich etwas nachdenken ... aber mach schon mal beim Attribut substitute aus den 2 Semikolon vor LOWBAT eins. Die zwei Semikolon kommen daher, dass ich meine Beispiele aus der fhem.cfg kopiert habe.

2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

lukasbastelpeter

#149
Alles klar, das mit dem dump habe ich wohl überlesen in der Doku  :-X

Alles klar, ich versuche auch mal via debugging weiter zu kommen, aber es kommt auch kein "Event" wenn ich schalte.
Scheint so als würde das reading von Fhem selbst gesetzt...?!- Also ohne entsprechenden input der ccm?


Kann ich verhindern, dass das:
"2015.12.26 16:33:42 1: HMCCU: Received no events from CCU since 180 seconds"
nicht jede Sekunde geloggt wird?
# Raspberry Pi
# Homematic, Z-Wave
# HUE, Tradfri
# Harmony
# ESP8266  Basteleien per MQTT