Autor Thema: Schnittstellenänderung  (Gelesen 7109 mal)

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Schnittstellenänderung
« am: 12 Dezember 2017, 15:58:41 »
Hallo zusammen,

einige Anfragen in Richtung "Modernisierung" Schnittstelle zum FHEMWeb wurden am mich heran getragen.

Grundsätzlich gingen alle Fragen in die Richtung - braucht es die "alte" Syntax mit "gno" im Mittelpunkt noch? Warum können nicht die Namen der einzelnen Gruppenadressen direkt verwendet werden?
Ich hab mir mal Gedanken gemacht, wie man das umsetzen kann, ohne wieder zu viele inkompatible Änderungen durchführen zu müssen.

Einen ersten Wurf findet Ihr anbei - für den Moment ist mal nur der "get-Pfad" bedient. Dieser war deutlich einfacher umzusetzen.
Offen ist noch der Feinschliff in Richtung readings, sowie die Stategie für Set.
Ich neige zum Entfallen der Schlüsselworte wie value, ... und dafür zu einer Validierung der eingegebenen Werte zur Laufzeit.

Nun bitte ich um Test und rege Diskussion - geht das in die richtige Richtung? Ist es noch kompatibel zu Euren Use-Cases?

Grüße, Andi

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #1 am: 13 Dezember 2017, 20:50:28 »
V2 - a bisserl performanter und mit zwei Fehlern weniger.

Offline erwin

  • Full Member
  • ***
  • Beiträge: 364
Antw:Schnittstellenänderung
« Antwort #2 am: 13 Dezember 2017, 22:14:48 »
Hi Andi,
... da nimmst du dir was vor, mit meiner Unterstützung kannst du rechnen!
ich würde vorerst das "Konzept vorschlagen und hier diskutieren, bevor es an coding geht....

Vorschlag von mir:
1)   irgenwie sollten wir die reading-namen (wenns schon völlig freie sein sollten) während des defines in setters und getters sortieren.
    zb: 1/2/45:dpt5.001:Isttemperatur:g - damit wärs ein get(=read/reply vom bus), ein  1/2/46:dpt5.001:Settemperatur:s könnte dann ein Set sein.
    ich hätte sonst keine Idee, wie man die sonst auseinander halten könnte. Die reading-namen müssen unique sein! Ich denke nicht, dass das ein Problem sein wird.
    Falls wirklich ein GA sowohl set als auch get unterstützt, schlimmstenfalls 2 definitionen....
    Natürlich müsste man dan die setter- und getter-hash dann dynamisch updaten.
    die befehlen lauten dann: set|get <device> <reading> <value>
    ein set <device> on - wär dann ungültig - oder ein spezialfall!
    einen andern weg geht z.B. das GAEBUS Modul, allerdings sind da die möglichen Variablen=reading-namen und deren Parameter,Definitionen in einer externen csv-datei definiert.
    Könnte man evtl. aus der ETS generieren,  so richtig gefällt mir das nicht, auch wenn es das coding etwas einfacher machen würde. 
2) ich würde die ganzen on-for-timer, toggle,slider... funktionen rausschmeissen, und durch die standard fhem funktionen ersetzen.

Bitte betrachte das jetzt mal als input zur diskussion, nicht als Vorgabe!
l.g. erwin
FHEM 5.7 auf RaspberryPI mit Busware ROT
CUNO2 V 1.44 CUNO868 SLOWRF - HMS100xx, FS20, FHT
1-Wire über ROT - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT-DEVICES, KNX - EIBD

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #3 am: 14 Dezember 2017, 08:27:55 »
Moin!

Verstanden - geht auch in meine Denkrichtung.

Allerdings würde ich nicht zwischen get und set bei der Definition unterscheiden - grundsätzlich kann jeder DPT ja beides. Physikalisch auseinandersortieren kann ich dann mit den resultierenden Readings...

Bsp. (analog heute):
1/2/3:dpt1:Automatik 4/5/6:dpt1:Manuell 7/8/9:Rueckmeldung

Führt zum Beispiel zu:
Automatik-get on
Manuell-set off
Manuell-get off
Rueckmeldung off

Was spricht aus Deiner Sicht dagegen?

P.S.: Wie sähe Deine alternative Implementierung zu einem on-for-timer aus?

« Letzte Änderung: 14 Dezember 2017, 08:30:38 von Andi291 »

Offline erwin

  • Full Member
  • ***
  • Beiträge: 364
Antw:Schnittstellenänderung
« Antwort #4 am: 14 Dezember 2017, 09:16:58 »
Hi Andi,

wenn man bei der definition zwischen set u. get unterscheiden kann, dann sind die readingnamen völlig frei vergebbar, also ohne set/get suffix. - das könnte evtl. optional sein -Fallback wie bisher.
man könnte auch listen-only, read-only dort unterbringen und damit per GA verfürbar machen.
Zitat
Wie sähe Deine alternative Implementierung zu einem on-for-timer aus?
siehe setextensions.pm
Verwendet z.B. im Modul 10_FS20.pm

l.g. erwin
« Letzte Änderung: 14 Dezember 2017, 09:28:04 von erwin »
FHEM 5.7 auf RaspberryPI mit Busware ROT
CUNO2 V 1.44 CUNO868 SLOWRF - HMS100xx, FS20, FHT
1-Wire über ROT - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT-DEVICES, KNX - EIBD

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #5 am: 14 Dezember 2017, 10:39:25 »
Elltert hat vor einigen Wochen mit wenigen Zeilen Codeergänzung die meisten "dummy" features in das DOIF-Modul übernommen.
Das Ergebnis: Man benötigt keine dummys mehr, wenn man DOIF verwendet.

Meine große Bitte wäre: Das auch in KNX einzug halten zu lassen! Die Verdopplung vieler Device würde ich gerne abschaffen.

Folgendes hat Ellert mir dazu geschrieben:

im einfachsten Fall reicht es die Zeilen 48 - 57 aus dem Dummy ans Ende der SetFn zu kopieren, die Variablen müssten auf KNX angepasst werden und die Attribute der Attributliste zugefügt werden.
Ob das bei KNX mit wenig Aufwand geht, kann ich nicht beurteilen, da ich kein KNX verwende.

Schöne Grüße

Ellert
« Letzte Änderung: 14 Dezember 2017, 10:51:55 von JoeALLb »
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

Offline obi

  • New Member
  • *
  • Beiträge: 10
Antw:Schnittstellenänderung
« Antwort #6 am: 14 Dezember 2017, 10:59:42 »
Hallo,

ich fände es erst einmal gut wenn man bei Set den Name der Gruppenadresse verwenden könnte dies wär etwas übersichtlicher als Gruppennummer.

Ansonnsten finde ich es mit den set/get suffix der Readings so ok wie es jetzt ist. Wenn dies geändert werden sollte dann bitte mit Fallback :)


Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #7 am: 15 Dezember 2017, 19:48:39 »
Servus Erwin!

Um es zu konkretisieren:

Zitat
siehe setextensions.pm
Verwendet z.B. im Modul 10_FS20.pm

Setextensions sind ja schon des längeren drin - fehlt da noch was?

Das andere Thema - die Readingnamen...
So ganz sehe ich den Sinn noch nicht mich beim Anlegen auf ein set oder get festlegen zu müssen.
Wie gehst Du mit GAD um, die lesen und schreiben? Und wie löst Du dahingehend die Events auf?
Ein Punkt wäre listenonly/readonly GAD-spezifisch zu machen.

Bsp.:
define bullshit KNX 1.2.3:dpt1:meinNameIstHase:listenonly
@JoeALLb:

Ein wenig konkreter, bitte. Im Modul 98_DOIF.pm stehen in den genannten Zeilen noch Variablendefinitionen, kein Code.
Welche Erweiterungen möchtest Du denn genau haben?

Grüße, Andi

Offline erwin

  • Full Member
  • ***
  • Beiträge: 364
Antw:Schnittstellenänderung
« Antwort #8 am: 16 Dezember 2017, 16:07:43 »
Hi Andi,

sorry, das hatte ich übersehen, dass setexensions schon drin waren, was ich aber gemeint hatte ist, das damit einiger code überflüssig geworden ist, - weil duch setexensions abgedeckt! (on-for timer gibts z.B. in set-pulldown jetzt 2 mal) . Ebenso gibst in fhem auch die generische slider funktion, damit wär auch dieser code-Teil obsolet.

Die Readingnamen: sind Geschackssache, wenn du der Meinung bist das die Änderung zu intensiv dadurch wird, hab ich kein Problem mit der bisherigen Implementation.
Ich hätte 2 Vorteile gesehen:
1) Namen frei vergebar (ohne -set/get suffix)
2) einfache realisierung der Set/Get Pull-down's im Detail-fenster
    das set-pulldown ist ja bisher komplett generisch - ohne Rücksicht ob für diesen dpt valid, das Get-pulldown gibts dzt. gar nicht.
Sinnvollerweise müsste man da eine Rückwärtskompatibilität einbauen, also wenn im def der 4.parameter nicht vorkommt: alles wie bisher....und die Frage ist, ob das dann noch sinnvoll ist!

