Schnittstellenänderung

Begonnen von Andi291, 12 Dezember 2017, 15:58:41

Vorheriges Thema - Nächstes Thema

Andi291

Ja, ist nachvollziehbar. Entspricht auch in etwa meinen Vorstellungen.
Ich meine, die GAD dann direkt adressieren zu können. Muss ich mir aber mal aufschreiben...

Andi291

Servus zusammen!

Anbei ein erster Draft, von der Richtung in der ich mir die Entwicklung vorstelle.
Es läuft rudimentär, ist aber noch nicht für "produktiven" Einsatz geeignet.

Am dringendsden fehlen noch die setExtensions sowie testen, testen, testen.

@Andreas:
ich bin die kommenden zwei bis drei Wochen Land unter. Wenn Du willst, Tob Dich aus :-)

Grüße, Andi

docm

Hi Andi291,
ich habe es runtergeladen. Bin aber diese Woche getrennt von meinem FHEM  :'( und kann es also erst danach testen.
Viele Grüße
Andreas

JoeALLb

Hallo Andreas,

wenns was zum testen gibt einfach melden.
Bin gerade an der Finalisierungsphase meiner neuen KNX-Umgebung...
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

Die Schnittstelle kannst Dir gerne ansehen.
Die SetExtensions (on-for-timer, ...) gehen noch nicht, aber grundsätzlich läufts...

Andi291

Moin Männer!

Es gibt Neues zum Testen...

Die DPT sollten nun alle funktionieren - sind teilweise getestet. SetExtensions sind drin. Die Erweiterungen von Andreas in Richtung put sind drin.

Bitte schaut mal drüber und gebt RM - Danke!!!

JoeALLb

DANKE.
Bin unterwegs,vschaus mir diese Woche an!

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

JoeALLb

#52
Hallo,

was mir auffällt:

1. Wenn man in einem KNX_Device unten auf "Device specific help" klickt, kommt die Hilfe vom TUL-Device, nicht vom KNX device.
    (War aber im alten auch schon der Fall).
2. ein Get auf ein Datums-Device aus der ETS heraus, wird der state zurückgegeben. Sollte aber eigentlich nicht der wert des readings "time-put" zurückgegeben werden?
3. "stateCmd" zeigt manchmal falsche Werte an. Wenn ich dort zB {ReadingsNum($name,"desired-temp-get","")} eingebe, kommt manchmal 0 als Ergebnis, obwohl
desired-temp-get = 16° ist. Manchmal kommen aber auch stimmige Werte. Seltsam.
    (( In dem Beispiel unten ist state =STATE, cmdState wurde ignoriert.))

Edit: Hier das Testdevice
defmod timedev KNX 0/0/251:dpt10:time
attr timedev IODev KNX
attr timedev answerReading 1
attr timedev eventMap /value now:now/
attr timedev room KNX
attr timedev stateCmd {ReadingsNum($name,"getG1","")}
attr timedev verbose 5
attr timedev webCmd now

setstate timedev 00:02:00
setstate timedev 2018-03-19 10:43:20 STATE 00:02:00
setstate timedev 2018-03-19 14:53:53 getG1 03:02
setstate timedev 2018-03-19 10:43:20 last-sender 1/1/4
setstate timedev 2018-03-19 10:43:20 setG1 00:02:00
setstate timedev 2018-03-19 10:43:20 state 00:02:00
setstate timedev 2018-03-19 14:43:21 time-put 00:01:02




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

Und wieder a bisserl stabiler...

Anbei mit der Bitte um Test und Feedback.

Grüße, Andi

JoeALLb

Hallo Andi,
worauf soll man in dieser Version denn besonders schauen?

Was ich gefunden habe ist:
# stateCmd liefert noch nicht die selben Ergebnisse wie das alte KNXD. Auch wenn die Readings selbst unverändert vorhanden sind..
# putCmd hört nicht auf einen veränderten "$value", wie in dem Beitrag von docm beschrieben, sondern auf einen returnwert.
# putCmd setzt das Reading "time-put" auf "", nachdem es über die ETS gelesen wird, wenn $value nicht verändert wird! (hängt mit dem oberen punkt zusammen)
# in putCmd wird die Variable $reading nicht mehr gefüllt und ist "", abfragen damit funktionieren also nicht mehr.
# Wenn ich das Log korrekt interpretiere, wird putCmd 2x evaluiert? (siehe unten)

