[gelöst] Datentypen in 10_EIB-pm ergänzt

Begonnen von Andi291, 02 März 2015, 20:37:09

Vorheriges Thema - Nächstes Thema

Andi291

Hallihallo,

das weiß ich auch nicht. Wenn mal so 20..30 Tester grün zurück gemeldet haben, würd ich Rudolph König mal kontaktieren. Kenne mich da auch nicht so gut aus.
Insofern: bitte fleißig Testen!!!

MiWe58

Hallo,

nachdem ich gestern diese Neuerungen gelesen habe, machte ich mich gleich heute ans Testen.
Schon seit einiger Zeit versuche ich meine Wärmepumpe (Heliotherm) über KNX an FHEM anzubinden, was bisher nicht geklappt hat.

Mit der neuen 10_EIB.pm  hat es nun schon recht gut geklappt.

Einzig die Darstellung irritiert mich noch etwas. Vielleicht fällt euch hierzu etwas ein?
Werte von "TempRuecklauf" und "TempVorlauf" werde prinzipiell richtig dargestellt. Das Komma ist allerdings verschoben

define WP_TempAussen EIB 14/0/0
attr WP_TempAussen IODev KNX
attr WP_TempAussen model tempsensor
attr WP_TempAussen room 2.50_Heliotherm

define WP_TempBrauchwasser EIB 14/0/2
attr WP_TempBrauchwasser IODev KNX
attr WP_TempBrauchwasser model tempsensor
attr WP_TempBrauchwasser room 2.50_Heliotherm

define WP_TempVorlauf EIB 14/0/3
attr WP_TempVorlauf IODev KNX
attr WP_TempVorlauf model tempsensor
attr WP_TempVorlauf room 2.50_Heliotherm

define WP_TempRuecklauf EIB 14/0/4
attr WP_TempRuecklauf IODev KNX
attr WP_TempRuecklauf model tempsensor
attr WP_TempRuecklauf room 2.50_Heliotherm

define WP_TempPuffer EIB 14/0/5
attr WP_TempPuffer IODev KNX
attr WP_TempPuffer model tempsensor
attr WP_TempPuffer room 2.50_Heliotherm

define WP_HKRHeizgrenze EIB 14/1/76
attr WP_HKRHeizgrenze IODev KNX
attr WP_HKRHeizgrenze model tempsensor
attr WP_HKRHeizgrenze room 2.50_Heliotherm

define WP_WWTempSoll EIB 14/1/83
attr WP_WWTempSoll IODev KNX
attr WP_WWTempSoll model tempsensor
attr WP_WWTempSoll room 2.50_Heliotherm




Gruß
Michael
Devices: RasPi V, HomeMatic, PICCU, Modbus, Heliotherm-Wärmepumpe, SMA PV-Anlage, Easee Laderoboter
Steuerung: Rollos, Beleuchtung, Heizung-Heliotherm, Heizung-Heizkreise, PV-Anlage-Eigenverbrauch, Alarm, Zugang, Wasser

antonwinden

Hallo,
Da hätte ich auch ein Anliegen :
wäre es möglich auch den Datentyp 14 (Float nach IEEE 754) zu integrieren?
Meine Schnittstelle für den Stromzähler liefert leider genau diese Typen...
auf der seite http://www.h-schmidt.net/FloatConverter/IEEE754de.html ist ein umrechner vorhanden nur mein perl ist praktisch nicht vorhanden.
wäre super
anton
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

Andi291

Hallo,

Du zum Lesen/Empfangen ist der Datentyp bereits drin:

   } elsif ($code eq "dpt14") # contributed by Olaf
       {
           ...
   }

Funktioniert auch bombig. Nur Schreiben/Senden geht nicht. Musst Du zwingend Senden, oder reicht Dir Empfangen?

antonwinden

stimmt schon das der Typ drinnen ist nur funktioniert es nicht - zumindestens bei mir ergibt dpt12 das gleiche wie dpt14.
in ets kann ich mir im busmonitor aber die richtigen ergebnisse sehen.
z.b. ist 43F3E3D7  1140057047 in fhem in ets sehe ich aber die richtigen werte nämlich 487,78
auf http://www.h-schmidt.net/FloatConverter/IEEE754de.html kommt auch 487,78 raus

dpt 14 (14.000 bis 14.079) ist für unter anderem elektrische energie so genormt ("4-Octet Float Value")
4 octets: F32
4MSB 3 2 1LSB
The values are encoded in the IEEE floating point format according IEEE 754.

S Exponent.......I   Fraction
F F F F F F F F  F F F F F F F F  F F F F F F F F  F F F F F F F F

S (Sign) Exponent Fraction
= {0,1}
= [0 ... 255]
= [0 ... 8 388 607]

danke anton
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

Andi291

Aaaah! Verstanden. Funktion Kaputt :-)

Ich bei Gelegenheit schau mal drauf...

antonwinden

KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

Andi291

Hallo Anton,

also bei mir geht's ohne weitere Änderungen:

2015.03.31 18:40:20 1: Byte: 66, Sign: 1, Bytee: 17136, Exp: 6, Bytem: 15728640, Mant: 15728640
2015.03.31 18:40:20 1: EIB dpt14 parse 42f00000 translated: 120
2015.03.31 18:41:36 1: Byte: 67, Sign: 1, Bytee: 17395, Exp: 8, Bytem: 15983575, Mant: 15983575
2015.03.31 18:41:36 1: EIB dpt14 parse 43f3e3d7 translated: 487.779998779297