GAD die set und get unterstützen: Ich hab keine einzige, aber selbstverständlich ist das im standard vorgesehen!
Unterscheiden würde ich nach "Herkunft" - aus der set-funktion ist's ein write zum BUS, aus der parse-funktion kommts vom BUS.
Die SET und GET ist in fhem m.M. nach nicht so klar definiert (und in unterschiedlichen Modulen sehr verschieden implementiert): z.B ist folgendes ein SET oder GET?:
1) ich schicke einen request von fhem auf den BUS, der unmittelbar/zwingend eine Antwort erwartet? (Z.B. Wie spät ist es?).
2) Ein KNX Device schickt periodisch die Uhrzeit auf den BUS
3)Im Unterschied zu: Schalte Lampe xyz ein?

zum Thema von JoeALLb: ich glaube er meint die Zeilen im dummy Modul... Wenn ich das richtig vertehe, soll für jedes set ein event ausgelöst werden, was beim KNX Modul ohnehin der Fall ist. Allerdings hab ich mich mit dem DOIF noch nie beschäftigt, daher lieber auf die Antwort von JoeALLb warten!   
l.g. erwin
FHEM 5.7 auf RaspberryPI mit Busware ROT
CUNO2 V 1.44 CUNO868 SLOWRF - HMS100xx, FS20, FHT
1-Wire über ROT - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT-DEVICES, KNX - EIBD

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #9 am: 16 Dezember 2017, 16:49:38 »
Hallo Erwin!

Du sprichst mir in Teilen aus der Seele :-)

Die Hauptänderung wird sein, die Set-List um die einzelnen GAD zu erweitern und entsprechend der DPT auch die dahinter liegenden Dropdowns anbieten zu können.
Quick-and-dirty hab ich dies bereits für die get-Funktion gemacht.
Richtig ist, dass ich aus Gründen der RÜckwärtskompatibiliät beides zulassen muss - die setlist also redundant befüllen muss...

Beispiel:
define feuerFrei 1/2/3:dpt5:finde 4/5/6:dpt19:mich
alte Syntax (hier wird wegen Schlüsselwort value geprüft, ob es sich um einen numerischen Wert handelt):
set feuerFrei value 17
set feuerFrei value 18 g2

neue Syntax (prüft exakt gegen das Regex aus dem Define - wesentlich genaur):
set feuerFrei finde 17
set feuerFrei mich 18

Den alten sums muss ich halt mitziehen...

Ggf. kann ich die set-listen über ein Attribut maskieren. Oder die set-listen leer lassen, die alte Syntax aber weiterhin zulassen.

Schau Dir bitte mal die getlist von dem obigen Beispiel an...

Grüße, Andi

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #10 am: 18 Dezember 2017, 09:56:32 »
@JoeALLb:

Ein wenig konkreter, bitte. Im Modul 98_DOIF.pm stehen in den genannten Zeilen noch Variablendefinitionen, kein Code.
Welche Erweiterungen möchtest Du denn genau haben?

Hallo Andi,

Ich benötige für meine DualWhite-Aktoren mehrere Slider und Schiebebalken. Das wäre toll, wenn ich nicht nur einen direkt im KNX-Device definieren könnte.

Ergänzung: Im Dummy oder eben auch DOIF kann ich setList und readingList mehrere Slider einfach definieren.
Simples Beispiel:

defmod wz.LichtTMP DOIF ([$SELF:kw])\
  (set eg.wz.deckenlicht value [$SELF:kw] g8)\
DOELSEIF([$SELF:ww])\
  (set eg.wz.deckenlicht value [$SELF:ww] g9)
attr wz.LichtTMP DbLogExclude .*
attr wz.LichtTMP do always
attr wz.LichtTMP readingList ww,kw
attr wz.LichtTMP setList top:colorpicker,HSV\
shade:colorpicker,CT,2700,50,5000\
kw:colorpicker,CT,0,1,100\
ww:colorpicker,CT,0,1,100\

attr wz.LichtTMP stateFormat kw
attr wz.LichtTMP webCmd kw:ww


sG
Joe
« Letzte Änderung: 18 Dezember 2017, 15:56:04 von JoeALLb »
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

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #11 am: 25 Dezember 2017, 18:19:32 »
Hallo,

ich würde es gut finden, bei set und get Befehl auch den Gruppennamen verwenden zu können. Dazu habe ich mir aktuell einen Workaroud mit cmdalias gebaut, den ich gerade heute im Forum gepostet habe. Wäre performanter, das direkt im Modul zu können.

Bei den Readings habe ich den ganz klaren Wunsch, die getrennten -set und -get Readings so zu lassen, wie sie sind.
-set liefert mir den letzten Wert, den ich auf den Bus für diese GA gesendet habe.
-get liefert mir den letzten Wert, den ich vom Bus für diese GA empfangen habe.
Sehr häufig verwende ich beides für ein und dieselbe GA. In meinem System kann ich z.B. Temperaturverschiebung der Heizaktoren lokal vom Raumcontroller oder zentral über FHEMWEB einstellen, will dabei aber auch in FHEM mitbekommen, wenn dezentral eine Temperaturverschiebung gesendet wird.

Akktuell baue ich mir für die einfachere Integration mit FHEMWEB sogar jeweils noch ein drittes Reading. Ich verwende dazu die Endung -web. Dieses verwende ich zur Bindung an Widgets Bspw. für die GA solltemperatur habe ich die Readings
solltemperatur-get
solltemperatur-set
solltemperatur-web

Warum so? Über solltemperatur-web erhält das Widget seinen Anzeigewert.
Wenn ich am Widget eine Auswahl treffe, z.B. 24.0, wird diese nicht automatisch auf den KNX gesendet. Sondern ich habe zunächst noch die Kontrolle im Programm, wo ich abhängig von weiteren Bedingungen entscheiden kann, ob und was ich tatsächlich sende. Ich leite dazu den vom Widget generierten "set myDevice solltemperatur-web 24.0" Befehl auf ein cmdalias um. Ein weiterer Grund für das -web Reading sind Einheiten. Die -get und -set Readings enthalten Einheiten, die Widgets wollen eher keine Einheit. Jetzt könnte man bei einer Interface-Änderung die Einheiten natürlich wegnehmen. Aber das führt gewiss zu Inkompatibilitäten in Altinstallationen.

Letztendlich muss ein KNX Device auf zwei Arten von Ereignissen reagieren können
1. Bedienungen auf der Weboberfläche, die Kommandos auslösen -> bei mir heute über cmdalias
2. Events vom KNX-Bus -> bei mir heute über notify

Was ich mir noch wünschen würde:
- In den Gruppennamen zwischen Groß- und Kleinschreibung unterscheiden. Das steht besser im Einklang mit Perl und mit anderen FHEM Modulen.
- Beim Autocreate eine zur Länge des Telegramms passende dpt setzen. Damit sich das neue KNX Modul erst einmal gutmütig verhält und nicht bei jeder empfangenen Botschaft Fehlermeldungen ins Log geschrieben werden.

Viele Grüße
Andreas


Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #12 am: 04 Januar 2018, 20:47:35 »
Hallo und gutes neues Jahr!

Ein Wunsch: Schön wäre, wenn das Modul die Export-XML aus der ETS5 mit den Gruppenadressen importieren könnte, um die DPTs
direkt einzutragen und eventuell sogar aus dem Bezeichnungen Aliase generieren könnte....
Eventuell würde es auch Sinn machen, das Sende-Device irgendwie mit rein zu bekommen, um so manche GAs gruppieren zu können,
aber das würde wohl recht aufwendig werden ;-)

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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #13 am: 04 Januar 2018, 21:10:17 »
Ja, das würd ich mir auch wünschen :-)
Ich hab da tatsächlich mal was versucht - aber das sprengt jeglichen Rahmen!

Solch eine Brücke, idealerweise sogar als ETS-Plugin, wäre ein Quantensprung. Und zwar nicht nur für FHEM, sondern die ganze Visualisierungswelt.
Leider übersteigt das meine Möglichkeiten bei Weitem...

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #14 am: 05 Januar 2018, 07:51:24 »
Halo zusammen und noch ein frohes neues Jahr!

Technisch könnte man das schon angehen. Aber erstmal braucht es eine Grundidee, wie es funktionieren soll.
Es sollen ja am Ende "zusammengehörende" GAs auf das selbe FHEM KNX Device gemappt werden. Und hier gibt es verschiedenste Fälle.
In der realen Welt haben KNX Aktoren ja häufig mehrere Kanäle mit gleicher Funktion. Das will zumindest ich nicht 1:1 in FHEM abbilden. Ich habe lieber mehrere unabhängige "Licht" KNX Devices als einen 4-Kanal Dimmaktor. Oder manchmal auch etwas stärker aggregiertes, z.B. "Heizung Bad" als ein KNX Device, wobei dann ein Kanal eines n-Kanal Heizungsaktors,  ein Temperaturgeber aus dem Raumcontroller, ein Kanal eines Schaltaktors (Handtuchheizung) und diverse Bedienelemente zusammenwirken. Hier sehe ich keinen Automatismus, der mir die "richtigen" Signale in ein Device mappt.

Wir sollten aber mindestens in der Lage sein, eine exportierte Liste der GAs mit dpt und Namen im FHEM zu importieren, so dass man dann beim Anlegen eines FHEM Devices per Klick aus einer Liste der vorhandenen GAs auswählen kann. Und hat dann gleich den richtigen dpt und Namen für das Signal.

