dpt7 Wert Senden

Begonnen von Xcoder, 23 Juli 2015, 23:24:08

Vorheriges Thema - Nächstes Thema

Xcoder

Hallo,

Bei mir funktioniert das senden von dpt7 Werten nicht. Im ETS Gruppenmonitor werden "Ungültige Frames" angezeigt.
define EIB_0517 EIB 0517
attr EIB_0517 IODev tul
attr EIB_0517 icon light_on-for-timer
attr EIB_0517 model dpt7
attr EIB_0517 room Präsenz


Es geht um einen dpt 7.005 Zeit in Sekunden. Wird das Objekt als dpt9 definiert, kann man mit Faktor 100 kleineren Werden den richtigen Wert senden...


Gruss, Xcoder

Andi291

Abend,

hast Du die letzten Wochen mal ein Update gemacht? Ich hab am EIB-Modul einiges glatt gezogen. Unter anderem auch den DPT7. Der funktioniert (nach meiner ETS :-)) störungsfrei - nutze ich recht ausgiebig.
Dur schreibst was von Zeit - nicht dass DU den DPT verwechselt hast? Nur zur Sicherheit: DPT7 ist U16...

Grüße, Andi 291

Xcoder

Hallo,

Ja, fhem ist aktuell und neu gestartet... Trotzdem werden "ungültige Frames" auf den Bus geschickt.

Die Applikationsbeschreibung des Gerätes (Feller Pirios BWM), sagt klar dass es ein 7.005 ist um die Auschaltverzögerung in Sekunden einzustellen. U16 scheint mir da nicht so abwegig zu sein. Zudem sollte das ja egal sein, fhem sollte jeden Typ richtig senden können. Empfange funktioniert ja auch korrekt. War da nicht auch mal das gleiche Problem bei dpt9?

Gruss, Xcoder

Andi291

Hallo,

doch...

Aber: bei mir funktioniert es...Kannst Du mir ein wenig mehr Futter geben? Bsp. fhem-log mit Level 5 und ein passendes ETS-Tracefile?

Grüße, Andi

Andi291

Abend!

Mea culpa - es ging wohl doch nicht.

@Erwin: Du erinnerst Dich an die Sonderbehandlung für DPT7 im Write? Das wars...
@Erwin und XCoder: Bitte Version im Anhang mal  aus Seiteneffekte gegenprüfen, bevor ich diese online stelle. Erster Quick-check positiv.

Grüße, Andi291

erwin

#5
ich kann mich erinneren,
du hattest damals geschrieben "code ist nicht von mir", .... von mir ist er auch nicht, verstanden hab ich ihn damals auch nicht!
Lösung: weg damit!  ;D
l.g. erwin

PS: die zeilen oberhalb deiner Änderung brauchts dann auch nicht mehr:

  my $groupcode = $hash->{CODE}{$groupnr};
#  $model = $attr{$name}{"model"}; ##MH
#  $model = "" unless defined($model); ##MH avoid uninit msg
#
#  my $code = $eib_dpttypes{"$model"}{"CODE"};
 
  #ABU removed due to incorrect DPT7-sending

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

nibblerrick

Wo wir hier gerade bei Werte senden sind, mir fehlte heute dpt20.*, bzw. konkret DPT20.105. Ich habe es mit dpt5 auch soweit hinbekommen, dass die passenden Meldungen ueber den Bus gehen.
Die definitionen im Sourcefile sehen so ja recht uebersichtlich aus, fast so, als waere es kein Riesenaufwand neue Datentypen dort hineinzubekommen.
Aber dank meines gerade mal leichten Verstaendnisses des Codes will ich hier nicht zuviel behaupten ;-)
Daher die Frage: Kann dieser Wert bei Gelegenheit mit einfliessen, oder was fuer Vorbereitungen und Informationen kann man noch zusammenbekommen, um dem Modulautor soweit wie moeglich vorzuarbeiten?

Andi291

Abend!

Hab mir den DPT20 mal angesehen - Problem isses nicht, aber aufwändig. Es geht halt keine Zahlenkonversion (generisch), sondern muss über Tabellen abgewickelt werden...

Ich legs mir mal unters Kopfkissen, aber eher mit Prio Y :-)

Grüße, Andi

nibblerrick

Das die einzelnen Untertypen Bestimmte Wertspezifikationen haben kann ich mir gerade vorstellen.
Aber hat der DPT20 als uebergeordneter Typ auch schon so spezifische Dinge oder muss der erstmal "nur" als 4 byte eingerichtet werden, den man dann mit entsprechenden Fuettern muss?
Achso, danke fuers unters Kopfkissen legen, damit ist es ja schonmal fuer die queue akzeptiert ;-)

Gruesse

Xcoder

Sorry, hatte jetzt erst Zeit das neue 10_EIB auszuprobieren. Leider funktioniert es bei mir noch nicht:

