Autor Thema: Schnittstellenänderung  (Gelesen 8006 mal)

Online JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1466
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

Online JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1466
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: 1098
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?

Online JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1466
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

Online JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1466
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: 1098
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

Online JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1466
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: 1098
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: 1098
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


Online JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1466
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

 

decade-submarginal