Muss aber gleich noch zu bedenken geben, dass die ETS möglicherweise gar nicht alle GAs kennt, wenn man Devices am KNX hat, die nicht über ETS konfiguriert werden (z.B. Raspis mit FHEM). Also muss es immer manuell möglich sein, GAs zu vergeben, bzw die Liste manuell zu verändern. Man will ja vielleicht auch gar nicht alle GAs in FHEM verwenden, sondern nur ein Subset.

Ich denke mal weiter darauf rum.
Viele Grüße
Andreas

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #15 am: 05 Januar 2018, 08:10:57 »
Die Funktion könnte schlicht alle KNX devices aus FHEM und alle neuen Devices aus dem ETS Export anzeigen, dann wäre dein ABER schon kein Problem mehr.
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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #16 am: 05 Januar 2018, 11:19:49 »
Oder die pflicht, alle GA in der ETS anzulegen. Auch die "leeren" vom raspi.
So mach ich das zumindest. Versteht ja sonst keiner mehr 😉

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #17 am: 05 Januar 2018, 12:18:08 »
Jemand ohne ETS sollte das Modul halt auch nutzen können ;-)
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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #18 am: 05 Januar 2018, 16:27:43 »
Da sind wir uns denke ich einig. Ein Assistent kann nur ein addon sein.
Definition zu Fuß (wie heute) muß immer möglich bleiben...

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #19 am: 10 Januar 2018, 21:01:46 »
Aktueller Stand - Ich habe begonnen, die Datenstrukturen im DeviceHash umzubauen.
Den Get-Pfad hab ich schon so umgebaut, wie ich ihn mir im Ziel vorstellen könnte - also Fokus mit Bedienung per GAD-Name. Für den Rüko-Pfad wäre eine Bedienung mit "g<n>" noch möglich.

Feedback?
« Letzte Änderung: 10 Januar 2018, 21:26:04 von Andi291 »

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #20 am: 16 Januar 2018, 20:06:14 »
Hallo Andi,

kurzes Feedback:

Ich finde es super, wenn ein Zugriff bei get und set über Readingnames möglich wird anstelle g1, g2, g3.

Ich finde es nicht so toll, wenn die hash-Struktur verändert wird. Das hat weitreichende Auswirkungen und würde z.B. bei mir im System einigen Änderungsaufwand an Perl-Skripten mit sich bringen.

Viele Grüße
Andreas

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #21 am: 18 Januar 2018, 22:05:28 »
Noch ein Wunsch, was man verbessern kann:
Die dpt1 Untertypen haben ja oftmals Werte, die nicht "on" oder "off" heißen, sondern z.B. für dpt1.008 "down" und "up".
Beim Set Kommando würde ich doch in diesem Fall auch lieber "down" angeben wollen anstelle von "on".
Kann man sich natürlich in jedem Einzelfall per eventMap bauen, aber das KNX-Modul kennt ja die zulässigen Werte für den dpt und könnte es daher auch automatisch ohne eventMap machen. Für die Rü-Ko müssten natürlich "on" und "off" weiter akzeptiert werden.
Viele Grüße
Andreas

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #22 am: 27 Januar 2018, 10:16:10 »
Hallo Andi291,
sollen wir das ganze mal gemeinsam angehen?
Hier mein Vorschlag, was wir implementieren
set <device> <groupname> <value>
get <device> <groupname> <value>
Möglichkeit, bei "set" die Werte im gleichen Format anzugeben, wie sie im Reading angezeigt werden, also z.B. "up" "down"
Einführung von -put Readings. Wenn vom knx eine GA des Devices gelesen wird und ein -put Reading existiert, wird dieser Wert auf den Bus ausgegeben und nicht state.
set and put  <device> <groupname> <value> -> schreibt den Wert zusätzlich ins -put Reading
attr putCmd -> Perl Code, der aufgerufen wird, wenn von knx aus eine GA ausgelesen wird, bevor das Device antwortet.
ein FHEM-Event, der ausgelöst wird, nachdem vom knx eine GA gelesen wurde und das Device geantwortet hat. 
attr setList -> zur besseren Integration mit Widgets
<groupname> soll case-sensitive werden. Dann brauchen wir aber einen Schalter, um das wieder abzustellen für RüKo. Es könnte nämlich sein, dass Nutzer heute bei den groupnames Groß- und Kleinbuchstaben mischen, die ja dann für die Readings auf Kleinbuchstaben gemappt werden.

Die interne Datenstruktur muss aus Kompatibilitätsgründen gleich bleiben. Wir können sie aber um weitere Elemente ergänzen, die einen effizienteren Zugriff über <groupname> ermöglichen. Ich weiß, dir gefällt dieser Punkt nicht. Aber ich sehe für viele User potenzielle Probleme, wenn wir die alte Datenstruktur nicht mehr unterstützen.

TUL fassen wir jetzt nicht an. Hat zu große Auswirkungen auf bestehende Installationen ohne echten Mehrwert. Man könnte unabhängig von der knx Erweiterung mal überlegen, was es an TUL zu verbessern gibt. Es gibt bei der Konfiguration immer mal wieder Probleme für den Anfänger. Außerdem ist TUL nicht 100% robust, wenn das Netzwerk zum knx-IP-Gateway, oder das Gateway selbst nicht verfügbar ist. Ein Kommando, um die Verbindung zu testen, wäre manchmal ganz hilfreich. Aber lass uns das alles erstmal ausklammern.

Gibt es weitere Themen, die noch mit aufgenommen werden sollen?

Wie machen wir jetzt konkret weiter?

Viele Grüße
Andreas

Offline EIB-Fan

  • Full Member
  • ***
  • Beiträge: 132
Antw:Schnittstellenänderung
« Antwort #23 am: 27 Januar 2018, 10:42:13 »
Hallo Andi291,

viele beschriebene Änderungen sehe ich ebenfalls an sinnvoll an.

Einige Änderungen scheinen nicht so innovativ durchgeführt werden zu können, da Kompatibilitätsgründe dagegen sprechen.

Mein Gedanke dazu ist, das bisherige KNX-Modul in der aktuellen Version "einzufrieren" und ein völlig neues Modul z.B. KNXv2 zu programmieren.

Was hälst du davon?

Gruß Jens

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #24 am: 27 Januar 2018, 11:09:49 »
Hallo EIB Fan
ich frage mich ernsthaft, welche innovativen Dinge denn im KNX Modul nicht möglich sein sollen.
Eine Neuordnung der internen Datenstruktur hat m.E. hauptsächlich für den Programmierer ästethische Gesichtspunkte. Für den Anwender bringt das nichts.
Ich würde es echt für einen Fehler halten, jetzt ein KNXv2 Modul zu machen und damit die User-Gemeinde abzuhängen, bzw. zu spalten.
Es gibt heute noch genügend Anwender, die das EIB-Modul nutzen. Auch sie haben noch Supportbedarf.

Natürlich ist es aus Sicht des Modulentwicklers immer einfacher, auf der grünen Wiese neu anzufangen, weil man sich dann nicht um die Vergangenheit kümmern muss. Ich glaube aber in diesem Fall hier - ich habe den Code des KNX-Moduls mittlerweile ganz gut verstanden - besteht gar keine Notwendigkeit alles umzuschmeißen und die Aufrechterhaltung der Kompatibilität ist nicht sonderlich schwierig.

Also mein Vorschlag ist, das vorhandene Modul weiterzuentwickeln und kein neues aufzusetzen.
Da würde ich auch sofort mitarbeiten.

Viele Grüße
Andreas

Offline Löwenzahn

  • New Member
  • *
  • Beiträge: 26
Antw:Schnittstellenänderung
« Antwort #25 am: 27 Januar 2018, 11:24:13 »
Ja, ich kann mich noch gut erinnern, wie ich meine Definitions usw. auf das knx Modul heben musste. :o
Somit wäre es psychologisch wohl nicht so gut wieder ein ganz neues Modul einzuführen?!

Gleichzeitig muss ich gestehen daß mir der Vorschlag mit dem put Reading noch nicht einleucht. Ich habe es zwar verstanden, sehe aber das Szenario ich nicht, wo man das benötigt.
Gruß Löwenzahn

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #26 am: 27 Januar 2018, 20:54:22 »
Servus!

Die genannten Vorschläge hab ich größtenteils auf dem Schirm.
Einen Teil hab ich schon umgesetzt, hab aber im Moment wenig Zeit. Ostern kann ich mich mal wieder länger konzentrieren.

@docm:
Die Datenstrukturen wird ich dennoch anpacken - da finden wir leider keinen Konsens :-(
Beim zweiten Punkt bin ich bei Dir. Die TUL bleibt, wie sie ist. In einem weiteren Schritt werd ich ein knxd-modul bauen - muss mich dazu mal mit smurfix abstimmen, ob man einige Konfigurationsoptionen nach FHEM hoch holen kann. Das macht es - denke ich - einigen Usern einfacher. Den Schritt heb ich mir aber für kommenden Winter auf :-)

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #27 am: 10 Februar 2018, 11:40:28 »
Hallo Andi291 und andere Interessierte,
ich stelle hier mal eine Variante von KNX ins Forum, die folgende Zusatzfunktionalität liefert:
Man kann Readings vom Typ groupname-put bzw putGn erstellen, analog zu den automatisch erstellten -get und -set Readings.
Wenn man das getan hat, kriegt das Modul ein neues Verhalten bezüglich Leseanfragen vom knx Bus.