Verbose Log beim Lesen eines Wertes aus der ETS:
2018.03.20 09:37:57 5: parse: process message, device-name: timedev, rd-name: date, gadCode: 000fa, model: dpt11
2018.03.20 09:37:57 5: received hash: HASH(0x5574dce7ce70) name: timedev, GET
2018.03.20 09:37:57 5: parse device hash: HASH(0x5574dce7ce70) name: timedev - put replaced via command {
return $reading ;
} - value:
2018.03.20 09:37:57 5: encode value: , gadName: date
2018.03.20 09:37:57 5: encode model: dpt11, code: dpt11, value:
2018.03.20 09:37:57 5: encode normalized value:
2018.03.20 09:37:57 5: encode model: dpt11, code: dpt11, value: , numval: -1900, hexval: 00fffffffffffff894
2018.03.20 09:37:57 5: received hash: HASH(0x5574dce7ce70) name: timedev, GET: 00fffffffffffff894, READING: date
2018.03.20 09:37:57 5: parse: process message, device-name: timedev, rd-name: date, gadCode: 000fa, model: dpt11
2018.03.20 09:37:57 5: received hash: HASH(0x5574dce7ce70) name: timedev, GET
2018.03.20 09:37:57 5: parse device hash: HASH(0x5574dce7ce70) name: timedev - put replaced via command {
return $reading ;
} - value:
2018.03.20 09:37:57 5: encode value: , gadName: date
2018.03.20 09:37:57 5: encode model: dpt11, code: dpt11, value:
2018.03.20 09:37:57 5: encode normalized value:
2018.03.20 09:37:57 5: encode model: dpt11, code: dpt11, value: , numval: -1900, hexval: 00fffffffffffff894
2018.03.20 09:37:57 5: received hash: HASH(0x5574dce7ce70) name: timedev, GET: 00fffffffffffff894, READING: date
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

Moin!

Gute Frage :-)

Ich hab unter der Haube ja deutlich mehr umgebaut. Die ganzen Datenstrukturen intern sind neu.
Weiterhin ist die signifikanteste Änderung, dass die neue Syntax

set <device> <gad-name> <wert>

ist. Das ganze geeir mit "value", ... und "g2"... ist weg...

Das "put" hab ich nur als goodie mitgenommen - schaue ich mir aber nochmal en detail an...

Andi291

P.S.: Schick mir bitte nochmal Deine aktuelle Definition.

Die o.g. ist inhaltlich nicht schlüssig:

attr timedev stateCmd {ReadingsNum($name,"getG1","")}

Kann eigentlich nicht funktionieren - es dürfte kein Reading mit dem Namen "getG1" geben.

JoeALLb

Hallo Andi,


Zitat von: Andi291 am 20 März 2018, 10:03:40
Die o.g. ist inhaltlich nicht schlüssig:

gestern gabs das noch! Auch heute gibt es das noch und es wird sogar aktualisiert (siehe timestamp),

hier mein Device von heute (mit geändertem stateCmd).
... dass mein putCmd nicht überall Sinn ergibt, ist mir bewußt, aber für Tests sollte es reichen.


defmod timedev KNX 0/0/251:dpt10:time\
0/0/250:dpt11:date\
0/0/252:dpt14:test
attr timedev IODev KNX
attr timedev answerReading 1
attr timedev eventMap /value now:now/
attr timedev group Global
attr timedev putCmd {\
  if ($reading =~ /date/) {\
    return ReadingsVal($name,"date-put","14.03.2018");;\
  }\
   elsif ($reading =~ /time/){\
     return ReadingsVal($name,"time-put","01:02:03")\
  }\
   elsif ($reading =~ /test/){\
     return $reading\
  }\
}\

attr timedev readonly 0
attr timedev room KNX
attr timedev stateCmd {ReadingsVal($name,"date-put","")}
attr timedev verbose 5
attr timedev webCmd now
attr timedev widgetOverride putCmd:textField-long

setstate timedev 2018-03-20 09:47:57 STATE 00:02:00
setstate timedev 2018-03-20 09:47:57 date-get 20.03.2018
setstate timedev 2018-03-20 09:47:57 date-put 18.03.2018
setstate timedev 2018-03-20 09:47:57 getG1 03:02
setstate timedev 2018-03-20 09:47:57 last-sender 1/1/253
setstate timedev 2018-03-20 09:47:57 setG1 00:02:00
setstate timedev 2018-03-20 09:47:57 state
setstate timedev 2018-03-20 09:47:57 time-put 00:01:02
setstate timedev 2018-03-20 09:47:57 time-set 00:02:00

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: Andi291 am 20 März 2018, 09:59:28
ist. Das ganze geeir mit "value", ... und "g2"... ist weg...

