FHEM Forum

FHEM - Hausautomations-Systeme => KNX/EIB => Thema gestartet von: Andi291 am 14 April 2018, 00:23:42

Titel: [eingechecked, thread closed] Neues major release zum Test
Beitrag von: Andi291 am 14 April 2018, 00:23:42
Hallo Gemeinde!

Anbei ein neues Major-Release zum Test.

Es sind einige Bugfixes und die Feature-Requests aus dem Thread "Schnittstellenänderung" eingeflossen. Weiterhin habe ich die internen Datenstrukturen umgebaut, um das Modul übersichtlicher und performanter zu gestalten.
Zu den Kernänderungen gehört auch die Umgebaute Set-Syntax. Hierbei gilt, dass die Gruppenadressen nun grundsätzlich über Namen angesprochen werden. Die Qualifier (Value, ...) entfallen ersatzlos. Keine Sorge, der alte Pfad ist und bleibt noch drin.

Folgende Attribute sind deprecated - bitte dazu die Commandref und die darin enthaltenen Beispiele konsultieren: listenonly, readonly, slider, useSetExtensions.

Bitte testet fleißig und gebt mir Rückmeldung.

@Admins: kann man den Thread bitte oben anpinnen?

Danke!


Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 16 April 2018, 08:03:21
Danke!

Die neue Prüfung:
configfile: GAD 3/5/20 may be supplied only once per device.
hat gleich erfolgreich zugeschlagen und mir einen Fehler in meiner Konfiguration aufgedeckt.
Titel: Antw:Neues major release zum Test
Beitrag von: EIB-Fan am 16 April 2018, 11:20:01
Hallo Andi,

danke an dich für die Weiterentwicklung des Modules!  :)

Ich habe am Wochenende auf die neue KNX-Version umgestellt. Natürlich waren in der Konfiguration einige Änderungen notwendig ... 8)

Mir ist ein Punkt aufgefallen. Das Senden des Datums bricht immer wieder mit Fehler "invalid value: time" ab
set timedev date now

Werde natürlich weiter testen und Feedback geben.

Gruß Jens
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 16 April 2018, 14:55:21
Allgemeiner Hinweis:
Da ich zum Anzeigen immer wieder entscheiden muss, welche Werte (-put -get oder -set) ich nutze,
verzichte ich mittlerweile in meiner ganzen Installation auf die Nutzung von -get,-put,-set.
Dies hat auch den riesen Vorteil, dass bei Set-Befehlen gleich der aktuelle Wert als Vorauswahl angezeigt wird.

Rudi hat mir dankenswerter Weise in fhem.pl eine Erweiterung eingearbeitet, die das Umschreibend avon in userReadings
relativ einfach macht. (Achtung, das geht nur in ganz aktuellen Versionen!)
Statt drei einzelnen Aufrufen ist nun folgendes möglich, um alle drei Arten auf ein Reading "zusammenzukopieren".

measured-temp:measured-temp-.* {   
  $eventValue;
},


Dies kann noch und folgendes ergänzt werden, wenn man zB nur bei Änderungen das Reading aktualisieren möchte und wenn man
zusätzlich noch nur den nummerischen Wert ohne "Unit" übernehmen möchte:

measured-temp:measured-temp-.* {   
  return  $eventValue ne ReadingsVal($name,$eventName,-10) ? ($eventValue =~ /(-?\d+(\.\d+)?)/)[0] : undef;
},


Vielleicht mag das einer in dem Zusammenhang mit nutzen...

sG
Joe
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 16 April 2018, 15:29:52
bei diesem Device bekomme ich
defmod knx.Test1 KNX 0/5/6:dpt9.001:measured-temp
attr knx.Test1 verbose 5
attr knx.Test1 webCmd :


diese Fehlermeldung im Log:
2018.04.16 15:26:26 5: parse: process message, device-name: knx.Test1, rd-name: , gadCode: 0050a, model:
2018.04.16 15:26:26 5: decode value: 00, gadName:
2018.04.16 15:26:26 5: decode model: , code: , value: 00
2018.04.16 15:26:26 2: decode model: , no valid model defined
2018.04.16 15:26:26 1: readingsUpdate(knx.Test1,last-sender,1/1/10) missed to call readingsBeginUpdate first.
2018.04.16 15:26:26 1: stacktrace:
2018.04.16 15:26:26 1:     main::readingsBulkUpdate            called by ./FHEM/10_KNX.pm (1128)
2018.04.16 15:26:26 1:     main::KNX_Parse                     called by fhem.pl (3746)
2018.04.16 15:26:26 1:     main::Dispatch                      called by ./FHEM/00_TUL.pm (289)
2018.04.16 15:26:26 1:     main::TUL_Parse                     called by ./FHEM/00_TUL.pm (270)
2018.04.16 15:26:26 1:     main::TUL_Read                      called by fhem.pl (3550)
2018.04.16 15:26:26 1:     main::CallFn                        called by fhem.pl (708)
2018.04.16 15:26:26 2: parse device hash (wpi): HASH(0x562abf1cb260) name: knx.Test1, message could not be decoded - see log for details


sG
Joe
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 16 April 2018, 21:12:42
Moin!

