[gelöst] Neue Version (Test): AnwerOnReading, DPT6, DPT16 senden

Begonnen von Andi291, 17 September 2015, 22:01:10

Vorheriges Thema - Nächstes Thema

Alveole

So, ein Tag mit einigen Tests verlief ohne Probleme. Die log-Datei ist jetzt auch aufgeräumter. Super!
2 Dinge hätte ich noch:

Könnte man bei dem log-Eintrag bei fehlendem model noch die Gruppenadresse oder den Namen mit ausgeben? Dies würde das finden und beheben erleichtern.
Zitat2015.09.23 15:26:48 3: EIB encode: no model defined. Replaced with DPT1.

bei mir kommen in unregelmäßigen Abständen folgende Fehlermeldungen die zum stop von fhem führen. Nur durch die Überwachung mit Monit wird fhem wieder gestartet.
Zitat2015.09.23 10:27:00 3: Control Byte 0x12 does not match expected mask 0xB0
2015.09.23 10:27:00 3: TUL EIB refused message: 120c191ec20080
2015.09.23 10:28:18 3: Control Byte 0x18 does not match expected mask 0xB0
2015.09.23 10:28:18 3: TUL EIB refused message: 18bc12031901c300
2015.09.23 10:28:19 3: Control Byte 0x07 does not match expected mask 0xB0
2015.09.23 10:28:19 3: TUL EIB refused message: 07ddd3bc12031900c200
2015.09.23 10:29:59 3: Control Byte 0x00 does not match expected mask 0xB0
2015.09.23 10:29:59 3: TUL EIB refused message: 0009bc1203190ac200800003bc113300
2015.09.23 10:29:59 1: tul:/dev/ttyACM0@57600 disconnected, waiting to reappear
2015.09.23 10:30:03 0: Server shutdown
2015.09.23 10:30:07 1: reload: Error:Modul 99_email deactivated:

2015.09.23 10:30:07 1: Including fhem.cfg
2015.09.23 10:30:07 3: TUL opening EIB device tul:/dev/ttyACM0@57600
2015.09.23 10:30:07 3: TUL setting EIB baudrate to 57600
2015.09.23 10:30:07 3: TUL device opened
2015.09.23 10:30:09 2: eventTypes: loaded 2387 events from ./log/eventTypes.txt
2015.09.23 10:30:09 1: Including /opt/fhem/web.cfg
2015.09.23 10:30:09 3: telnetPort: port 7070 opened
2015.09.23 10:30:10 3: WEB: port 8083 opened
2015.09.23 10:30:10 3: WEBphone: port 8084 opened
2015.09.23 10:30:10 3: WEBtablet: port 8085 opened
2015.09.23 10:30:10 1: Including /opt/fhem/allgemein.cfg
2015.09.23 10:30:11 1: Including /opt/fhem/wohnen.cfg
2015.09.23 10:30:12 1: Including /opt/fhem/kueche.cfg
2015.09.23 10:30:13 1: Including /opt/fhem/diele-eg.cfg
2015.09.23 10:30:13 1: Including /opt/fhem/diele-og.cfg
2015.09.23 10:30:13 1: Including /opt/fhem/bad.cfg
2015.09.23 10:30:14 1: Including /opt/fhem/keller.cfg
2015.09.23 10:30:15 1: Including /opt/fhem/heizung.cfg
2015.09.23 10:30:15 1: Including /opt/fhem/garten.cfg
2015.09.23 10:30:16 1: Including /opt/fhem/wetter.cfg
2015.09.23 10:30:17 1: Including /opt/fhem/schaltuhr.cfg
2015.09.23 10:30:17 1: Including /opt/fhem/mail-sms.cfg
2015.09.23 10:30:17 1: Including /opt/fhem/floorplan-eg.cfg
2015.09.23 10:30:18 1: Including /opt/fhem/test.cfg
2015.09.23 10:30:19 1: Including ./log/fhem.save
2015.09.23 10:30:20 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2015.09.23 10:30:20 0: Featurelevel: 5.6
2015.09.23 10:30:20 0: Server started with 277 defined entities (version $Id: fhem.pl 9218 2015-09-09 19:43:43Z rudolfkoenig $, os linux, user fhem, pid 14468)

