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

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

Vorheriges Thema - Nächstes Thema

Andi291

Hallo zusammen,

da einige Anfragen aufgelaufen sind, hier einige Lösungen zum Test :-)

TUL:
- Hab den Log-Spammer "Simple Write" endgültig entfernt

EIB:
- cleaned up
- implemented DPT16 for sending
- implemented DPT6
- added EIBanswerOnRead
- changed time/date-handling
- fixed DPT14-sending
- removed Root-Causes for several warnings

Bitte testen und Rückmelden. Würde die Version gerne bald einchecken.

Grüße, Andi

Andi291

N'Abend,

soho - habe noch ein paar Nerven investiert, um die Warnings rings um die DPT16 auszurotten.

Wie ich meine, mit Erfolg...

Grüße, Andi

EIB-Fan

Hallo Andi291,

habe inzwischen mehrere Tests mit der neuen 10_EIB.pm bezüglich des sendens des DPT16 durchgeführt.

Das klappt prima.  :)

Einen Bug scheint es allerdings zu geben.  ???

Wenn der Buchstabe "g" im Text vorkommt, erscheint die Fehlermeldung "groupnr not know".

Getestet habe ich dies mit:

set Text_Nachricht value g

set Text_Nachricht string g

Alle anderen Texte in meinem Test wurden problemlos übertragen (z. B "set Text_Nachricht value abcdef" oder "set Text_Nachricht string abcdef").

Der Fehler tritt bei deiner Version vom 17.09. als auch vom 19.09.2015 auf.

Welcher Syntax soll bei der Übertragung von Texten genutzt werden?

value oder string

An diesem Punkt noch einmal Danke für die bisher geleistete Arbeit!

Viele Grüße

Jens

Andi291

Morgen jens. Sollte dokumentiert sein :-)

set string mein text

Ich musste das keyword string wegen des von dir beschriebenen problems einführen.
Hinweis: delimiter werden 7bertragen, also im normalfall eher weglassen...

Andi291

Also korrekt set mein-text string hallo hugo

Ich schau nochmal nach g :-)

aliate

Servus Andi,

habe beide Module im Einsatz und sie laufen bisher ohne Probleme.Das Log ist nun auch absolut sauber!
Die neuen Features im EIB-Modul habe ich auf Grund fehlender Geräte nicht getestet.

Vielen Dank für die tolle Arbeit!

Gruß

Andi291

Hallo Jens,

Dein Problem mit dem "g" kann ich nachstellen...

Bin auf der SUche...

Grüße, Andi

Andi291


EIB-Fan

Hallo Andi,

habe es getestet. DPT16 senden funktioniert jetzt auch mit "g".  :)

Danke!

Gruß Jens

ZeitlerW

#9
Hallo Andi291,

read requests funktioneren bei mir! Ein kleiner Schönheitsfehler  :): Standardmäßig wird ein EIB Device ja ohne Modell angelegt. Wenn man auf dieses ein read request schickt, dann mault das System weil halt on/off zum TUL geschickt werden und nicht DPT1 0/1.
PERL WARNING: Argument "off" isn't numeric in numeric ne (!=) at ./FHEM/10_EIB.pm line 269.
Vielen Dank für die Implementierung, das hilft sehr meine Solltemperaturen einzustellen.

vG
Wolfgang


Andi291

Hallo Wolfgang,

sehr gerne.

Das on/off Konstrukt hab ich bewusst drin gelassen. Sonst wären wir nicht mehr rückwärtskompatibel. An zentraler Stelle kann ich on/off also nicht rausnehmen. Aber ich schau mal, ob ich die (hoffentlich letzte :-)) Warnung noch raus kriege...

Grüße, Andi

ZeitlerW

Hallo Andi,

das hat keine Prio, man kann ja das Modell angeben.

vG
Wolfgang

Andi291

Jut...bei nicht definiertem model wird nun automatisch DPT1 angenommen und ein Verbose-3-Log rausgehauen. Bei einem falsch dfinieren Model ein Verbose-1-Log. Sollte so gehen.

Grüße, Andi

Andi291

...und DPT9 und DPT14 hab ich noch ein wenig getuned...

Alveole

hab beide Dateien eingebaut - läuft bisher ohne Probleme!

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

aliate

Zitat von: Andi291 am 28 September 2015, 18:16:57
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

Bei mir:

Tul.pm vom 18.09.2015 und EIB.pm vom 12.08.2015 (Grund: bei der aktuellen EIB.pm aus diesem Thread hab ich soviele Log-Einträge wg. den noch nicht definierten Geräten mit model dpt1; muss ich mal machen und dann nehme ich die aktuelle EIB.pm).
Mit diesem Setup (raspi2; dem Stick von busware und laufendem eibd) gibts bei mir keine Probleme.

Andi291


Alveole

Ich hab mal umgestellt auf 19200 Baud. bin gespant!

Eins kann ich schon mal noch sagen, mit 57600 trat der Absturz bei folgenden Dateikombinationen noch auf:
TULneu-EIBneu
TULalt-EIBneu

Andi291

Guten Abend zusammen,

die Änderungen sind eingecheckt und stehen bald per Update zur Verfügung.

Grüße, Andi