@Jens: In der Doku korrigiert.
@Joe: Kann ich nicht nachvollziehen. Die Definition läuft 1a durch. Wann wird die Fehlermeldung ausgegeben?

Ich pinne die Version am ersten Post an...

Grüße, Andi

EDIT:
Kann es sein, dass bei Dir noch ein Autocreate-Device mit der Adresse 0/5/10 rumliegt? Das ist nämlich die Adresse der geparsten Nachricht.
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 17 April 2018, 11:55:37
Zitat von: Andi291 am 16 April 2018, 21:12:42
@Joe: Kann ich nicht nachvollziehen. Die Definition läuft 1a durch. Wann wird die Fehlermeldung ausgegeben?

hm, wenn ich ein get measured-temp absetze,

Zitat von: Andi291 am 16 April 2018, 21:12:42
Kann es sein, dass bei Dir noch ein Autocreate-Device mit der Adresse 0/5/10 rumliegt? Das ist nämlich die Adresse der geparsten Nachricht.
Nein, nicht per autocreate. das ist ein normale Windarlarm, definiert über 0/5/10:dpt1.


sG
Joe
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 17 April 2018, 19:35:18
Abend Joe!

Sorry, ich kann es nicht nachvollziehen:


2018.04.17 19:31:20 5: parse: process message, device-name: knx.Test1, rd-name: measured-temp, gadCode: 00506, model: dpt9.001
2018.04.17 19:31:20 5: received hash (r): HASH(0x3a2ee88) name: knx.Test1, GET
2018.04.17 19:33:24 5: enter get knx.Test1: hash: HASH(0x3a2ee88), attributes: knx.Test1, measured-temp
2018.04.17 19:33:24 5: get knx.Test1: request value for GAD: 0/5/6, GAD-NAME: measured-temp
2018.04.17 19:33:24 5: exit get
2018.04.17 19:33:25 5: parse: process message, device-name: knx.Test1, rd-name: measured-temp, gadCode: 00506, model: dpt9.001


Kann es sein, dass Du noch irgendein put-Cmd Fragment rumliegen hast, welches den value nullt?
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 17 April 2018, 20:18:00
Hallo Andi, meine Wetterstation antwortet auf die eine Anfrage mit mehreren verschiedenen antworten... Ich schau mir das gerade genauer an....
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 18 April 2018, 10:37:26
Hallo Andi, wie ist es gedacht, einer "funktion" mehrere GADs zuzuweisen?
Ich denke da im Moment an ein Sperrobjekt für Heizungsventile.

Jedes Ventil hat eine eigene SperrGAD, dann gibt es noch eine zentrale SperrGAD fürs ganze Haus.

Wie würdest Du das im Modul abbilden? 2 Unterschiedliche GADs und die Stati per funktion oder userreading "zusammenkopieren", oder
kann ich (vielleicht sogar jetzt schon?) 2 unterschiedliche GADs gleich benennen?

Edit:
Bin gerade über das Log aus zeile 647 gestossen, das bei jeder Ansicht des Devices angezeigt wird.
Da es "Unknown argument ..." heißt, bin ich von einem Fehler ausgegangen, wenn ich mir die Codekommentare ansehe, scheint es aber kein Fehler zu sein.
Kann/Sollte man hie rnicht den text ändern?
Zusätzlich musste ich mir den Devicenamen über folgendes mit anzeigen, um überhaupt zu sehen, welches Device denn diese Fehlermeldung überhaupt produziert.
"Unknown argument '$name : $arg1' [...]

sG
Joe
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 18 April 2018, 19:44:48
Servus Joe!

Hab ich bei mir sinngemäß so gelöst (alte Syntax):

Im state steht immer nur der eigentliche Aktorstatus - meist zu bekommen per stateCmd und Einlesen von Status-get:

define licht_terasse KNX 5/4/18:dpt1.001:status 5/4/16:dpt1.001:auto 5/4/17:dpt1.001:manuell
attr licht_terasse IODev knxd
attr licht_terasse alias Licht Terasse
attr licht_terasse devStateIcon (on)|([Ee]in):general_an:Aus (off)|([Aa]us):general_aus:Ein
attr licht_terasse eventMap /on g3:Ein/off g3:Aus/
attr licht_terasse group Beleuchtung
attr licht_terasse icon light_outdoor
attr licht_terasse room Au&szligen
attr licht_terasse stateCmd {sprintf("%s", ReadingsVal($name,"status-get",""))}
attr licht_terasse webCmd Ein:Aus


Wenn mich der Übergangszustand interessiert - z.B. wg. Icon - nutze ich folgenden Weg:

define nas KNX 11/0/1:dpt1.001:status 11/0/0:dpt1.001:steuern 11/0/2:dpt1.001:reboot
attr nas IODev knxd

Und ja: Zeile 647 is blöd - bitte auskommentieren.

Was ist aus Deiner Wetterstation geworden?
attr nas alias NAS
attr nas devStateIcon status-on:general_an:Reboot status-off:general_aus:Ein steuern-.*:hourglass reboot-.*:hourglass
attr nas eventMap /on g2:Ein/off g2:Aus/on g3:Reboot/
attr nas group IT
attr nas icon it_nas
attr nas room System,Startseite
attr nas stateRegex /steuern-[sg]et:/steuern-/ /status-[sg]et:/status-/ /reboot-[sg]et:/reboot-/
attr nas webCmd Ein:Aus:Reboot