Ideen was das ist?

Danke!

Alveole

#16
es gibt leider doch nocht Probleme  :-[

define Bad_umstell EIB 3202
attr Bad_umstell IODev EIB


define Bad_umstell_v dummy
attr Bad_umstell_v alias Heizmodus Bad
attr Bad_umstell_v devStateIcon 01:tag 02:status_away_2 03:nacht 04:secur_frost_protection
attr Bad_umstell_v group Klima
attr Bad_umstell_v room Bad
attr Bad_umstell_v sortby 1
attr Bad_umstell_v webCmd Tag:Standby:Nacht
define umstellen11 notify Bad_umstell_v:Nacht set Bad_umstell value "03"
define umstellen12 notify Bad_umstell_v:Standby set Bad_umstell value "02"
define umstellen13 notify Bad_umstell_v:Tag set Bad_umstell value "01"


diese bis her funktionierenden notifys führen zum Absturz von fhem!

Das Problem scheint zu sein, das die Raumregler DPT20.102 erwarten. Diesen Typ gibtes aber nicht und kein model ist definiert. Somit springt das automatisch auf DPT1 um und das versteht der Raumregler logisch nicht.

Protokolldatei anbei.

Andi291

Hallihallo,

ja, das kann ich erklären. Bisher wurden alle Nachrichten, egal ob ein gültiger DPT angegeben war, oder nicht, durchgeroutet. Anteilig auch mit Fehlern. Das hab ich unterbunden...
Da Du kein Model definiert hast, wird die ankommende Nachricht nicht weiter behandelt.

Warum sich dadurch FHEM aufstellt, muss ich noch prüfen...

Fürs erst würde es reichen, wenn Du den "Pseudo-DPT20" ein model DPT5 zuweist...

Aber ich schau trotzdem nochmal nach...

Grüße, Andi

Andi291

Anbei eine Testversion NUR FÜR ALVEOLE!

Folgendes Verhalten:
Nach wie vor wird ein model erwartet. Wenn kein model, dann DPT1. Wird was anderes als 00, 01, on, off übergeben, wird nicht platt abgebrochen, sondern der Eingabewert nach Hex umgewandelt und weiter gemacht.
Erzeugt zwar Datenmüll, aber keinen Absturz.

In Deinem Fall KÖNNTE es sogar ohne model funktioneren - ist aber trotzdem nicht schön :-)

Bitte um Test und Rückmeldung.

Grüße, Andi

Alveole

Danke!
Habs gleich noch probiert:
wenn ich alle entsprechenden Gruppenadressen auf DPT5 setze, funktioniert die Umschaltung ohne Probleme.
Der Log ist auch sauber (mit Ausnahme einer kurzen Meldung am Anfang?!). siehe Anhang! ich hab hier mehrfach hin und her geschalten - und es hat funktioniert!

Andi291

Morgen! Du hast noch die alte tul. Siehe threadanfang. Was passiert mit dem letzten modul, wenn du kein model setzt? Hoffentlich datensalat ohne absturz...

Andi291


eburkon

Hallo Andi,

Habs bei mir eingebaut. Antwortet ganz brav auf einen Read request. Danke!

Ekkehard
FHEM auf Rpi48G, KNX via knxd und IP Interface, Hue, FS20, und ein paare externe Sachen via MQTT

Alveole

funktioniert super!