Das Standardverhalten ist ja, dass das Modul den Wert von state sendet, wenn das Attribut answerReading gesetzt ist. Und zwar egal, welche GA des Moduls gelesen wird.

Das neue Verhalten ist: Wenn die zu dem -put Reading passende GA vom KNX ausgelesen wird, liefert das Modul den Wert des -put Readings an den Bus. Unabhängig vom Attribut answerReading.

Neues und altes Verhalten können auch parallel genutzt werden. Dann liefert das Modul den Wert von state nur dann, wenn zu der angefragten GA kein -put Reading existiert, ansonsten das -put Reading.

Ein weiteres neues Feature in diesem Zusammenhang ist das Attribut putCmd. Diesem kann - analog zu stateCmd - ein Perl Code zugewiesen werden. putCmd wird angesprungen, wenn vom Bus aus ein -put Reading angefordert wird und bevor das -put Reading ausgegeben wird.
Im Perlcode stehen folgende Variablen zur Verfügung
$name - Name des Moduls
$reading - Name des abgerufenen -put Readings
$value - Wert dieses Readings
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.

Nach dem Senden eines -put Readings auf den Bus wird ein "KNX response" Event erzeugt, der z.B. über ein notify aufgegriffen werden kann.

Schaut euch das gerne mal an. Über Rückmeldungen würde ich mich freuen.

Viele Grüße
Andreas
 


Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #28 am: 10 Februar 2018, 13:23:51 »
Das ist eine toller Ergänzung, damit kann ich endlich auf die Abfragen meiner Heizungsthermostate nach einem KNX Ausfall ordentlich reagieren... Ein erster schneller Test scheint vielversprechend.

DANKE!
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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #29 am: 10 Februar 2018, 18:28:17 »
Das ist eine toller Ergänzung, damit kann ich endlich auf die Abfragen meiner Heizungsthermostate nach einem KNX Ausfall ordentlich reagieren... Ein erster schneller Test scheint vielversprechend.

DANKE!
Puh, Mammutergänzung. Danke, kommt auf den Stapel...

Gesendet von meinem XT1580 mit Tapatalk


Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #30 am: 12 Februar 2018, 08:07:07 »
Ein weiteres neues Feature in diesem Zusammenhang ist das Attribut putCmd. Diesem kann - analog zu stateCmd - ein Perl Code zugewiesen werden. putCmd wird angesprungen, wenn vom Bus aus ein -put Reading angefordert wird und bevor das -put Reading ausgegeben wird.

:D ein sehr tolles Feature. Damit kann ich endlich komfortabel meine Temperatursensoren, je nach Wetter und Sonneneinstrahlung von Estrichsensor auf Raumsensor oder Deckensensor umstellen oder jegliche Mischtemjperatur aus 2 Sensoren berechnen....
ich nutze das um in der Übergangszeit den Boden auf angenehmer Barfuß-Temperatur zu halten, ohne den Raum merklich zu heizen!

DANKE!!
« Letzte Änderung: 12 Februar 2018, 10:58:34 von JoeALLb »
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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #31 am: 12 Februar 2018, 08:09:49 »
Puh, Mammutergänzung. Danke, kommt auf den Stapel...

Hm, bedeutet das, dass wir aktuell 3 Branches vom KNX-Modul bekommen? (original, den dieser Schnittstellenänderung und den von docm)?
Sollte ich dann diese Version noch nicht großflächig nutzen und nur in einer eigenen FHEM-Version für die Heizung nutzen,  da diese nicht weiterentwickelt wird?

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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #32 am: 12 Februar 2018, 12:28:49 »
Hm, bedeutet das, dass wir aktuell 3 Branches vom KNX-Modul bekommen? (original, den dieser Schnittstellenänderung und den von docm)?
Sollte ich dann diese Version noch nicht großflächig nutzen und nur in einer eigenen FHEM-Version für die Heizung nutzen,  da diese nicht weiterentwickelt wird?

sG
Joe
Hallo Joe!
Richtig. Bitte noch nicht flächig umstellen. Ab Ostern ist hoffentlich alles wieder in einem Pfad...

Gesendet von meinem XT1580 mit Tapatalk


Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #33 am: 12 Februar 2018, 23:12:34 »
Hallo,
ja wir müssen den Code in einem Branch zusammenhalten. Das ist jetzt die erste Hälfte der Neuerungen. Der zweite Teil wäre dann das Ansprechen der GAs über Namen statt G1, G2 usw. Den Code dafür habe ich bereits in Form von cmdalias implementiert. Muss man nur noch in den Modulcode übertragen, was ich gerne in den nächsten Wochen tun würde.
Dann wäre da noch der Wunsch nach readingsList Support, wobei ich noch ein paar Fragen habe, welche Funktionalität genau gewünscht ist.
Schließlich möchte Andi291 noch die internen Datenstrukturen reorganisieren. Das sehe ich zugegebenermaßen skeptisch, weil viel Arbeit ohne unmittelbaren Nutzen für den Anwender und birgt Gefahr, dass neue Bugs reinkommen. Aber wenn dadurch die Pflegbarkeit des Codes besser wird, werde ich es mit unterstützen.
Mein Vorschlag wäre: Ich baue die genannten Erweiterungen bis Ende Februar komplett ein und werde Testversionen hier ins Forum stellen. Dann übernimmt Andi291 ab März und fügt seine Änderungen ein. Wir machen gegenseitig Quality Check und haben dann Richtung Ostern ein neues Release.
Was haltet ihr davon?

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #34 am: 13 Februar 2018, 07:58:40 »
Hallo!

Dann wäre da noch der Wunsch nach readingsList Support, wobei ich noch ein paar Fragen habe, welche Funktionalität genau gewünscht ist.
Welche Fragen?

Ein Beispiel aus meinem aktuellen Projekt:
Im Prinzip würde es hier reichen, wenn ich mit
attr xy widgetOverride kw:colorpicker,CT,0,1,100
attr xy readingsList kw
die Lichtfarbe einstellen könnte, und danach
"set <device> kw 100"
eingeben könnte. Das geht im Moment auch schon über ein eher komplexes eventMap

{
usr=>{
  '^kw.?(\d*)' => 'value $1 g8',
 },
fw=>{
  '^kw.?(\d*)' => 'kw',
 }
}

habe jedoch keinen Einfluss mehr auf die Werte.

mit

attr xy readingsList kwbräuchte ich kein eventMap und könnte in den userReadings auf die Eingabe reagieren und damit zB MEHRERE GAs problemlos senden.


Im übrigen sollte man folgende Felder standardmäßig mit großen Textfeldern belegen,
analog zu anderen Modulen:

devStateIcon:textField-long
stateCmd:textField-long
stateRegex:textField-long
eventMap:textField-long
widgetOverride:textField-long
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

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #35 am: 13 Februar 2018, 08:56:18 »
Gib mal bitte ein Beispiel zu den userReadings, wie du da mehrere GAs senden willst.
kw wäre bei dir im Beispiel ein "normales Reading", kein userReading, oder?
Nach meinem Verständnis von userReadings handelt es sich um solche, deren Wert automatisch berechnet werden, sobald sich irgendwelche anderen Readings ändern. Würdest du dann aus dem Code des userReadings heraus wiedeum GAs senden, sehe ich die Gefahr von Endlosschleifen
GA senden -> reading-set update -> userReading update -> GA senden ...
Oder habe ich hier etwas falsch verstanden?
Danke
Andreas

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #36 am: 13 Februar 2018, 09:06:38 »
Nach meinem Verständnis von userReadings handelt es sich um solche, deren Wert automatisch berechnet werden, sobald sich irgendwelche anderen Readings ändern.
Du hast recht, ich meine eigentlich "setList" (zB aus dummy oder DOIF). Sorry.

Beispiel eines Userreadings; Hier zähle ich den Verbrauch und setze einen Wert hoch.
Da bei jedem KNX-Restart (stromlos setzen des knx-trafos) "getG1" wieder bei 1 beginnt, nehme ich hier die monotonic Funktion.
verbrauch:getG1.* monotonic {
  return ReadingsVal("$name", "getG1", "") ;
}

wenn jetzt jedoch "verbrauch" und der tatsächliche Zählerstand auseinanderläuft, könnte ich wenn
attr xy setList verbrauchgesetzt ist, einfach mit

set xy verbrauch 123456 den korrekten Zählerstand eintragen.

Im Moment muss ich dafür halt einen gewissen Handstand machen (aber es geht auch).


Ein Beispiel für 2 GAs reich ich später nach. Die gefahr von Endlosschleifen habe ich in FHEM an sehr vielen Stellen... da würde ich nicht allzuviel wert drauf legen, ehrlich gesagt.
Richtig konfiguriert funktioniert es ja.

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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #37 am: 13 Februar 2018, 21:59:53 »
Moin zusammen!

@Andreas:
Find ich super. Gib mir bitte noch ne Woche, dann ist "set" auch umgebaut. "Define" und "get" hab ich schon. Dann hast was sauberes zum Aufsetzen...

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #38 am: 14 Februar 2018, 07:36:38 »
Hallo Andi291,
gut, mach es so. Dann kann es natürlich sein , dass ich ein paar Tage länger brauche, weil mein aktueller Code auf die jetzige Datenstruktur ausgelegt ist.