Was ich toll finde! ist viel übersichtlicher, vorallem da ich Devices mit >50 GADs habe (zB Stromzähler). Wenn ich dort eine GAD einfüge, musste ich
immer alle "g"s neu durchzählen :D.

Zitat von: Andi291 am 20 März 2018, 09:59:28
Das "put" hab ich nur als goodie mitgenommen - schaue ich mir aber nochmal en detail an...
Abe rnicht vollständig denke ich. In der version von docm wurde "$reading=..." vor dem eval gesetzt, damit die variable verfügbar war.
Das scheint jetzt zu fehlen, fixen konnte ich es aber leide rnicht.

In der Beschreibung von Andreas schrieb er auch

Zitat von: docm am 10 Februar 2018, 11:40:28
Wenn innerhalb von putCmd $value ein neuer Wert zugewiesen wird, so wird automatisch das -put Reading aktualisiert und dieser aktualisierte Wert auf den Bus gesendet.
Das funktioniert eben jetzt nicht mehr. Scheinbar muss jetzt die Rückgabe (oder "return") der routine verändert oder eben gleich gelassen werden. Das fand ich verwirrend, da ich zuerst natürlich den ersten Fall getestet habe und gescheitert bin.

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

Abend!

Jetzt hab ich die Verwirrung verstanden - aber der Reihe nach...

Zitat
1. Wenn man in einem KNX_Device unten auf "Device specific help" klickt, kommt die Hilfe vom TUL-Device, nicht vom KNX device.
    (War aber im alten auch schon der Fall).
Wirklich? Bei mir ist nur die TUL verlinkt, um auf das zweistufige Modulkonzept hinzuweisen. Hast Du einen Screenshot?

Zitat2. ein Get auf ein Datums-Device aus der ETS heraus, wird der state zurückgegeben. Sollte aber eigentlich nicht der wert des readings "time-put" zurückgegeben werden?
Wie Du ja später in Deinem Beispiel selbst schreibst - eben nicht. Wenn kein Device date-put angelegt ist, wird je nach Stellung answerReading nichts oder state zurück gegeben. Es sei denn, Du reagierst mit putCmd (was jetzt auch funktioniert :-)).

Zitat3. "stateCmd" zeigt manchmal falsche Werte an. Wenn ich dort zB {ReadingsNum($name,"desired-temp-get","")} eingebe, kommt manchmal 0 als Ergebnis, obwohl
desired-temp-get = 16° ist. Manchmal kommen aber auch stimmige Werte. Seltsam.
Das war dämlich...ich habe beim Umbau nicht auf gleiche Bezeichnung der Variablen geachtet - $Name habe ich durch $deviceName ersetzt. Sollte jetzt aber repariert sein und wieder auf $Name reagieren.

ZitatIn dem Beispiel unten ist state =STATE, cmdState wurde ignoriert.
cmdState ist durch den letzten Punkt erklärbar. STATE = state passiert irgendwo im Hintergrund. Das hat mich aber länger beschäftigt - gibt es in fhem.save entsprechende Leichen, bringt es ggf. den ABlauf durcheinander. Letztendlich hat es geholfen, die fhem.save mal zu bereinigen.

...gestern gabs das noch! Auch heute gibt es das noch und es wird sogar aktualisiert (siehe timestamp),
Ja, aber wahrscheinlich nur über die fhem.save.
Sobald bei einer GAD ein Name angegeben ist, gibt es kein getG.../o.ä. mehr. Das schließt sich aus...
Insofern kann das mit dem ReadingsVal getG1 nur auf Basis der gespeicherten fhem.save funktionieren - oder ich hab was gröberes übersehen...

ZitatAbe rnicht vollständig denke ich. In der version von docm wurde "$reading=..." vor dem eval gesetzt, damit die variable verfügbar war.
Das scheint jetzt zu fehlen, fixen konnte ich es aber leide rnicht.
Korrekt - weil ich es auch nicht 1:1 übernehmen wollte. Ich hab mich nun angenähert - einziger Unterschied ist $reading. Reading ist schlicht falsch, deshalb habe ich die Variable $gad gennant.

ZitatDas funktioniert eben jetzt nicht mehr. Scheinbar muss jetzt die Rückgabe (oder "return") der routine verändert oder eben gleich gelassen werden. Das fand ich verwirrend, da ich zuerst natürlich den ersten Fall getestet habe und gescheitert bin.
Gefixed...

Danke für's erste Feedback...Anbei der Stand für heute.

In diesem Sinne: Weitermachen :-)