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
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
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
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...
Also korrekt set mein-text string hallo hugo
Ich schau nochmal nach g :-)
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ß
Hallo Jens,
Dein Problem mit dem "g" kann ich nachstellen...
Bin auf der SUche...
Grüße, Andi
...und repariert...
Hallo Andi,
habe es getestet. DPT16 senden funktioniert jetzt auch mit "g". :)
Danke!
Gruß Jens
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
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
Hallo Andi,
das hat keine Prio, man kann ja das Modell angeben.
vG
Wolfgang
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
...und DPT9 und DPT14 hab ich noch ein wenig getuned...
hab beide Dateien eingebaut - läuft bisher ohne Probleme!
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!
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.
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
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
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!
Morgen! Du hast noch die alte tul. Siehe threadanfang. Was passiert mit dem letzten modul, wenn du kein model setzt? Hoffentlich datensalat ohne absturz...
Und noch ein Fix für date / time...
Hallo Andi,
Habs bei mir eingebaut. Antwortet ganz brav auf einen Read request. Danke!
Ekkehard
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!
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?
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 (http://busware.de/tiki-index.php?page=TUL)
in der fhem.cfg eingebunden per:
define EIB TUL tul:/dev/ttyACM0@57600 0.0.100
Morgen! Die variante kannte ich bis jetzt noch nicht. Kannst du bitte mal einen knx/eib zwischenschalten?
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?
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.
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
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.
Leidensgenossen:
http://forum.fhem.de/index.php?topic=12337.0 (http://forum.fhem.de/index.php?topic=12337.0)
@Alveole: versuchs mal mit 19200Baud statt 57600...
Grüße, Andi
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
Guten Abend zusammen,
die Änderungen sind eingecheckt und stehen bald per Update zur Verfügung.
Grüße, Andi