fhem level 5 log:
2015.08.09 09:12:27 4: Connection closed for FHEMWEB:10.76.1.137:65191: EOF
2015.08.09 09:12:27 4: HTTP FHEMWEB:10.76.1.137:65234 GET /fhem&cmd=set+EIB_0514+value+300
2015.08.09 09:12:27 5: Cmd: >set EIB_0514 value 300<
2015.08.09 09:12:27 5: EIB set EIB_0514 value 300
2015.08.09 09:12:27 4: EIB encode 300 for EIB_0514 model: dpt7 dpt: HASH(0x10e6c660)
2015.08.09 09:12:27 4: EIB encode 300 for EIB_0514 model: dpt7 dpt: dpt7 unit:
2015.08.09 09:12:27 5: EIB dpt7 encode 300 = 0012c translated: 0012c
2015.08.09 09:12:27 4: EIB EIB_0514 translated 300  to 0012c
2015.08.09 09:12:27 4: EIB parse 0012c for EIB_0514 model: dpt7 dpt: HASH(0x10e6c660)
2015.08.09 09:12:27 4: EIB parse 0012c for EIB_0514 model: dpt7 dpt: dpt7 unit:
2015.08.09 09:12:27 5: EIB dpt7 parse 0012c = 300 translated: 300
2015.08.09 09:12:27 4: EIB EIB_0514 translated to 300
2015.08.09 09:12:27 5: tul sending Bb05140012c
SimpleWrite data: 0 18
2015.08.09 09:12:27 3: Bad EIB message type

2015.08.09 09:12:27 5: SendGroup: dst: 0514, msg:

2015.08.09 09:12:27 5: sendRequest: 0027000000

2015.08.09 09:12:27 5: Triggering EIB_0514 (1 changes)
2015.08.09 09:12:27 5: Notify loop for EIB_0514 300


ETS log. Das erste Telegram ist von fhem mit dem obigen Kommando erzeugt. Das zweite Telegram ist wenn ich den Wert aus der ETS sende. Den Wert au der ETS senden funktioniert auch korrekt.
<CommunicationLog xmlns="http://knx.org/xml/telegrams/01">
  <Telegram Timestamp="2015-08-09T07:08:31.2865356Z" Service="Raw invalid frame" FrameFormat="CommonEmi" RawData="2900BCE0000000000000" />
  <Telegram Timestamp="2015-08-09T07:08:40.4101992Z" Service="L_Data.con" FrameFormat="CommonEmi" RawData="2E00BCD0000005140300800258" />
</CommunicationLog>

Xcoder

Sorry. Fehlalarm. Habe beim kopieren der Testversion von 10_EIB.pm die falsche Datei umbenannt. Mit der Testversion funktioniert das Senden von dpt7 Werten nun korrekt.

2015.08.09 09:35:08 4: HTTP FHEMWEB:10.76.1.137:65451 GET /fhem&room=Pr%C3%A4senz&cmd=set+EIB_0514+value+300
2015.08.09 09:35:08 5: Cmd: >set EIB_0514 value 300<
2015.08.09 09:35:08 5: EIB set EIB_0514 value 300
2015.08.09 09:35:08 5: EIB_EncodeByDatapointType: EIB_0514, Value= 300, model= dpt7
2015.08.09 09:35:08 4: EIB encode 300 for EIB_0514 model: dpt7 dpt: dpt7 unit:
2015.08.09 09:35:08 5: EIB dpt7 encode 300 = 00012c translated: 00012c
2015.08.09 09:35:08 4: EIB EIB_0514 translated 300  to 00012c
2015.08.09 09:35:08 5: EIB parse 00012c for EIB_0514 model: dpt7 dpt: dpt7 unit:
2015.08.09 09:35:08 4: EIB_ParseByDatapointType: EIB_0514, origval= 00012c, transval= 300, Group= 1, Model= dpt7, code= dpt7, unit=
2015.08.09 09:35:08 5: tul sending Bw051400012c
SimpleWrite data: 0 1 44
2015.08.09 09:35:08 5: encode_eibd dst: 0514 apci: 2 datalen: 3 data: 0 1 44
2015.08.09 09:35:08 5: SendGroup: dst: 0514, msg: 1300 0 128 1 44

2015.08.09 09:35:08 5: sendRequest: 002705140080012c

2015.08.09 09:35:08 5: Triggering EIB_0514 (1 changes)
2015.08.09 09:35:08 5: Notify loop for EIB_0514 300
2015.08.09 09:35:08 4: HTTP FHEMWEB:10.76.1.137:65451 GET /fhem?room=Pr%C3%A4senz
2015.08.09 09:35:08 4: 4936:FHEMWEB:10.76.1.137:65451: /fhem?room=Pr%C3%A4senz / RL:10369 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.08.09 09:35:08 5: Received packet: 0027000005140080012c

2015.08.09 09:35:08 5: decode_eibd byte len: 3 array size: 3
2015.08.09 09:35:08 5: SimpleRead msg.type: write, msg.src: 0000, msg.dst: 0514
2015.08.09 09:35:08 5: SimpleRead data: 012c
2015.08.09 09:35:08 4: SimpleRead: B0000w0514012c

2015.08.09 09:35:08 4: tul: B0000w0514012c
2015.08.09 09:35:08 5: tul dispatch B0000w0514012c
2015.08.09 09:35:08 5: EIB parse 012c for EIB_0514 model: dpt7 dpt: dpt7 unit:
2015.08.09 09:35:08 4: EIB_ParseByDatapointType: EIB_0514, origval= 012c, transval= 300, Group= 1, Model= dpt7, code= dpt7, unit=
2015.08.09 09:35:08 5: EIB EIB_0514 300
2015.08.09 09:35:08 5: Triggering EIB_0514 (1 changes)
2015.08.09 09:35:08 5: Notify loop for EIB_0514 300


Vielen Dank.