Noch folgender Tipp: Wenn es darum geht die Performance zu steigern, dann muss vor allem KNX_Parse($$) optimiert werden. Diese Funktion führt für jede von TUL empfangene GA eine (äußere) Schleife über sämtliche KNX Devices durch und prüft in einer (inneren) Schleife, ob das Device diese GA kennt und verarbeitet.

Wenn der Hash so aufgebaut ist {Modul_Wurzel}->{Device_Wurzel}->{GA_numerisch}->{gname,gno,dpt...}, dann kann auf die innere Schleife ganz verzichtet werden. Ich hatte aber verstanden, dass dein Ansatz {Modul_Wurzel}->{Device_Wurzel}->{gname}->{GA_text,gno,dpt...}. Damit ist aber die innere Schleife unvermeidlich und es ist nicht performanter als die aktuelle Datenstruktur.

Du könntest, um KNX_Parse($$) zu boosten zusätzlich noch einen weiteren Hash einführen {Modul_Wurzel}->{"GA"}->{GA_numerisch}->{Liste der Devices für diese GA}
Dann entfällt auch die äußere Schleife beim Parsen der GA.

Wäre super, wenn du das so berücksichtigst. Dann erreichen wir eine echte Performancesteigerung. In einer typischen FHEM-KNX Installation wird KNX_Parse bestimmt 10x häufiger aufgerufen als KNX_set und 100x häufiger als KNX_get. Eigentlich jedes Mal, wenn auf dem KNX-Bus eine GA unterwegs ist und zwar unabhängig davon, ob sie in FHEM überhaupt von irgend einem Device ausgewertet wird.

Viele Grüße
Andreas

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #39 am: 14 Februar 2018, 10:29:32 »
Grüß Euch....

Ich suche noch nach einer Möglichkeit, einen Vorlauf-Rücklauf-sensor zu deaktivieren, bzw. keine Werte zu aktualisieren, während das Ventil geschlossen ist.
In dieser Zeit stimmen die Werte nicht und nähern sich eher der Umgebungstemperatur an.
Also suche ich so etwas ähnliches wie ein Sperrobjekt... habt ihr dazu eine Idee?

Wenn ich den status loggen würde, könnte ich es in stateCmd einbauen, das halte ich jedoch eher für "unelegant".

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

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #40 am: 14 Februar 2018, 19:44:02 »
Wie wäre es mit folgendem Ansatz:
Vorlauf-Rücklauf-Sensorwert als UserReading, dieses auf das -get Reading hin aktualisieren, dabei Ventilzustand berücksichtigen.
Gruß
Andreas
P.S: Die Frage gehört nicht in den Schnittstellen-Thread

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #41 am: 14 Februar 2018, 20:38:32 »
Servus Andreas!

Ja, da dachte ich auch schon dran.
Hab noch keine ausdetaillierte Lösung, aber ich glaube, wenn ich den defptr von $Name auf $gad umstelle, geht's gänzlich ohne äußere Schleife.
Die innere Schleife wäre weiterhin nötig, um die einzelnen GA durchzugehen.

Wird aber um Dimensionen schlanker...

Wenn Du noch Ideen zum Zeit überbrücken brauchts ( :D) - hast Du Dich schon mal mit den Möglichkeiten der Konfiguration befasst?
Ich hab immer noch die Vision von einem Wizard samt ESF-Input...


Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #42 am: 14 Februar 2018, 20:42:18 »
P.S.:
Was auch noch offen ist, ist die Mehrfachdefinition von Slidern.
Ich bin noch unschlüssig, ob diese ins define gehören oder als Attribut definiert werden sollten.

Pro Definition:
Pro GAD kann ein SLider dfiniert werden

Contra Definition:
Die Def wird überladen
Es handelt sich nicht um Basiseigenschaften einer GAD, sondern um eine Eigenschaft der Visualisierung

Wenn als Argument, sollte es dann lauten
attr devName slider <gadName> 1,2,10?

Ist unschön, wäre aber leicht rückwärtskompatibel umzusetzen...
« Letzte Änderung: 14 Februar 2018, 20:46:14 von Andi291 »

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #43 am: 14 Februar 2018, 22:19:27 »
Zitat
wenn ich den defptr von $Name auf $gad umstelle, geht's gänzlich ohne äußere Schleife
Sorry, das verstehe ich nicht.
Heute liefert defptr eine Liste aller Devices vom Typ KNX. In KNX_Parse() wird für jedes dieser Devices geprüft, ob es die empfangene GA verarbeiten kann. Dies ist die "äußere" Schleife.

Sie lässt sich nur vermeiden, wenn zu jeder GA eine Liste aller KNX-Devices geführt wird, die diese GA verarbeiten können. Dann braucht man nur beim Empfang der GA diese spezifische Liste zu durchlaufen. Liste deshalb, weil es sein kann, dass dieselbe GA von mehreren KNX-Devices verarbeitet wird. Z.B. in meiner Installation ist dies häufig der Fall.

Du kannst also eine Sruktur der Art $modules{KNX}{defptr}{$gad}[Liste der Device-Hashes für diese GA] aufbauen. Ich würde in jedem Fall auf Device-Hashes und nicht auf die Device-Namen gehen, denn sonst wird das rename kompliziert.

Ist das nachvollziehbar?
Gruß
Andreas


Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #44 am: 15 Februar 2018, 08:35:52 »
P.S: Die Frage gehört nicht in den Schnittstellen-Thread
Das habe ich auch überlegt, da hier aber die Schnittstelle besprochen wird, diese immer mehr umgebaut wird um sie ähnlich wie ein
KNX-Hardwaredevice zu nutzen, dachte ich, wären hier auch gewisse quasi-"standardfunktionen" von anderen Devices sinnvoll zu bedenken,
wie zB eben auch Sperrfunktionen, zwangsstellungen, etc...

nichts für ungut ;-)

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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #45 am: 15 Februar 2018, 19:59:06 »
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...

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #46 am: 18 Februar 2018, 18:50:26 »
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

Offline docm

  • Jr. Member
  • **
  • Beiträge: 83
Antw:Schnittstellenänderung
« Antwort #47 am: 18 Februar 2018, 22:52:54 »
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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #48 am: 22 Februar 2018, 11:35:07 »
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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #49 am: 22 Februar 2018, 20:36:51 »
Die Schnittstelle kannst Dir gerne ansehen.
Die SetExtensions (on-for-timer, ...) gehen noch nicht, aber grundsätzlich läufts...

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #50 am: 17 März 2018, 17:01:22 »
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!!!

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #51 am: 18 März 2018, 06:55:16 »
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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #52 am: 19 März 2018, 14:48:35 »
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
« Letzte Änderung: 19 März 2018, 14:56:11 von JoeALLb »
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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #53 am: 19 März 2018, 21:02:38 »
Und wieder a bisserl stabiler...

Anbei mit der Bitte um Test und Feedback.

Grüße, Andi

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #54 am: 20 März 2018, 09:40:31 »
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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #55 am: 20 März 2018, 09:59:28 »
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...

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #56 am: 20 März 2018, 10:03:40 »
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.

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #57 am: 20 März 2018, 10:28:39 »
Hallo Andi,


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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #58 am: 20 März 2018, 10:34:44 »
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.

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

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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #59 am: 20 März 2018, 21:55:12 »
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?

Zitat
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?
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 :-)).

Zitat
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.
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.

Zitat
In 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...

Zitat
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.
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.

Zitat
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.
Gefixed...

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

In diesem Sinne: Weitermachen :-)

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #60 am: 20 März 2018, 22:46:28 »
Hier ein Screenshot

Edit: aber eigentlich bist du ja auf das selbe Ergebnis gestoßen wie ich, wenn ich deinen Text dazu korrekt interpretieren.
Da Klick ich jedenfalls drauf, wenn ich eine neue Erklärung zu den Attributen des aktuellen Devices benötige, darum fände ichH es schön und richtiger, wenn hier die Hilfe des KNX kommt.

Mehr morgen!
Danke!
SG Joe
« Letzte Änderung: 20 März 2018, 22:51:27 von JoeALLb »
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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #61 am: 21 März 2018, 09:44:19 »
Hallo Andi, danke!

Anbei ein erstes Feedback:
Zeile 1079
if (defined ($value) and !($value eq ""))dürfte nicht ganz passen, denn dadurch wird putCmd ja nicht ausgeführt?!? Wofür ist diese Prüfung hier gedacht?
Wenn ich diese Abändere ode rganz entferne, funktioniert es jedenfalls.


Edit: Zum test habe ich dieses Device verwendet und einfach mal die GAD 0/0/253
aus der ETS abgefragt. Ohne meine Änderung habe ich als Ergebnis den STATE-Wert zurückbekommen, mit
dem Entfernen des IFS bekam ich den $gad name, also test zurück.

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

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 18.03.2018
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-21 09:49:07 date-put 14.03.2018
setstate timedev 2018-03-20 09:47:57 last-sender 1/1/253
setstate timedev 2018-03-21 00:02:00 state 18.03.2018
setstate timedev 2018-03-21 09:45:00 test-put test
setstate timedev 2018-03-21 09:49:13 time-put 01:02:03
setstate timedev 2018-03-21 00:02:00 time-set 00:02:00


