Schnittstellenänderung

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

Vorheriges Thema - Nächstes Thema

Andi291

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

Andi291

V2 - a bisserl performanter und mit zwei Fehlern weniger.

erwin

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 aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Andi291

#3
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?


erwin

#4
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.
ZitatWie 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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

JoeALLb

#5
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
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

obi

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 :)


Andi291

Servus Erwin!

Um es zu konkretisieren:

Zitatsiehe 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

erwin

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 aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Andi291

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

JoeALLb

#10
Zitat von: Andi291 am 15 Dezember 2017, 19:48:39
@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
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

docm

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


JoeALLb

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

Andi291

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

docm

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