NEWS
KNX Adapter überholt
-
Hallo Goldblaster,
Kann es sein das deine SD Karte beschädigt ist? Mach mal bitte einen filesystem Check.
VG
chefkoch009
-
Kurze Rückmeldung von mir.
Nach einigen Stunden des Testens habe ich folgende Konfiguration wieder lauffähig bekommen.
Ich kann wieder schalten. Jeder Versuch gelingt.
KNX IP Interface von MDT (vom Nachbarn geliehen)
ioBroker KNX-Adapter in Version 0.8.6
Aktuell versuche ich nun den knxd in Version 0.12 neu zu kompilieren und zu installieren.
Danach teste ich wieder mit meinem IBBCape KNX-Interface und 012er knxd.
Edit:
Update 1
Keine Chance. Ich bin kurz vorm Aufgeben nach all den Tagen. KNXD v0.12 ist einwandfrei gestartet, keine Fehler mit folgendem Aufruf
KNXD_OPTS="-e 1.1.248 -E 1.1.249:5 -D -T -R -S –GroupCache --tpuarts-ack-all-group --tpuarts-ack-all-individual --layer2=tpuarts:/dev/ttyS2"
gemeldet.
knxtool groupwrite ip:localhost 2/0/0 1 schaltet.
Update 2:
Hab die MDT SCN-IP000.02 Schnittstelle jetzt in meiner Verteilung drin, alles läuft in Bezug aufs Schalten einwandfrei, quer durchs Haus. Bis auf den nicht sauberen Import bei der 0.8.6 (falsch/doppelt zugewiesene GA´s), werde ich nach meinem Urlaub nochmal die 1.0.9 wagen.
Bis dahin, Grüße
Vince
-
Zuerst muss ich sagen dass der KNX Adapter wirklich ein tolles Projekt ist. Das Konzept mit dem Import hat mir viel Tipparbeit erspart (gegenüber anderen Plattformen).
Leider schaltet bei meinem derzeitigen Setup der Adapter nicht zuverlässig und teils verzögert. Ich hab das auch mit manuellem Setzen von ein-aus Status von verschiedenen Objekten probiert. Manchmal funktioniert es, manchmal nicht. Ich habe auch lokal einen KNXD laufen, der auch mit demselben GW verbunden ist. wenn ich hier über das knxtool schalte funktioniert das Schalten zu immer :
knxtool groupswrite ip:localhost 0/0/1 1
knxtool groupswrite ip:localhost 0/0/1 0
Kann man den iobroker KNX-Adapter so konfigurieren, dass er den lokal laufenden KNXD verwendet?
Ich verwendet folgendes Setup
- Raspberry Pi 3 Modell B+
- ioBoker Adapter 1.0.9
- OS: Raspbian strech
- GW: Gira KNX IP-Router
- ETS: Version 5
Lg Shannon
-
Hallo Shannon,
Natürlich kannst du dies tun. Als IP gibst du die 127.0.0.1 bzw die IP deines KNXD Hosts ein. Der KNXD muss dann mit -T gestartet sein.
VG
chefkoch009
-
Hallo Shannon,
bei mir ist es annähernd die gleiche Situation.
Ich habe eine GIRA X1, nutze für gewöhnlich aber den KNXD inV 0.14 mit einem Busware TUL als Schnittstelle.
Probleme gibt es nur mit binären Schaltern.
Lampen mit Dimmer funktionieren einwandfrei.
Und auch nur mit dem KNX Tool kann ich stets die normalen Binären Schalter schalten.
Es scheint noch irgendwo beim/zwischen KNX Adapter und dann zur Schnittstelle zu Haken.
Vielleicht kommt es zu Problemen bei der Erstellung der Adressen und Vorgaben für den Adapter?
Grüße
Michael
-
verstehe ich das richtig, dass damit das Fehlerbild bei beiden Interface Setups auftritt und herstellerunabhängig ist?
Gibt es etwas wie ich vielleicht unterstützen kann? (z.B. etwaige Monitor/Debuglogs,..)
Lg Shannon
-
In meinen Testszenarien konnte ich es nicht nachstellen. Gleichwohl konnte ich es bei einigen Benutzern live beobachten.
Ich bin jedoch aktiv auf der Suche nach dem Fehler.
@all: kann jemand eine Aussage darüber treffen, ob der Adapter sich Babtec und GIRA verbindet? Ich habe meine Testgeräte leider nicht mehr.
VG
chefkoch009
-
Hi,
Alsooo, hatte den seit langem perfekt laufenden Adapter von 0.8.6 auch mal auf 1.0.9 aktualisiert.
Seit dem gleiches Verhalten wie bei allen anderen. Teilweise geht schalten und teilweise nicht.
Verzögert auch möglich.
IpGateway ist das von MDT.
Wie downgrade ich den wieder zufrieden stellend?
Gesendet von iPhone mit Tapatalk
![](</s><URL url=)<link_text text="https://uploads.tapatalk-cdn.com/201805 ... f6d2db.jpg">https://uploads.tapatalk-cdn.com/20180513/27895162e2b9336ca4de667e26f6d2db.jpg</link_text>" /> -
Nach dem umtüteln wieder auf 0.8.6 bekomme ich nun solche Fehler…
~~![](</s><URL url=)<link_text text="https://uploads.tapatalk-cdn.com/201805 ... 64e9a5.jpg">https://uploads.tapatalk-cdn.com/20180513/5df4dda6c539ca0181fba871ef64e9a5.jpg</link_text>" />
Gesendet von iPhone mit Tapatalk~~
-
Nach dem umtüteln wieder auf 0.8.6 bekomme ich nun solche Fehler… `
Der Adapter läuft anscheinend doppelt,
mach mal ein ioBroker restart, sollte dann weg sein.
Gruß Christian
-
Nach nem iobroker restart ging es nicht.
Aber nach nem reboot vom pi….
Lässt sich aus den Objekten auch wieder was steuern.
Gesendet von iPhone mit Tapatalk
-
Hallo Zusammen,
ich musste am Wochenende leider wegen einem dummen Fehler mein System komplett neu aufsetzen.
Dies habe ich dann als Chance gesehen es nochmal mit der 1.0.9 Version zu versuchen. Also frisches System installiert und das IoBroker backup eingespielt. KNX Adapter war dann der Aktuelle. Anfangs war ich auch total begeistert weil es funktionierte.
Nach einer Weile dann aber das gleiche Verhalten wie bei Allen hier. Rollo A fährt runter, Rollo B nicht. Rollo B manuell gefahren, geht. Rollo B wieder hochgefahren, geht nicht. Ähnliches mit Flurleuchten die Bewegungsmelder gesteuert sind, mal gehen die an, mal nicht.
Ein Blick in IoBroker zeigt das die States absolut korrekt verändert werden und auch korrekt (Bei manuellem Tasterdruck) gelesen werden. Es scheint, dass das Schreiben nur sporadisch funktioniert oder manchmal sogar zeitversetzt passiert. Ein kurzer klick und Wechsel auf die 0.8.6 und alles funktioniert perfekt! Es kann meiner Meinung nach nicht an einer fehlerhaften Vernbindung, Datenpunkten oder Protokollen liegen.
Ich habe das Gira IP Gateway.
Zwei Gedanken zu dem möglichen Fehler:
-
entweder der State wird nicht an das IP-Gateway übertragen und kommt am BUS nicht an (Müsste ich mit dem Busmonitor mal gegenchecken)
-
oder die Übertragung ist gesperrt, ähnliches Verhalten habe ich wenn ich mit der ETS das IP Gateway quasi blockiere, dann schreibt IOB fleissig states und auf dem BUS passiert nichts.
Grundsätzlich stellt sich die Frage, was hat sich in der Kommunikation ab Version 0.8.6 so gravierend verändert?
Ich werde in den nächsten Tagen mal eine zusätzliche Testumgebung aufbauen und kann gerne bei Bedarf Projekte, Protokolle etc. zur Verfügung stellen.
Gruß
Daniel
-
-
Hallo dangar,
Ich arbeite mit Hochdruck an diesem Problem. Grundsätzlich habe ich den hinter dem Adapter liegenden Protokollstack komplett neu geschrieben. Leider gehen dabei Theorie und Praxis auseinander. Diese muss ich nun in Einklang bringen und das ist sehr mühsam.
VG
chefkoch009
-
Hi chefkoch009,
Danke für die Info und ich hoffe, Du findest die Ursache bald.
Sag Bescheid wenn wir was testen sollen.
Gruß
Daniel
-
Hallo @all,
heut ist es wieder einmal soweit: Ich habe die neue Version 1.0.10 fertig.
Vielen Dank für Euer fleissiges reporten. Ich konnte so einige Bugs beheben. Des weiteren habe ich im Adapter Dialog eine Funktion hinzugefügt, welche erweitertes Logging/Debugging ermöglicht. Das die Funktion sichtbar wird müsst ihr u.U. ein "iobroker u knx" ausführen, oder in der Adminoberfläche unter Adapter den Expertenmodus auswählen und dann rechts in der knx-adapter Zeile auf das Symbol "upload" klicken.
Viel Spass beim Testen, ich freue mich auf reges Feedback.
VG
chefkoch009
-
Hallo zusammen,
nach update auf 1.0.10:
Ich habe den Eindruck, dass es etwas häufiger klappt. Aber nicht stabil.
Bei meiner Testumgebung konnte ich recht zügig auf die 1.0.10 updaten.
Bei meiner Produktivumgebung hat der Admin Adapter komischerweise keine aktuellere Version als die 1.0.8 gefunden.
Es ging dann nur über die Konsole.
Aber auch dort läuft es über die Visualisierung immer noch nicht stabil.
Ich habe allerdings den Eindruck, dass es im Iobroker Admin über die Objekte häufiger funktioniert.
Trotzdem macht es den Eindruck, dass die Trefferwahrscheinlichkeit angestiegen ist.
Das gilt anbei für beide meiner Schnittstellen.
Viele Grüße
Michael
-
Hallo,
Vielen Dank für die Rückmeldung. Die Sache mit dem Schalten ist ein Problem, dessen bin ich mir bewusst und arbeite daran.
Beim Schalten ist es so, das es unter gewissen Umständen (bin noch auf der Suche welche das sind) nicht funktioniert.
Für die Profis: das Schalttelegram endet IMMER mit 0x80 für das Ausschalten und mit der 0x81 für das Einschalten. Dabei ist das letzte Halbbyte also die 0 bzw 1 interessant. Es hat sich gezeigt, das für den Fall, das das letzte Halbbyte gerade ist (0,2,4,….)das Ausschalten passiert, andernfalls das Einschalten.
Mit der V1.0.10 gibt es den Punkt Debug-Level im Adapter Konfigurationsdialog. Wenn der Adapter mit dem höchsten Debug-Level betrieben wird, erhält man die Paketinformationen im Reiter Log der Admin Oberfläche. Dazu kann man sich die Pakete ebenfalls in der ETS anschauen.
Für mich wäre ein Auszug aus beiden +- 3Pakete interessant.
Vielen Dank für Eure Mithilfe.
VG
chefkoch009
-
Hallo @all,
ich habe soeben die V1.0.11 veröffentlicht.
Ein großes Dankeschön bei der Fehlersuche dabei an Micheagle.
VG
chefkoch009
-
Hi,
das klingt super. Hatte auch erst mit 1.0.10 rumprobiert und bin auf die selben Probleme gestoßen, mit 0.8.6 lief es jedoch problemfrei. Ich teste später mal 1.0.11.
Oh und bin auch gleich neu hier, nachdem die faxen voll hatte mich weiter mit FHEM rumzuärgern. ioBroker macht einen hingegen einen super Eindruck soweit.
Danke fürs entwickeln!
-
Kurzes mini Feedback:
Hab heute morgen schnell mal 1.0.11 installiert und zwei Minuten getestet. Jeder (!!!) Ein- oder Ausschalt-Befehl wurde korrekt ausgeführt. Wie gesagt, es waren zwar nur zwei Minuten, aber die waren sehr positiv
Ich glaube das Problem ist gelöst.
Vielen Dank @chefkoch009!