Edit2:
Was ich besonders praktisch finde ist, dass auch bei putCmd dies funktioniert,
was vermutlich in die Doku einzug nehmen sollte:
if ($gad =~ /date/) {
   $value=  "now";
}

@Andi: Verständnisfrage zu GETSTRING: Was steckt hinter den "test:noArg date:noArg time:noArg"? Kann/soll ich das zu etwas nutzen?

sG
Joe
« Letzte Änderung: 21 März 2018, 09:54:53 von JoeALLb »
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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #62 am: 21 März 2018, 10:21:15 »
Moin!

1. Deinen Screenshot zur Devicespezifischen Hilfe kann ich nicht nachvollziehen - habs bei drei Systemen probiert. Bei allen wird die KNX-Doku angezogen...Kannst Du hier nochmal nachschauen, ob Du einen potentiellen Fehler findest?

2. Deine Anmerkung zur Value-Abfrage...PutCmd soll nur ausgeführt werden, wenn das Argument gegeben ist ($value = ReadingsVal...). Dummerweise gibt Readingsval bei nicht definiertem Wert einen Leerstring und kein undef zurück - deshalb die Abfrage auf "". Bei mir funktionierte gestern die Unterscheidung auch sauber - hast Du ein Log zu Deinem u.g. Beispiel?

3. Gestring ... In der Vergangenheit wurden die Abfragen vom Webfrontend immer in get/set bearbeitet und die Antwortstrings gebildet. Das habe ich ins define ausgelagert und gespeichert - letztlich steht da die Vorgabe zur Darstellung der Checkboxen in der Detailseite:
return "Unknown argument, choose one of " . $hash->{GETSTRING} if(defined($a[1]) and ($a[1] =~ m/\?/));--> Dürfte Dir völlig wurscht sein...

Grüße...

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #63 am: 21 März 2018, 11:21:14 »
Hallo Andi,

1. Ich habe 2 Systeme, die alle dieses Phänomen zeigen.
2. aber manchmal ist ein Reading leer, also "". Selbst dann hätte ich gerne, dass putCmd ausgeführt wird...
3. Ist es mir eigentlich auch, jedoch steht dort bei "Vorlauftemperatur:slider,-670760,13415,670760", der als dpt9 genutzt wird, was den Slider relativ unbrauchbar macht....

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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #64 am: 21 März 2018, 20:23:11 »
Hm - da musst mir nochmal helfen...

Zitat
1. Ich habe 2 Systeme, die alle dieses Phänomen zeigen.
Kannst Du es bitte versuchen, einzugrenzen - siehe Anhang. Ich kann's nicht nachvollziehen...
Zitat
2. aber manchmal ist ein Reading leer, also "". Selbst dann hätte ich gerne, dass putCmd ausgeführt wird...
Verstanden - ich such einen Workaround.
Zitat
3. Ist es mir eigentlich auch, jedoch steht dort bei "Vorlauftemperatur:slider,-670760,13415,670760", der als dpt9 genutzt wird, was den Slider relativ unbrauchbar macht....
Ebenfalls verstanden - alternativ kann ich den Slider ganz weglassen - finde ich aber auch nicht schick. Eingrenzen macht wenig Sinn...Der Slider nach "Außen" wird jedenfalls skalierbar sein.

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #65 am: 22 März 2018, 08:42:02 »
Hallo Andi,

Kannst Du es bitte versuchen, einzugrenzen - siehe Anhang. Ich kann's nicht nachvollziehen...

Der Anhang fehlt leider. Hab bei mir in 2 weiteren Systemen nachgesehen, ein altes (>5 Jahre) und ein frisch installiertes:
Bei beiden bekomme ich die TUL-hilfe.

Verstanden - ich such einen Workaround.
Wofür wird die Zeile überhaupt benötigt? putCmd kann doch immer ausgeführt werden, egal ob value gesetzt ist oder nicht?!?
Die Prüfung prüft ja lediglich, ob hier ein entsprechendes -put Reading vorhanden ist, aber selbst ohne Reading sollte putCmd ausgeführt werden, nicht?

Ebenfalls verstanden - alternativ kann ich den Slider ganz weglassen - finde ich aber auch nicht schick. Eingrenzen macht wenig Sinn...Der Slider nach "Außen" wird jedenfalls
skalierbar sein.
Widgetoverride gibt doch dazu Möglichkeiten... für mich sind das also "defaulfWidgets"-Werte, die sich das System über den verwendeten DPT als "Sinnvoll" ausdenkt.
Per Widgetoverride kann ich dann die Werte verkleinern, Sprünge einbauen (dass ich die Temperatur in 0.5er Schritte verändern kann), die Farbskala ändern, etc...

Der Rest sieht schon sehr ordentlich aus, ich denke ich kann das Modul schon produktiv einsetzen! Herzlichen Dank!!