EDIT: Probier die neue Version - damit müsste last-Sender nun auch in den autocreate-devices ohne DPT eingetragen werden.
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 19 April 2018, 09:33:17
Zitat von: Andi291 am 18 April 2018, 19:44:48
  Was ist aus Deiner Wetterstation geworden?
Beim Suchen danach bin ich eben über Zeile 647 gestolpert und hab mich nach der vermeindlichen Fehlersuche "verrannt".

Aber aktuell sieht es gut aus, obwohl ich noch seltsamkeiten bei DPT1 untersuchen möchte. DPT1.001 scheint dagegen zu funktionieren!
Aber ich bin noch nicht weiter, muss es nochmal prüfen.

Generell finde ich die Version toll, und einen Mega-Schritt gegenüber der bisherigen Version!
Besonders auch das angenäherte look and feel zu anderen typischen fhem-Modulen, besonders die Auflösung des eigenen Slider-Konzepts und das wegfallen des "value".
Schade finde ich leider wirklich, das Thema "-put,-get, -set",
denn dadurch lassen sich die neuen Gruppennamen nur "halbherzig" verwenden, Slider haben falsche Defaults beim Öffnen eines Devices, ...
Hier würde ich mir ein Attribut wünschen, um das zu deaktivieren.

Über folgenden simplen Patch habe ich das im Moment für mich gelöst, da ich die saubere Variante mit Attribut (und default bei nicht gesetztem Attribut auf (-put, -...) leider mit meinen Programmierkenntnissen nicht hinbekomme.

--- 10_KNX.org.pm Thu Apr 19 09:17:50 2018
+++ 10_KNX.pm Thu Apr 19 09:16:33 2018
@@ -71,7 +71,7 @@
#pattern for group-no
my $PAT_GNO = '[gG][1-9][0-9]?';
#pattern for GAD-Options
-my $PAT_GAD_OPTIONS = '(get)|(set)|(listenonly)';
+my $PAT_GAD_OPTIONS = '(get)|(set)|(listenonly)|(suffix)';
#pattern for forbidden GAD-Names
#my $PAT_GAD_NONAME = '((on)|(off)|(value)|(raw)|' . $PAT_GAD_OPTIONS . ')$';
#pattern for DPT
@@ -384,6 +384,12 @@
$rdNameSet = $gadName . "-set";
$rdNamePut = "";
}
+ elsif ($gadOption =~ m/(suffix)/i)
+ {
+ $rdNameGet = $gadName . "";
+ $rdNameSet = $gadName . "";
+ $rdNamePut = $gadName . "";
+ }
}
else
{


Übrigens: Der Klick in der englischen Commandref auf KNX funktioniert nicht. Ich muss immer auf das Modul darüber (KM273) klicken und dann runterscrollen.
Das entsteht wohl durch diesen Fehler:
/usr/bin/perl ./contrib/commandref_join.pl -noWarnings
*** EN KNX: nonempty line after =begin html ignored

und sorgt dafür,
dass diese Zeile
<p><a name="KNX"></a></p>
nicht mit aufgenommen wird. Somit fehlt das Sprungziel.

Was ich mir noch wünschen würde wäre ein DPT1 der nur 0 und 1 kennt.

sG Joe
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 19 April 2018, 22:09:22
Abend!

Nervensäge :-)

Doku geht. Dein Flag heißt "nosuffix". Ich konnte mich durchringen, einen DPT außerhalb des KNX-Standard anzulegen. Er heißt 1.000 (für was auch immer Du den brauchst....).

Grüße, Andi
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 20 April 2018, 06:56:07
 :D
Ich nehme das jetzt mal für diesen Fall als Kompliment...
Bin am testen!
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 23 April 2018, 10:19:04
Hallo Andi.
Das ist eine sehr gelungene Version! Das neue Feature ist genial, und ich wette fast dass das zu einem der beliebtesten Features werden wird ;-)

Ich bin noch intensiv am konfigurieren, da es sich um einen Neubau handelt, aber bisher bin ich sehr zufrieden!

Eine Ergänzung zu einem bisherigen Wunsch fällt mir auf:
Ich hatte mir die Funktion bzw. das Attribut "setList" aus dummi oder DOIF gewünscht, um leichter per widgetoverride Eintellungen konfigurieren zu können...

Vermutlich einfacher könnte man es gestalten, indem man in der Definition statt einer GAD einfach ein DUMMY erlaubt, um so dummy setter und getter zu ermöglichen.
Diesen kann man dann wunderbar direkt als eventmap oder aber auch über userReadings für verschiedenste Dinge nutzen.
Ich möchte zB 2 GADs gleichzeitig einen Wert schicken und löse das im Moment mit dem Definieren einer GAD in einer Linie, die es bei mir eigentlich nicht gibt.

ABER: Dieser Wunsch ist nicht für das Release relevant, aus meiner Sicht könnte man langsam über einen Checkin nachdenken.
Was ich jedoch NICHT getestet habe ist die Kompatiblität zum bisherigen Modul, da ich alles gleich auf die neuen Features aktualisiert habe unf G1, etc. nicht mehr nutze.
Probleme kann es definitig mit der Großskleinschreibung geben: Da dort Readings, wenn genutzt, plötzlich Großbuchstaben enthalten, werden Werte, stateCMDs, etc. eventuell nicht mehr aktualisiert, aber da kann man ja drauf hinwesien.

