Schnittstellenänderung

[JoeALLb]

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.

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

[JoeALLb]

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

[Andi291]

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

[docm]

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?

[JoeALLb]

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

Code Auswählen Erweitern

attr xy widgetOverride kw:colorpicker,CT,0,1,100
attr xy readingsList kw
die Lichtfarbe einstellen könnte, und danach

Code Auswählen Erweitern

"set <device> kw 100"

eingeben könnte. Das geht im Moment auch schon über ein eher komplexes eventMap

Code Auswählen Erweitern

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

habe jedoch keinen Einfluss mehr auf die Werte.

mit

Code Auswählen Erweitern

attr xy readingsList kw
brä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:

Code Auswählen Erweitern

devStateIcon:textField-long
stateCmd:textField-long
stateRegex:textField-long
eventMap:textField-long
widgetOverride:textField-long

[docm]

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

[JoeALLb]

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.

Code Auswählen Erweitern

verbrauch:getG1.* monotonic {
  return ReadingsVal("$name", "getG1", "") ;
}

wenn jetzt jedoch "verbrauch" und der tatsächliche Zählerstand auseinanderläuft, könnte ich wenn

Code Auswählen Erweitern


attr xy setList verbrauch
gesetzt ist, einfach mit

Code Auswählen Erweitern

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

[Andi291]

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

[docm]

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

[JoeALLb]

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

[docm]

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

[Andi291]

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 ( ) - hast Du Dich schon mal mit den Möglichkeiten der Konfiguration befasst?
Ich hab immer noch die Vision von einem Wizard samt ESF-Input...

[Andi291]

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

[docm]

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

[JoeALLb]

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