nur eine Sache noch:
Vielleicht weis jemand Rat oder kann mir sagen, wo ich überhaupt suchen muss.
log-Datei:
Zitat2015.09.27 11:52:07 3: Control Byte 0x12 does not match expected mask 0xB0
2015.09.27 11:52:07 3: TUL EIB refused message: 12422164c30080
2015.09.27 11:52:11 3: Control Byte 0x26 does not match expected mask 0xB0
2015.09.27 11:52:11 3: TUL EIB refused message: 2616bc12422164c3
2015.09.27 11:52:18 3: Control Byte 0x80 does not match expected mask 0xB0
2015.09.27 11:52:18 3: TUL EIB refused message: 8024bc8dbc12422164
2015.09.27 11:52:21 3: Control Byte 0x00 does not match expected mask 0xB0
2015.09.27 11:52:21 3: TUL EIB refused message: 0080252010bc12422164c30080256555bc1242
2015.09.27 11:52:24 1: tul:/dev/ttyACM0@57600 disconnected, waiting to reappear
2015.09.27 11:52:29 3: TUL setting EIB baudrate to 57600
2015.09.27 11:52:29 1: TUL tul:/dev/ttyACM0@57600 reappeared (EIB)
2015.09.27 17:49:37 3: Control Byte 0x10 does not match expected mask 0xB0
2015.09.27 17:49:37 3: TUL EIB refused message: 100ebc11330033
2015.09.27 17:49:37 3: Control Byte 0x00 does not match expected mask 0xB0
2015.09.27 17:49:37 3: TUL EIB refused message: 00800cedf0bc11330032c300800cd3cfbc1133
2015.09.27 17:50:00 3: Control Byte 0x01 does not match expected mask 0xB0
2015.09.27 17:50:00 3: TUL EIB refused message: 01c300800efed3bc11330002c300800e1d33bc120c
2015.09.27 17:50:00 0: Server shutdown
2015.09.27 17:50:03 1: reload: Error:Modul 99_email deactivated:

2015.09.27 17:50:03 1: Including fhem.cfg
2015.09.27 17:50:03 3: TUL opening EIB device tul:/dev/ttyACM0@57600
.
weiter als normales booten
.

was passiert hier und warum stürzt fhem manchmal da ab und manchmal nicht.
Was kann ich dagegen tun?

Danke!

Andi291

Hallo Alveole,

wie per PM geschrieben - bitte sicherstellen, das auch die neue TUL drin ist und die letzeditierte EIB.
Dann mir ein Verbose 5 Log schicken.

So lange ich nicht weiß, was vorher passiert, kann ich nur Glaskugellesen :-P

Jedenfalls krieg ich die Message mit dem Kontrollbyte ums verrecken nicht reproduziert. Kann mir auch aktuell keinerlei Reim drauf machen, welche meiner Änderungen sich auf die Level-2-Schicht auswirken soll...

Interessehalber: Wie ist Dein KNX denn angebunden? Seriell? USB? Ethernet?

Alveole

Hallo,
Log läuft und folgt zeitnah wenn sich das ganze wieder gezeigt hat.

Angebunden ist das KNX per TUL - TPUART USB light Stick direkt an einer USB-Buchse des Raspi (Raspberry Pi B+). Die anderen USBs sind alle leer.
http://busware.de/tiki-index.php?page=TUL

in der fhem.cfg eingebunden per:
define EIB TUL tul:/dev/ttyACM0@57600 0.0.100

Andi291

Morgen! Die variante kannte ich bis jetzt noch nicht. Kannst du bitte mal einen knx/eib zwischenschalten?

Alveole

Ist diese Variante so ungewöhnlich???  :o
Vielleicht liegt es ja auch da dran.
Kann man denn was besseres empfehlen?

ich steh gerade aufm Schlauch? Was zwischenschalten?

aliate

Zitat von: Alveole am 28 September 2015, 12:02:31
Ist diese Variante so ungewöhnlich???  :o
Vielleicht liegt es ja auch da dran.
Kann man denn was besseres empfehlen?

ich steh gerade aufm Schlauch? Was zwischenschalten?

Mein raspi hängt auch mit dem stick von busware am bus. Einziger unterschied, bei mir läuft noch ein eibd.

Habe aktuell und hatte früher (ohne eibd) keine Probleme, d.h. nicht diese log-einträge wie du.

Andi291

Abend!

Ungewöhnlich weiß ich nicht. Ich persönlich kenne die Variante nicht.
Der eibd oder knxd ist ein Server, der die Kommunikation zum Bus regelt. Allem Anschein nach scheint der Fehler damit nicht aufzutreten...

Anyway - ich schau mir die Logs mal durch.

Nur nochmal zum Verständnis:

TUL "SVN" + EIB "SVN" --> kein Fehler
TUL "SVN" + EIB "Thread" --> Fehler
TUL "Thread" + EIB "Thread" --> Fehler
TUL "Thread" + EIB "SVN" --> ???

Grüße, Andi