Tolle Version, herzlichen DANK!!!!!

sG Joe
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 23 April 2018, 12:25:52
Ergänzung:
Bei diesem Device habe ich einen Anzeigefehler, wenn ich auf "set <device> umluft" um webfrontend gehe:

defmod knx.TEST2 KNX 8/6/240:dpt5:szene:nosuffix\
\
8/6/241:dpt1:umluft-position:nosuffix\
8/6/242:dpt1:umluft-stop:nosuffix\
8/6/243:dpt5.001:umluft-position:nosuffix\
8/6/244:dpt5.001:umluft-position-state:nosuffix\
8/6/245:dpt1.001:umluft-bewegung:nosuffix
attr knx.TEST2 IODev KNX
attr knx.TEST2 eventMap /abluft-langzeit 100:abluft oeffnen/abluft-langzeit 0:abluft schliessen/\
szene 1:szene standby/\
szene 2:szene abluft/\
szene 3:szene umluft/\
szene 4:szene open/
attr knx.TEST2 room 5-Todo
attr knx.TEST2 stateFormat umluft-position-state abluft-position-state
attr knx.TEST2 webCmd umluft
attr knx.TEST2 widgetOverride widgetOverride:textField-long\
eventMap:textField-long\
umluft:uzsuSelectRadio,oeffnen,schliessen\
szene:uzsuSelectRadio,standby,abluft,umluft,open

setstate knx.TEST2 40 % abluft-position-state
setstate knx.TEST2 2018-04-23 12:20:06 last-sender 1/1/102
setstate knx.TEST2 2018-04-23 12:20:06 state off
setstate knx.TEST2 2018-04-23 12:20:06 umluft-bewegung off
setstate knx.TEST2 2018-04-23 12:20:06 umluft-position-state 40 %
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 23 April 2018, 19:53:21
Joe, vielen Dank auf für's Testen...

Ich wird spätestens Himmelfahrt bei mir noch einen Batzen umstellen - dann haben wir auch einen "Migrationsleitfaden".

Melde mich, wenn eingechecked :-)

P.S.: Deinen Fehler schau ich mir noch an...
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 24 April 2018, 10:50:17
Puh, zu früh gefreut? Da immer ein Rückgabewert vorhanden war, ist es mir bisher nicht aufgefallen.
Scheinbar wird hier putCmd nicht mehr aufgerufen?

Wenn ich in der ETS eine Abfrage an die GAD 0/3/19 mache, bekomme ich als Rückgabewert 2.56°.
Woher nimmt er diese? Im Status stehen sie nicht, in putCmd steht zum Debug schlicht  {$value=16;},
das wird aber laut diesem Log gar nicht erst ausgeführt?!?
Wenn ich den Parameter ":nosuffix" weglasse, wird auch schön das Reading "return-temp-get 2.56 &deg;C" angelegt,
also sollte es an "nosuffix" auch nicht liegen.

2018.04.24 10:40:41 5: parse: process message, device-name: deviice, rd-name: return-temp, gadCode: 00313, model: dpt9.001
2018.04.24 10:40:41 5: received hash (r): HASH(0x563ea59c32b8) name: deviice, GET
2018.04.24 10:40:41 5: parse: process message, device-name: deviice, rd-name: return-temp, gadCode: 00313, model: dpt9.001
2018.04.24 10:40:41 5: decode value: 0100, gadName: return-temp
2018.04.24 10:40:41 5: decode model: dpt9.001, code: dpt9, value: 0100
2018.04.24 10:40:41 5: decode model: dpt9.001, code: dpt9, value: 0100, numval: 2.56, state: 2.56 &deg;C
2018.04.24 10:40:41 5: received hash (wpi): HASH(0x563ea59c32b8) name: deviice, STATE: 2.56 &deg;C, READING: return-temp, SENDER: 01101
2018.04.24 10:40:41 5: parse device hash (wpi): HASH(0x563ea59c32b8) name: deviice - state replaced via command {sprintf(
         "Soll: %4.1f° ".
         "Ist: %4.1f° ".
         "Ventil: %3d %% ".
         "Return: %4.1f°",
  ReadingsNum($name,"desired-temp",""),
  ReadingsNum($name,"measured-temp",""),
  ReadingsNum($name,"ventil",""),
  ReadingsNum($name,"return-temp",""),
)} - state: Soll: 13.0° Ist: 15.6° Ventil:   0 % Return:  2.6°


Hast Du dazu eine Idee?
Ich überlege gerade, auf welche Version ich zurückwechseln sollte, denn das bringt meine Heizungssteuerung durcheinander.
Übrigens habe ich auch geprüft, ob ich die GAD v ersehentlich 2x angelegt habe, was jedoch nicht zutrifft
cat fhem.cfg |grep "0/3/19[^0-9]"
0/3/19:dpt9.001:return-temp:nosuffix\