Nimm bitte meine 10_EIB.pm von Seite 1, stelle Dein LogLevel auf 5 und poste mal die relevanten Zeilen...

antonwinden

#23
werd ich machen -
so hab es jetzt riskiert und es funktioniert tatsächlich richtig - super

merci anton
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

antonwinden

Danke für die Super Arbeit - bei mir funktionieren jetzt die Datentypen die ich brauche.
Fehlt nur mehr loglevel zu streichen und dafür verbose reinzugeben  8) dann wäre es glatt aktuell gepflegt.
danke anton
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

Andi291

Hallo Anton,

gerne.

Was genau meinst Du? Das "spammen" ins fhem-Log bei großem Loglevel ist in der Version ebenfalls deaktiviert...
Mit gesetztem Loglevel 2 bekomme ich keine Einträge mehr im normalen Log.

aliate

Das Log ist sauber, kann ich nur bestätigen :)

Gibt es eine Möglichkeit die normalen EIB-Schaltvorgänge (z.B. Licht ein/aus) ins Log zu bekommen?
Kann bei verbose und loglevel einstellen was ich will, bzgl. EIB-Bewegungen kommt nichts mehr in die Log-Datei.

Andi291

Abend!

Ja, es gibt ne radikale Möglichkeit :-P
Wenn Du das Log-Level auf 5 stellst, kriegst Du alles, was Du möchtest:

2015.04.02 19:31:54 5: Received packet: 00271289423d0080

2015.04.02 19:31:54 5: decode_eibd byte len: 1 array size: 1
2015.04.02 19:31:54 5: SimpleRead msg.type: write, msg.src: 1289, msg.dst: 823d
2015.04.02 19:31:54 5: SimpleRead data: 00
2015.04.02 19:31:54 4: SimpleRead: B1289w823d00

2015.04.02 19:31:54 4: tul: B1289w823d00
2015.04.02 19:31:54 5: tul dispatch B1289w823d00
2015.04.02 19:31:54 4: EIB parse off for rtr_flur_og_heizen model: fs20 dpt: HASH(0x11fed88)
2015.04.02 19:31:54 4: EIB parse off for rtr_flur_og_heizen model: fs20 dpt:  unit:
2015.04.02 19:31:54 4: EIB rtr_flur_og_heizen model fs20 value off could not be translated.
2015.04.02 19:31:54 5: EIB rtr_flur_og_heizen off
2015.04.02 19:31:54 5: Triggering rtr_flur_og_heizen (2 changes)
2015.04.02 19:31:54 5: Notify loop for rtr_flur_og_heizen off

Was genau hättest Du Dir den vorgestellt?
Meiner Meinung nach haben die Daten nichts im fhem-log verloren. Du kannst ja prinzipiell alle Elemente parallel in mehrere Logs schreiben - dann hast Du auch wieder alles beieinander...

aliate

Ursprünglich, in der originalen EIB_pm landete ja alles was EIB/KNX betrifft im Log. Ganz egal was man in den einzelnen EIB-Geräten bei verbose/loglevel eingestellt hat.
Ich hatte von jedem Gerät die on/off Meldungen im Log stehen.

014.12.30 11:50:46 2: EIB Garage_Licht on
2014.12.30 11:50:49 2: EIB EIB_4001 off
2014.12.30 11:50:49 2: EIB EIB_4000 off
2014.12.30 11:50:50 2: EIB Keller_Treppe on
2014.12.30 11:50:52 2: EIB Putzen off
2014.12.30 11:51:03 2: EIB EIB_3204 off
2014.12.30 11:51:03 2: EIB Garage_Licht on
2014.12.30 11:51:08 2: EIB Keller_Holz_Rechts on
2014.12.30 11:51:08 2: EIB Keller_Holz_Links on


Das war mir definitiv zu viel, weil da Geräte/Meldungen dabei sind die zum einen im Sekundenabstand kommen und das Log zumüllen und zum anderen mich die Geräte auch nicht interessieren.
Der Jetzt-Zustand ohne "spammerei" ist mir also ganz recht.

Es gibt jedoch ein paar Schalter, da würden mich die Logeinträge schon interessieren, zumindest wenn es um Fehlersuche geht. Mir geht es hier nur um diese "on/off" Meldungen.

Verbose im Gerät global steht bei mir auf 3 und ich kann auch bei den einzelnen EIB-Geräten einstellen was ich will, die Einträge kommen nicht ins Log.

Hast du da vielleicht eine Idee?

antonwinden

#29
Zitat von: Andi291 am 02 April 2015, 18:38:48
Hallo Anton,

gerne.

Was genau meinst Du? Das "spammen" ins fhem-Log bei großem Loglevel ist in der Version ebenfalls deaktiviert...
Mit gesetztem Loglevel 2 bekomme ich keine Einträge mehr im normalen Log.
ich meinte damit das wenn ich es richtig verstanden habe loglevel nicht mehr loglevel genannt werden soll sondern verbose  8)
zumindestens soll man bei neuen modulen verbose statt loglevel einbinden - nur ein anderes wort für das gleiche...

was wichtiger wäre ein implementieren von event-on-change-reading damit kann man ein zumüllen von logfiles mit immer gleichen werten vermeiden.
ist hier beschrieben: http://forum.fhem.de/index.php/topic,32716.0.html
überdrüber wäre dazu noch ein prozentwert der angibt ab welcher änderung ein notify bzw ein schreiben ins logfile erfolgen soll - diese schwelle kann man leider nicht bei jedem gerät in ets einstellen... ist aber nicht wirklich notwendig da wohl eher nicht systemkonform
danke anton
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...