Nachtrag:
2018.03.22 xx:xx:xx 1 : PERL WARNING: Use of uninitialized value $option in pattern match (m//) at ./FHEM/10_KNX.pm line 602.
2018.03.22 xx:xx:xx 1 : PERL WARNING: Use of uninitialized value $option in pattern match (m//) at ./FHEM/10_KNX.pm line 603.


sG
Joe



« Letzte Änderung: 22 März 2018, 12:35:23 von JoeALLb »
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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #66 am: 22 März 2018, 12:44:16 »
Nachtrag #2:
Diese Fehlermeldung verstehe ich nicht. Man sieht im Hintergrund, dass desired-temp als g4 angelegt ist, warum bekomme ich dann diese Fehlermeldung mit "1"?

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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #67 am: 22 März 2018, 13:17:15 »
Nachtrag 3;

ich habe mittels


attr <> userattr Sensor
attr <> Sensor <nameSensor>
den externen Temperatursensor  eines Devices  als Attribut zu einem Device "dazugespeichert".

in stateCmd kann dies aufgerufen werden
{ReadingsNum(AttrVal($name,"Sensor",undef),"temperature",2,1)}
in putCmd jedoch nicht. Wird immer die alternative Zahl, also in diesem Fall die 2 ausgegeben.
Hast Du dazu eine idee?

Anbei der Code aus putCmd, der so eben die 2 ausgibt.

{
  if ($gad =~ /Vorlauftemperatur/) {
   $value= ReadingsNum(AttrVal($name,"Sensor",undef),"temperature",2,1);
  }
}

Wenn ich dort den Sensornamen "hardcodiere", geht es.
{
  if ($gad =~ /Vorlauftemperatur/) {
   $value= ReadingsNum("<nameSensor>","temperature",2,1);
  }
}

wie oben geschrieben, im stateCmd funktionieren beide varianten!

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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #68 am: 22 März 2018, 19:31:21 »
Moin!

Zitat
Der Anhang fehlt leider. Hab bei mir in 2 weiteren Systemen nachgesehen, ein altes (>5 Jahre) und ein frisch installiertes:
Bei beiden bekomme ich die TUL-hilfe.
Aber jetzt: Kannst Du es bitte versuchen, einzugrenzen - siehe Anhang. Ich kann's nicht nachvollziehen...

Zitat
Wofür wird die Zeile überhaupt benötigt? putCmd kann doch immer ausgeführt werden, egal ob value gesetzt ist oder nicht?!?
Die Prüfung prüft ja lediglich, ob hier ein entsprechendes -put Reading vorhanden ist, aber selbst ohne Reading sollte putCmd ausgeführt werden, nicht?
Naja, irgendwie brauchts ne Storyline - ich bin da relativ frei. Alternativ kommt zuerst answerReading mit state als Input, dann -put mit Inhalt des readings und zum Schluß putCmd. Ist mir eigentlich wurscht. Aber irgendeine Priorität muss man vorgeben..
Wie willst Du / Ihr es?

Zitat
2018.03.22 xx:xx:xx 1 : PERL WARNING: Use of uninitialized value $option in pattern match (m//) at ./FHEM/10_KNX.pm line 602.
2018.03.22 xx:xx:xx 1 : PERL WARNING: Use of uninitialized value $option in pattern match (m//) at ./FHEM/10_KNX.pm line 603.
Abgefangen...

Zitat
Nachtrag #2:
Diese Fehlermeldung verstehe ich nicht. Man sieht im Hintergrund, dass desired-temp als g4 angelegt ist, warum bekomme ich dann diese Fehlermeldung mit "1"?
Erledigt...

Zitat
Nachtrag 3;
Jetzt wird es kniffelig...
Die TUL kenn die Geräte nicht, für die Telegramme empfangen werden. Beim Empfang eines Telegrammes wird eine willkürliche KNX-Instanz (nicht deterministisch) angesprungen und in einer Schleife anhand des globalen Hashes "defptr" das entsprechende Hash in "deviceHash" gemapped.
Der restliche Kontext steht nicht zur Verfügung...
Ich hab mal einen Hack eingebaut. Funktioniert es damit?

Grüße, Andi



Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #69 am: 22 März 2018, 20:56:19 »
Naja, irgendwie brauchts ne Storyline - ich bin da relativ frei. Alternativ kommt zuerst answerReading mit state als Input, dann -put mit Inhalt des readings und zum Schluß putCmd. Ist mir eigentlich wurscht. Aber irgendeine Priorität muss man vorgeben..

Also putCmd würde gerne CH immer auswerten, wenn answerReading
1 ist,ndenn dafür macht man es ja ;-).
Im schlimmsten Fall kann man auch dort auf Statement oder reading-put reagieren, daher sollte das, wenn vorhanden, gewinnen.
Generell bräuchte ich eigentlich ein answerReading pro gad, denn wenn ich eine Gad in mehreren Devices nutze, sollte ich entscheiden können, welches davon antwortet.

Ich teste demnächst weiter, bin im Ausland....
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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #70 am: 24 März 2018, 15:03:12 »
Hallo Andi,

noch ein Wunsch: Schön wäre es, wenn ein in putCmd verwendete Devices unten in der Liste
"Probably associated with" angezeigt werden würde.
Feedback: Ich bin noch unterwegs, aber die Version läuft im Moment (ohne außergewöhnliche Abfragen) stabil!!

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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #71 am: 26 März 2018, 08:36:15 »
Zusammenfassung der Erkenntnisse aus dem Wochenende ;-)

1.
Aber jetzt: Kannst Du es bitte versuchen, einzugrenzen - siehe Anhang. Ich kann's nicht nachvollziehen...

Nein, leider. Geht bei mir nicht, egal was ich mache.

2.
Naja, irgendwie brauchts ne Storyline - ich bin da relativ frei. Alternativ kommt zuerst answerReading mit state als Input, dann -put mit Inhalt des readings und zum Schluß putCmd. Ist mir eigentlich wurscht. Aber irgendeine Priorität muss man vorgeben..

Wie oben geschrieben sollte meiner Meinung nach definitiv putCmd immer ausgewertet werden! Dort kann ich auf die anderen Fälle alle reagieren!
Die aktuelle Variante funktioniert nicht, denn wenn value=0, was bei Temperaturen gerade öfter vorkommt, wird putCmd auch nicht ausgewertet. Ich habe die Prüfung für mich einfach entfernt!

3.
Jetzt wird es kniffelig...
Die TUL kenn die Geräte nicht, für die Telegramme empfangen werden. Beim Empfang eines Telegrammes wird eine willkürliche KNX-Instanz (nicht deterministisch) angesprungen und in einer Schleife anhand des globalen Hashes "defptr" das entsprechende Hash in "deviceHash" gemapped.
Der restliche Kontext steht nicht zur Verfügung...
Ich hab mal einen Hack eingebaut. Funktioniert es damit?

Nein! Ich musste als Workaround fie Namen hardcodieren.

in #4 ist ein Testdevice! In diesem kannst Du auch den Fall für #3 testen. Aktuell gibt es als Temperatur über ETS abgefragt 0° zurück, anstatt 5.
wenn Du die eine Zeile in putCmd auskommentierst, wird korrekt 5° zurückgegeben.

Ein simples "{ ReadingsNum($name,"measured-temp-put",3) }" als stateCmd funktioniert jetzt übrigens auch nicht mehr, diehe Beispiel aus #4.

4. (Edit1):
Ein Device, das selbst eine Antwort mit putCmd liefert, kann nich selbst nicht mit "get <device> temperature" abfragen.

im Test für diesen Fall sollte meiner Meinung nach ein
get DemoKNX measured-temp ein Ergebnis liefern, und das Reading measured-temp-get aktualisieren.
Es wird jedoch lediglich measured-temp-put aktualisiert.

defmod DemoKNX KNX 1/0/30:dpt9.001:measured-temp
attr DemoKNX userattr correspondReturnSensor
attr DemoKNX answerReading 1
attr DemoKNX correspondReturnSensor DemoKNX
attr DemoKNX putCmd {\
  if ($gad =~ /measured-temp/) {\
   $value= ReadingsNum(AttrVal($name,"correspondReturnSensor",undef),"temperatureTest",0,1);;\
   #$value= ReadingsNum("DemoKNX","temperatureTest",0,1);;\
  }\
}
attr DemoKNX stateCmd { ReadingsNum($name,"measured-temp-put",3) }
attr DemoKNX verbose 5
attr DemoKNX widgetOverride stateCmd:textField-long\
eventMap:textField-long\
widgetOverride:textField-long\
putCmd:textField-long

setstate DemoKNX 2018-03-26 08:52:34 measured-temp-put 0.0
setstate DemoKNX 2018-03-26 08:52:35 temperatureTest 5


5. Wie wird GETSTRING wieder bereinigt, wenn ich GADs aus der Definition entferne?
Denn selbst beim kopieren eines Devices wird das immer mitgezogen!

6. beim Anlegen des Testdevices aus #4 bekomme ich diese Fehlermeldung:
Unknown argument, choose one of measured-temp:slider,-670760,13415,670760
Aber generell ist der Ansatz schon eine tolle Weiterentwicklung!! Möchte nicht mehr zum alten zurückkehren!!

sG
Joe
« Letzte Änderung: 26 März 2018, 09:04:33 von JoeALLb »
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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #72 am: 26 März 2018, 16:52:07 »
Nachtrag1:

Hier in diesem Device wird irgendwie die falsche Gruppenadresse abgefragt.
Geklickt habe ich im Webinterface auf "get knx.wetter measured-temp,
und hätte mir erwartet dass er 0/5/6 abfrägt.
Bei anderen Devices ist mir hier bishe rnie ein Fehler aufgefallen...

Siehe Screenshot:

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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #73 am: 26 März 2018, 19:26:36 »
Öhm...

Wie kopierst Du ein Device?

Frage wegen des GETSTRING...

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #74 am: 26 März 2018, 20:18:26 »
Mit
copy olddevice newdevice
« Letzte Änderung: 27 März 2018, 10:55:27 von JoeALLb »
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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #75 am: 27 März 2018, 12:01:28 »
Die tägliche Nutzung der neuen Version ist viel Angenehmer als bei der bisherigen.
Dennoch stelle ich die Notwendigkeit von "-get" in Frage!
Ich habe meine Installation fast komplett migriert, am meisten Aufwand war
die Änderung durch die Großkleinschreibung... da funktionierten plötzlich die kleingeschriebenen Readings nicht mehr.

Mit "-put" und "-set" kann ich sehr gut leben,
jedoch wenn ich ein
get <device> temperatureabsetze, erwarte ich mir eigentlich als Rückgabe eine Temperatur!
zudem schänkt mich das "-get" in der Namenswahl deutlich ein.

Ich beobachte mich immer häufiger beim Umschreiben der "-get" readings mittels userReadings, was ich für sinnlosen Doppelaufwand halte!

Wenn Du es nicht allgemeingültig ändern möchtest, wie wäre es mit einem Attribut?
Dann würde auch bei einem set <device> in der Weboberfläche gleich der aktuelle Wert vorab ausgewählt werden, was besonders bei Temperaturen
hilfreich ist!

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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #76 am: 27 März 2018, 20:05:55 »
Nachtrag #x:

Ich weiß nicht, wie es in anderen Modulen ist, aber wenn ein userReading undef zurückgibt, werden KEINE Events mehr produziert und somit auch nichts mehr geloggt.
Gespeichert werden die geänderten Werte jedoch in ihren Readings!

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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #77 am: 27 März 2018, 21:04:00 »
Moin!

Zu Deiner Anregung wegen -get...
-get wird in vielen Fällen sehr wohl benötigt - zumindest je nach Ansatz. Eine Umbenenneung packe ich jetzt nicht an - da drehen wir alle anderen hohl :-) Wenn Du eine minimal invasive Lösung brauchst, lautet die Antwort: manipuliere -get in der Define-Methode beim Schreiben der Gaddetails.
Die Unterscheidung zwischen Groß- und Kleinschreibung hab ich bereits vor einigen WOchen eingebaut. Ist nicht unproblematisch - gab aber doch einige entsprechende Wünsche...
Bezüglich Userreadings hab ich 0,0 Behandlung im Modul - will ich auch beibehalten...

Zu den Themen von gestern:
- putCmd wird immer ausgeführt
- "-put" überschreibt den ggf. vorbelegten Wert von "state"
- $hash krieg ich in putCmd mangels Kontext nicht sauberer hin - musst beim Hardcodieren bleiben
- Der Input mit GETSTRING war super - hier war noch ein unschöner bug drin...

Doku mach ich nach Ostern, dann isses meine ich reif für einen Breitentest...

Grüße, Andi

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #78 am: 28 März 2018, 08:22:24 »
Hallo Andi,

danke für die neue Version!

#1: Das Problem aus #72 existiert noch.
Anbei die WRAW_Definition eines Devices. Wenn ich
fhem> get knx.TEST measured-temp
current value for knx.TEST (5/5/0) requested
absetze, erhalte ich als Antwort, dass 5/5/0 abgefragt wird, nicht
5/5/6, wie ich erwartet hätte.

defmod knx.TEST KNX 5/5/0:dpt9.004:brightRight\
5/5/2:dpt9.004:brightCenter\
5/5/3:dpt9.004:brightLeft\
5/5/4:dpt9.004:twilight\
5/5/5:dpt1.001:daynight\
5/5/6:dpt9.001:measured-temp\
5/5/1:dpt1.001:alarm-bright-right\
5/5/20:dpt1.001:alarm-bright-center1\
5/5/7:dpt1.001:alarm-temp-frost\
5/5/17:dpt1.001:alarm-temp-hitze\
5/5/10:dpt1:alarm-wind1\
5/5/20:dpt1:alarm-wind2\
5/5/18:dpt1:alarm-rain1\
5/5/19:dpt1:alarm-rain2\
5/5/15:dpt1.001:alarm-Sensor\
5/5/14:dpt1.001:alarm-Time\
5/5/16:dpt1.001:alarm-Unit\
5/5/8:dpt9.026:measured-rain\
5/5/9:dpt9.028:measured-wind\
5/5/11:dpt10:time\
5/5/12:dpt1.001:getDate\
5/5/13:dpt11:date
attr knx.TEST DbLogExclude last-sender, state
attr knx.TEST IODev KNX
attr knx.TEST room TEST
attr knx.TEST verbose 5
attr knx.TEST webCmd :
attr knx.TEST widgetOverride stateCmd:textField-long\
eventMap:textField-long\
widgetOverride:textField-long

setstate knx.TEST 16.72 &deg;;C
setstate knx.TEST 2018-03-28 08:09:07 alarm-temp-hitze-get off
setstate knx.TEST 2018-03-28 08:09:07 alarm-wind1-get off
setstate knx.TEST 2018-03-28 08:09:29 last-sender 1/1/10
setstate knx.TEST 2018-03-28 08:09:29 measured-temp-get 16.72 &deg;;C
setstate knx.TEST 2018-03-28 08:09:29 state 16.72 &deg;;C

Zu Deiner Anregung wegen -get...
- Wenn Du eine minimal invasive Lösung brauchst, lautet die Antwort: manipuliere -get in der Define-Methode beim Schreiben der Gaddetails.
Werde ich machen! Schlage hier jedoch trotzdem eine Suffix-Attribut vor, das ja standardmäßig mit "-get" vorbelegt sein kann.

Die Unterscheidung zwischen Groß- und Kleinschreibung hab ich bereits vor einigen WOchen eingebaut.
Nicht falsch verstehen, mir gefällt dies! Musste nur einige stateCmd's und anderes aktualisieren!

Bezüglich Userreadings hab ich 0,0 Behandlung im Modul - will ich auch beibehalten...
Mich wundert nur, dass danach nichtmal mehr moduleigene Readings Events produzierten.
Da weicht das Verhalten zumindest von anderen Modulen ab.
Die Rückgabe von undef ist nötig, wenn man im Userreading entscheidet, dass dies in diesem Fall eben NICHT aktualisiert werden soll.
Ich werd mir das aber auch noch genauer ansehen!




- $hash krieg ich in putCmd mangels Kontext nicht sauberer hin - musst beim Hardcodieren bleiben
Das ist bitter... warum funktioniert es im stateCmd schon?

Dann sag ich erstmal nochmals Danke für die neue Version, werde sie weiter testen!

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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #79 am: 28 März 2018, 12:45:17 »
Moin!

Ich schau mir das mit den verzwirbelten Adressen nochmal an - hab ich noch nicht verstanden.
Bitte poste auch die Konfiguration des Devices mit der GAD 5/5/0.

Zitat
Bezüglich Userreadings hab ich 0,0 Behandlung im Modul - will ich auch beibehalten...
Mich wundert nur, dass danach nichtmal mehr moduleigene Readings Events produzierten.
Da weicht das Verhalten zumindest von anderen Modulen ab.
Die Rückgabe von undef ist nötig, wenn man im Userreading entscheidet, dass dies in diesem Fall eben NICHT aktualisiert werden soll.
Ich werd mir das aber auch noch genauer ansehen!

Ja, bitte.


Zitat
$hash krieg ich in putCmd mangels Kontext nicht sauberer hin - musst beim Hardcodieren bleiben
Das ist bitter... warum funktioniert es im stateCmd schon?

Hatte ich vorgestern versucht zu erklären - stateCmd passiert im eigenen Kontext, putCmd kann auch im fremden Kontext passieren...

Grüße, Andi

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #80 am: 28 März 2018, 12:53:41 »
Bitte poste auch die Konfiguration des Devices mit der GAD 5/5/0.
Hängt doch oben in Beitrag 78 mit dran, zum selber ausprobieren.

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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #81 am: 28 März 2018, 13:02:43 »
Nein. In dem Device von Beitrag 78 ist die GAD 5/5/0 nicht definiert.

Ich nehme an, die ist Teil einer anderen Definition...Und genau die Suche ich. Ich vermute, hier kommen Namen durcheinander...

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #82 am: 28 März 2018, 14:10:01 »
Nein. In dem Device von Beitrag 78 ist die GAD 5/5/0 nicht definiert.

Doch, schau in die erste Zeile mit dem Gad Namen brightRight.

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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #83 am: 28 März 2018, 19:32:55 »
Gibs zu, das hast Du heimlich editiert :-)