sG
Joe
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 24 April 2018, 20:39:50
Puh, so weit ich auf die Schnelle sehe, wird der Wert 0x100 = 2,56°C vom Bus empfangen.
Klemm mal FHEM ab und frag nochmal - ich möchte meinen, hier antwortet ein anderes Gerät...
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 24 April 2018, 20:47:09
Wenn ich mich n fhem dem Device eine andere Gad gebe, antwortet in der ETS nichts mehr, daher sollte die Antwort schon von fhem kommen!

Joe
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 24 April 2018, 21:59:43
Aaaaalso....

Ich vermute:
- Zeile 1288: dein Umfangreiches StateCmd evaluiert letztendlich zu 2,6°C
- putCmd 16(dezimal) = 0x100 = 2,6°C (gerundet), sagt zumindest die ETS
- Zeile 1244: value und orgValue sind gleich, deshalb wird nicht gelogged

Probiere:
- StateCmd abschalten oder mit einer kleinen Konstante befüllen
- PutCmd mit 1CD5 befüllen

Damit dürftest Du 99°C aus putCmd erhalten. Wenn der Wert deutlich kleiner ist, war es ggf. doch stateCmd, dann geht es weiter.

Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 25 April 2018, 07:33:39
Aaaalso
#1 ist es nicht.
#2 weiß ich nicht.
#3 vermutlich, da die Heizung aus ist ändert sich die Temperatur nicht oft.

Aber:
Dies funktioniert nicht und liefert den falschen Wert!
$value= ReadingsNum("tempSensor","temperature",0,1)

Das funktioniert und liefert 15,25°.
$value= ReadingsNum("tempSensor","temperature",0,1) + 0.01

Nun sollte ReadingsNum doch definitig eine Zahl zurückliefern?!?!!
Auch der Verzicht auf die Rundung durch oder das Runden auf 0 Nachkommastellen brachte keine Besserung.
Der Defaultwert "0" schlägt ebenfalls nicht zu, ein ündern bringt nichts.
Ich bleibe also im Moment bei der Schreibweise + 0.01. Bin mir aber sicher, dass das schon mal funktioniert hat!

Edit1:
Was ich festgestellt habe ist, dass ich aktuell 4 Antworten in der ETS bekomme! die erste von 0.0.0 ohne wert, danach 3x von 1.1.253 (knxd) den Wert "15,25°".
Anbei ein Screenshot dazu

Edit2:
Ein entfernen von :nosuffix erhöht die Antworten von 3x auf 4x, auch bei entferntem putCmd. putCmd sollte demnach auch nicht daran "schuld" sein.

sG Joe
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 25 April 2018, 09:01:44
Anbei noch ein Patch für Szenen dpt17.001.

DPT5 könnte ja auch genommen werden, ist aber immer um 1 zu niedrig.

Ob das die richtige bzw. Eleganteste Methode ist, kann ich leide rnicht sagen.
in der ETS kommt das richtige an, de rumgekehrte Weg geht leider nicht. Etwas in der ETS gesetztes kommt in FHEM nicht an.
Auch nach dem "set device szene 4" steht das reading des Devices nicht auf 4.

Dennoch, für mich nutze ich es mal, da das ständige umrechnen der szenen mit +1 für verwirrung sorgte ;-)



diff /mnt/SeaCloud/10_KNX.pm FHEM/10_KNX.pm
189a190,192
>
> #Szenen
>       "dpt17.001"              => {CODE=>"dpt17", UNIT=>"", FACTOR=>1, OFFSET=>1, PATTERN=>qr/[+-]?\d{1,5}/i, MIN=>0, MAX=>255},
1633c1636,1642
<       }
---
>       }
>       #Szenen
>         elsif ($code eq "dpt17")
>         {
>                 $numval = $value;
>                 $hexval = sprintf("00%.2x",($numval));
>         }
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 26 April 2018, 07:46:50
Edit3:
Also das mit "+ 0.01" hatte im test die Auswirkung, dass statt 3, 4 Telegramme auf den Bus gescgickt wurden, von daher wurde scheinbar dadurch dann ein anderes Ergebnis angezeigt.
der erste gesendete Wert hatte noch immer die 2,56°, die anderen die korrekte Temperatur. Der Sender war bei allen Telegrammen der KNXD.

Hilft das weiter?

sG
Joe
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 26 April 2018, 10:03:25
Nein, tut es nicht.

Nochmal:

Hast Du stateCmd mal weegelöscht oder durch eine Konstante ersetzt? Was passiert dann?
Hast Du in putCmd eine andere Konstante reingeschrieben? Dann dürfte ein anderer Wert gesendet werden...

Wenn ich recht habe, wird wieder gelogged...
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 26 April 2018, 10:54:40
Hier ein Screenshot mit gemachten Tests.

Was mich besonders wundert:
1. ich bekomme 4-6 Antworten auf dem Bus bei einer Anfrage aus der ETS heraus. (ist das ein Fehler im Modul?)
2. besonders Test 6: Bei konstantem putCmd sollte keine andere Antwort geliefert werden, oder?
Hier wird 5x die Konstante und danach 1x ein anderer Wert geschickt.
3. bei Prüfung 4: putCmd ist nicht vorhanden, stateCMD auf Konstant 20. Diese wurde auch schon aktualisiert! Dennoch gibt eine Leseanfrage auf das Device welches 18,81 als Wert an ETS zurück liefert. Kommt der Wert aus einer internen, noch alten Variable?

Was ich geprüft habe:
1. Wenn ich in FHEM diese eine GAD ändere, bekomme ich in der ETS keine Antworten. Es antwortet also kein anderes Device!


Logs reiche ich noch nach.

Edit: Hier die Logs zu 2 Fällen: Sehen eigentlich ganz ok aus bis auf die Mehrfachausführung
Log1 putCmd = {$value=21}:
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: encode value: 21, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 21
5: encode normalized value: 21
5: encode model: dpt9.001, code: dpt9, value: 21, numval: 3098, hexval: 000c1a
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000c1a, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: encode value: 21, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 21
5: encode normalized value: 21
5: encode model: dpt9.001, code: dpt9, value: 21, numval: 3098, hexval: 000c1a
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000c1a, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: encode value: 21, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 21
5: encode normalized value: 21
5: encode model: dpt9.001, code: dpt9, value: 21, numval: 3098, hexval: 000c1a
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000c1a, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: encode value: 21, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 21
5: encode normalized value: 21
5: encode model: dpt9.001, code: dpt9, value: 21, numval: 3098, hexval: 000c1a
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000c1a, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: encode value: 21, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 21
5: encode normalized value: 21
5: encode model: dpt9.001, code: dpt9, value: 21, numval: 3098, hexval: 000c1a
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000c1a, READING: return-temp


Log 2: putCmd= {$value= int(rand(10))}
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: parse device hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A - put replaced via command {$value= int(rand(10))} - value: 0
5: encode value: 0, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 0
5: encode normalized value: 0
5: encode model: dpt9.001, code: dpt9, value: 0, numval: 0, hexval: 000000
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000000, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: parse device hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A - put replaced via command {$value= int(rand(10))} - value: 1
5: encode value: 1, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 1
5: encode normalized value: 1
5: encode model: dpt9.001, code: dpt9, value: 1, numval: 100, hexval: 000064
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000064, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: parse device hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A - put replaced via command {$value= int(rand(10))} - value: 9
5: encode value: 9, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 9
5: encode normalized value: 9
5: encode model: dpt9.001, code: dpt9, value: 9, numval: 900, hexval: 000384
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000384, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: encode value: 9, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 9
5: encode normalized value: 9
5: encode model: dpt9.001, code: dpt9, value: 9, numval: 900, hexval: 000384
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000384, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: parse device hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A - put replaced via command {$value= int(rand(10))} - value: 3
5: encode value: 3, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 3
5: encode normalized value: 3
5: encode model: dpt9.001, code: dpt9, value: 3, numval: 300, hexval: 00012c
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 00012c, READING: return-temp
5: parse: process message, device-name: knx.quad8.temp2, rd-name: temperature, gadCode: 01015, model: dpt9.001
5: decode value: 0cb0, gadName: temperature
5: decode model: dpt9.001, code: dpt9, value: 0cb0
5: decode model: dpt9.001, code: dpt9, value: 0cb0, numval: 24, state: 24.00 &deg;C
5: received hash (wpi): HASH(0x563ea588c060) name: knx.quad8.temp2, STATE: 24.00 &deg;C, READING: temperature, SENDER: 01103
5: parse: process message, device-name: knx.quad8.temp2, rd-name: temperature, gadCode: 01015, model: dpt9.001
5: decode value: 0cb0, gadName: temperature
5: decode model: dpt9.001, code: dpt9, value: 0cb0
5: decode model: dpt9.001, code: dpt9, value: 0cb0, numval: 24, state: 24.00 &deg;C
5: received hash (wpi): HASH(0x563ea588c060) name: knx.quad8.temp2, STATE: 24.00 &deg;C, READING: temperature, SENDER: 01103
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 26 April 2018, 19:58:54
So...

Ich lade nochmal einen kleinen Patch hoch. Es gab noch ein Problem bei nicht gesetztem putString.

Ansonsten kann ich bis auf die Rundungsfehler Deine Beandstandungen nicht nachvollziehen.
StateCmd schreibt brav bei jedem empfangenen Telegram den Wert in das korrespondierende Reading und ab diesem Zeitpunkt auch in die Antwort. Vorher natürlich der alte Wert, weil stateCmd ja noch nicht ausgeführt wurde.

Die Mehrfachantworten bekomme ich NIE.

Sicher, dass Du nicht irgendwelche Schweinereien / Relikte / Überbleibsel in Deinem System hast?

Sorry, aber ich kann es nicht nachvollziehen...
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 26 April 2018, 20:10:25
Zitat von: Andi291 am 26 April 2018, 19:58:54
Die Mehrfachantworten bekomme ich NIE.

Sicher, dass Du nicht irgendwelche Schweinereien / Relikte / Überbleibsel in Deinem System hast?


Eigentlich schon. Werde nächste Woche nochmal genauer draufschauen, muss jetzt auf Dienstreise....

Danke, und schöne Grüße, Joe
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 09 Mai 2018, 12:09:42
Dieser GAD-Name funktioniert nicht und wird durch getG18 als Reading beim eintreffen eines Telegrammes ersetzt:
6/3/201:dpt9.001:temp-desired-roomGet:nosuffix