EDIT:
Bitteschön...
« Letzte Änderung: 28 März 2018, 19:54:21 von Andi291 »

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #84 am: 29 März 2018, 19:27:39 »
Gibs zu, das hast Du heimlich editiert :-)

EDIT:
Bitteschön...

Sonst wärs doch langweilig :D
... über Deinen Edit wurde ich nicht per Email informiert, daher hab ich die Version gerade eben erst per Zufall "gefunden" ;-)

Werd testen!
« Letzte Änderung: 01 April 2018, 08:15:53 von JoeALLb »
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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #85 am: 01 April 2018, 08:21:19 »
Hi,
Ich benötige unbedingt eine Möglichkeit, das Answer einer Gad zu verhindern, während eine andere sehrwohl antwortet.
Sonst bekomme ich bei einem Heizungsthermostat (zB. Für die gad der Temperaturmessung) doppelte antworten...

Generell würde ich bei der Definition nach dem Namen der Gäste einen vierten optionalen Block vorschlagen.

Als kurzfristig Lösung würde ich h jedoch vorschlagen, dass wenn putCmd den value auf undef (oder einen beliebig anderen vordefinierten Wert) setzt, keine Antwort gesendet wird. ( Oder ist dies schon so, da undef ja nicht wirklich gesendet werden kann?)
Durch diese undef- variante kann ich beispielsweise auch gleich verhindern, dass eine Antwort zu oft generiert wird und sie beispielsweise auf 1x pro Minute limitieren, um den Bus zu entlasten.

SG Joe
« Letzte Änderung: 01 April 2018, 08:52:56 von JoeALLb »
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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #86 am: 02 April 2018, 13:17:46 »
Hier ein Beispieldevice, das zeigen soll,
warum suffixe manchmal problematisch sind.
Ich benötige hier das userreading nur, um den wert in das richtige reading (also ohne -set) zu kopieren.
Ich würde also ein Atribut vorschlagen, das "set-suffix, default to '-set' " heißen könnte.

Da, wie das Beispiel zeigt, die Widgets nun so schön genutzt werden können, würde ich vorschlagen, das Attribut "slider"
als veraltet zu bezeichnen und diesen FHEM-Standard durchgängig zu propagieren ...


defmod HeizungMaster3 KNX 7/3/0:dpt1.003:acutator-mode
attr HeizungMaster3 eventMap /acutator-mode disable:acutator-mode auto/\
acutator-mode enable:acutator-mode closed/
attr HeizungMaster3 room KNXtest
attr HeizungMaster3 stateCmd {  "Mode: ".ReadingsVal($name,"acutator-mode","undef").\
""}\
\

attr HeizungMaster3 stateRegex /status-set:enable/closed/ /status-set:disable/auto/ /XXX.*//
attr HeizungMaster3 userReadings acutator-mode:acutator-mode-set.* {   \
  my $reading = ReadingsVal($name,"acutator-mode-set",undef);;\
  if ($reading =~ /enable/)\
    {\
      return "closed";;\
    }\
  else\
    {  \
     return "auto";;\
    }\
}
attr HeizungMaster3 verbose 5
attr HeizungMaster3 webCmd acutator-mode
attr HeizungMaster3 widgetOverride devStateIcon:textField-long\
stateCmd:textField-long\
stateRegex:textField-long\
eventMap:textField-long\
widgetOverride:textField-long\
acutator-mode:uzsuToggle,auto,closed

setstate HeizungMaster3 Mode: auto
setstate HeizungMaster3 2018-04-02 13:11:41 acutator-mode closed
setstate HeizungMaster3 2018-04-02 13:11:41 acutator-mode-set enable
setstate HeizungMaster3 2018-04-02 13:11:41 state Mode: auto


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

Offline Andi291

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1067
Antw:Schnittstellenänderung
« Antwort #87 am: 04 April 2018, 10:27:37 »
Moin!

Das hab ich schon auf dem Schirm.
Dafür kannst Du in der Definition get/set/listenonly angeben. Muss ich aber noch scharf schalten.

Wenn answerReading nicht gesetzt ist, und putCmd undef ist, wird keine Antwort gesendet.

Grüße, Andi

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1366
Antw:Schnittstellenänderung
« Antwort #88 am: 06 April 2018, 14:08:57 »
Das hab ich schon auf dem Schirm.
Dafür kannst Du in der Definition get/set/listenonly angeben. Muss ich aber noch scharf schalten.

Top! Das war eigentlich mein größter Showstopper.
Ich bekomme noch manche userreadings nicht mit DbLog geloggt, aber das wollte ich mir noch genauer ansehen.
Ich habe dafür im Moment einen workaround mittels cronjob im Einsatz.

Aus meiner Sicht steht daher einer veröffentlichung nichts mehr im Weg.
Ich hab noch einen Vorschlag für eine Vereinfachung der Funktion splitFn, das teste ich aber vorab noch.

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