sG
Joe
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 09 Mai 2018, 20:57:26
Poste bitte das Log5 beim Laden des Devices.
Ich nehme an, er verkraftet das "get" im Namen nicht...
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 09 Mai 2018, 21:02:17
Hi Andi,
bin auf Dienstreise... am Montag gehts wieder!

sG
Joe
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 14 Mai 2018, 08:47:35
Hallo Andi:

Selbst auf einem frischen FHEM ohne andere Devices wird
defmod knxTest6 KNX 6/3/213:dpt9.001:temp:nosuffix
attr knxTest6 DbLogExclude .*
attr knxTest6 IODev KNX
attr knxTest6 putCmd {\
  if ($gad =~ /temp/) {\
   $value= ReadingsNum("knxTest6","temp",0,2)+1;;\
  }\
}
attr knxTest6 verbose 5
attr knxTest6 widgetOverride widgetOverride:textField-long\
eventMap:textField-long\
stateCmd:textField-long\
putCmd:textField-long

setstate knxTest6 2018-05-14 08:43:23 temp 6


mehrfach aufgerufen, wenn ich aus der ETS ein Get auf 6/3/213 absetze.
Erwarten würde ich mir den Rückgabewert 7 (+1), erhalte jedoch 10.
Dies hängt jedoch hier mit "nosuffix" zusammen.

sG Joe
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 14 Mai 2018, 20:29:19
Servus!

1. Was passiert ohne Rundungsparameter, also mit "$value= ReadingsNum("knxTest6","temp",0)+1;;"?
2. Was genau bedeutet mehrfach aufgerufen? Das zugehörige Event? Muss so sein, weil FHEM nicht unterscheiden kann (zwischen put und get)...
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 15 Mai 2018, 14:06:07
Noch was gefunden beim testen der oberen Punkte:.
wenn eine EVENT eines Aktors in der ETS auf 2 GADs gesendet wird (parametriert) und beide GADs in dem KNX-Modul in einem Device enden,
wird nur die erste GAD aktualisiert. Die zweite bleibt unverändert.

sG
Joe
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 15 Mai 2018, 15:18:49
Zitat von: Andi291 am 09 Mai 2018, 20:57:26
Ich nehme an, er verkraftet das "get" im Namen nicht...

Und das set auch nicht. Nicht mal als "setzen". hier ein Beispiel:

defmod knxTest7 KNX 6/3/213:dpt2:mode-auto-setzen:nosuffix
attr knxTest7 DbLogExclude .*
attr knxTest7 verbose 5
attr knxTest7 widgetOverride widgetOverride:textField-long\
eventMap:textField-long\
stateCmd:textField-long\
putCmd:textField-long
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 19 Mai 2018, 10:05:49
Fixed...Nun sind auch set und get im Namen erlaubt
Titel: Antw:Neues major release zum Test
Beitrag von: pandabear_de am 21 Mai 2018, 21:29:42
Hi,
im aktuellen Release scheint die Ergänzung wg dpt7.007 und der Fix wg dpt7.006 ('m' statt 's') nicht enthalten zu sein...

Zeile 144
"dpt7.006" => {CODE=>"dpt7", UNIT=>"m", FACTOR=>1, OFFSET=>0, PATTERN=>qr/[+-]?\d{1,5}/, MIN=>0, MAX=>65535},
"dpt7.007" => {CODE=>"dpt7", UNIT=>"h", FACTOR=>1, OFFSET=>0, PATTERN=>qr/[+-]?\d{1,5}/, MIN=>0, MAX=>65535},


Zeile 1916
dpt7.006 0..65535 m<br>
dpt7.007 0..65535 h<br>


Zeile 2187
dpt7.006 0..65535 m<br>
dpt7.007 0..65535 h<br>


Gruß
Jakob
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 22 Mai 2018, 09:36:41
Servus!

Beziehst du dich auf die Version aus dem Threads oder auf die offizielle?
Titel: Antw:Neues major release zum Test
Beitrag von: pandabear_de am 22 Mai 2018, 13:28:46
Auf die die ich gestern mit ,Update' in FHEM gezogen habe.
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 22 Mai 2018, 14:45:52
Ja, klar.
Die Änderungen in diesen thread gibts nur im Anhang von Post #1.
Titel: Antw:Neues major release zum Test
Beitrag von: pandabear_de am 22 Mai 2018, 21:54:47
Vielleicht eine Dumme Frage... Ist dies die Aufforderung meine Anpassung selbst einzuchecken?
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 23 Mai 2018, 06:29:53
NEIN...auf keinen Fall...

Wenn ausreichend positives Feedback zu dieser Testversion da ist, checke ich diese ein.
Momentan hab ich aber erst zwei Rückmeldungen - das ist mir noch zu wenig...
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 23 Mai 2018, 06:57:41
Ich glaube, pandabaer gehts um die Ergänzung des dpt7.007, der in dieser Testversion nicht enthalten ist....
Ich bräuchte den übrigens aktuell auch und nehme daher die von ihm gepatchte Version ;-).
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 23 Mai 2018, 12:41:55
Hallo Andi:
Versuche gerade einen Formatumwandler umzusetzen.
Es geht um die Einstellung Sommer/Winter.
Ich habe 2 Device, einer benötigt einen 1-Bit Datentyp, der andere 2-Bit.

Der 2-Bittige funktioniert nach dem Prinzip
0 => ,,Zwangsbit" nicht gesetzt => Automatik Modus
1 => ,,Zwangsbit" nicht gesetzt => Automatik Modus
2 => ,,Zwangsbit" gesetzt und bit0=0 => ,,off" -> Sommermodus
3 => ,,Zwangsbit" gesetzt und bit0=1 => ,,forced" -> Wintermodus
(bit1= Zwangsführung, bit0=Status Zwangsführung)




Anbei das Device, mit dem ich das umzusetzen versuche:

defmod knxTest8 KNX 4/0/253:dpt1.000:mode-auto-zentral1B:nosuffix\
4/0/249:dpt2:mode-auto-zentral2B:nosuffix\

attr knxTest8 DbLogExclude .*
attr knxTest8 IODev KNX
attr knxTest8 putCmd {\
if ($gad =~ /mode-auto-zentral2B/) {\
   $value= ReadingsVal("knxTest8",$gad,0);;\
  }\
  elsif ($gad =~ /mode-auto-zentral1B/) {\
   $value= ReadingsNum("knxTest8",$gad,0);;\
  }\
}
attr knxTest8 room 1-Handy,5-Todo,KNX
attr knxTest8 userReadings tmp:mode-auto-zentral1B.* {\
  if ($eventValue ==1){\
     fhem("set knxTest8 mode-auto-zentral2B forceoff");;\
   return "Debug: forceoff ";;\
    }\
  elsif ($eventValue ==0){\
   fhem("set knxTest8 mode-auto-zentral2B forceon");;\
   return "Debug: forceon ";;\
    }\
#   return "Debug: n";;\
}
attr knxTest8 verbose 5
attr knxTest8 widgetOverride widgetOverride:textField-long\
eventMap:textField-long\
stateCmd:textField-long\
putCmd:textField-long

setstate knxTest8 forceOn
setstate knxTest8 2018-05-23 12:36:53 STATE forceOn
setstate knxTest8 2018-05-23 12:39:07 last-sender 1/1/252
setstate knxTest8 2018-05-23 12:36:53 mode-auto-zentral1B 1
setstate knxTest8 2018-05-23 12:39:07 mode-auto-zentral2B forceOn
setstate knxTest8 2018-05-23 12:39:07 state forceOn



Wobei mode-auto-zentral1B 1 Bit ist, und mode-auto-zentral2B 2-Bittig.
Ich erhalte hier jedoch immer eine Recursion in FHEM, verstehe jedoch nicht genau, warum.

Hast Du dazu eine Idee? Wie würdest Du den umsetzen?
Habe es nur in der Testversion geprüft, da ich keinen Zugriff mehr auf die aktuelle offiziele habe.

Für den Test setze ich einfach in der ETS auf 4/0/253 on oder off ab.

Danke, sG Joe.
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 23 Mai 2018, 19:38:16
Moin!

Ich hab die Richtung und das Mapping noch nicht genau verstanden...

on --> forceOn
off --> forceOff

?
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 23 Mai 2018, 19:51:47
Zitat von: Andi291 am 23 Mai 2018, 19:38:16
Ich hab die Richtung und das Mapping noch nicht genau verstanden...
Genau! Wobei im Aktor immer von Zwangsbit gesprochen wird, und ich das Force hoffe so richtig interpretiert zu haben..... aber ich denke, das könnte ich austauschen, wenn
mein Weg stimmt und er nicht mehr zu Recursionen führt... (und dabei habe ich bewußt den weg zurück noch nicht umgesetzt, obwohl das natürlich auch irgendwann mal gehen sollte, im selben device mit den selben GADs).

sG Joe
Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 23 Mai 2018, 20:16:31
Nochmal die Frage:

3 --> on
2 --> off

oder

1 --> on
0 --> off

oder

on --> 1
off --> 0

oder

on --> 3
off --> 2

?
Titel: Antw:Neues major release zum Test
Beitrag von: JoeALLb am 23 Mai 2018, 20:24:19
Dpt1 auf dpt2
1 --> forceOn
0 --> firceOff

Dpt2 auf dpt1
Off --> 0 (Off)
On --> 1
ForcedOff --> 0
ForcesOn --> 1

Titel: Antw:Neues major release zum Test
Beitrag von: Andi291 am 23 Mai 2018, 21:23:18
So:

define knx.Test1 KNX 15/1/14:dpt1 15/1/15:dpt2
attr knx.Test1 IODev knxd
attr knx.Test1 stateCmd {\
  my $v = ReadingsVal("knx.Test1", $rdString, "default");;\
  if ($rdString =~ m/getG1/i)\
  {\
    fhem("set knx.Test1 g2 forceon") if ($v =~ m/on/i);; \
fhem("set knx.Test1 g2 forceoff") if ($v =~ m/off/i);; \
  }\
  elsif ($rdString =~ m/getG2/i)\
  {\
    fhem("set knx.Test1 g1 on") if ($v =~ m/on/i);; \
fhem("set knx.Test1 g1 off") if ($v =~ m/off/i);; \
  }\
  return $v;;\
}