Betaversion der openHAB-Bindings

[StefanOHAN]

Hallo Erik,

hallo Tinkerforge Team

 

wow das ging ja Fix mit dem "LCDx128x64" Firmaware-Bug-Fix 😉

Ich hab gleich gestern Abend den FW update für das LCD eingespielt, anschließende funktionierte auch der RemoveGuiTab für einzelne Tab's

 

Mit Deinem Vorschlag funktioniert auch das Rücksetzten des EdgeCount für die "alten" IO-16 (mit 10 pol Stecker) 

 

Super, danke für die schnelle Hilfe

 

viele Grüsse

 

Stefan

[rtrbt]

@matthiask

Der InvalidParameter-Fehler der von der Rule geworfen wird kommt direkt vom Bricklet. Das heißt in dem Fall, dass requestTagID aufgerufen wurde, obwohl das Bricklet nicht in einem der Idle-States war. Hast du eventuell noch etwas nebenbei laufen? (Andere Rules, die das Bricklet benutzen, andere Programme, den Brick Viewer?) Eventuell ist es sinnvoll, die Rule so umzuschreiben, dass periodisch requestTagID aufgerufen wird und eine zweite Rule das Ergebnis abfragt, dann ist das zumindest selbstreparierend.

Zu dem LED-Strip-Problem: Ich erinnere mich, dass es beim Testen ein Krampf war, mit den short-Arrays umzugehen, dazu kommt auf jeden Fall noch ein Beispiel. Dass das Bricklet short-Arrays erwartet, liegt an den Java-Bindings, deren Typmapping (von Java-Typen auf Device-Typen) ich unverändert übernehme: Das war in den ersten Versionen effizient im Sinne von short benutzen, wenn der Wertebereich klein genug ist. Da das in Java aber zu vielen nötigen Casts usw. führt, wurde das irgendwann umgestellt. Für die da schon veröffentlichten Devices kann das aber nicht geändert werden, ohne dass die Bindings nicht mehr rückwärtskompatibel zu alten Programmen sind.

[StefanOHAN]

Hallo Erik,

nachdem ich mein System auf das Beta 21 umstellt habe, kam es sporadisch zu verschiedenen Fehler.

Reboot und abschalten/Neustart haben nur temporär geholfen.

Daher entschloss ich mich die Konfiguration (Binding/Dämon ...) komplett neu zu erstellen. Jetzt funktioniert die Edit Funktion der Bicklets nicht mehr.

Zum  Fehlerbild:

→ verschiedene Bricklets gingen offline, aber nicht mehr online (laut Brickviewer waren diese funktionsfähig)

→ Bindings ungleich Tinkerforge funktionierten nicht mehr (z.B. Astro-Binding, kein Update des Sonnenwinkels)

Aus diesem Grund, habe ich alle Bricklets / Dämon‘s / Bindings aus der Konfiguration entfernt (beide TF-Bindings über die Console). Anschließend führt ich einen Update des kompletten System durch.

Nach dem Einbinden der Bindings, anlegen der Dämons und adden der Brickletes kann ich jetzt die Bricklets nicht mehr konfigurieren (Edit-Funktion).

Beispiel:

→ von den IO-4 Bricklet 2.0 / IO-16 Bricklet 2.0 / IO-16 Bricklet V1 können die verschiedenen Ports nicht von Input auf Output umgestellt werden. Das Fehlerbild ist eigenartig, da ich im Edit Menü zwar die Ports von Input auf Output umstellen kann, aber im „Thing-Menü“ wird aber für den Port weiterhin „Input“ angezeigt. Wenn ich wieder in das Edit Menü wechsle wird „output“ angezeigt.

→ für den Dual Button Bricklet 2.0 kann im Edit-Menu zwar der „left/right LED State Channel“ auf Off umgestellt werden, aber diese Änderung wird nicht im Thing-Menü des Bricklets angezeigt. Wenn ich wieder in den Edit Modus des Bricklets wechsle sehe ich die von mir vorgenommene Änderung.

Es handelt sich nicht nur um einen Darstellungsfehler.

Ich habe dies mit der letzten Release Version (openhab) also mit den Test / Snapshot Versionen versucht, hatte aber keine Auswirkung.

Was ich bis jetzt noch nicht versucht habe, das System komplett neu zu installieren.

Ich weiß momentan auch nicht weiter

viele Grüße Stefan

kurzer Update 1:

ich habe eben das ganze mit der Beta20 nochmal versucht, da konnte ich die  Port der IO-Bricklets und die LED-Channel des Dual-Button wieder konfigurieren.

kurzer Update 2:

jetzt wo nur wenige Komponenten in der Konfiguration eingebunden sind, sehe ich DEBUG-Meldungen im Log die mich verwirren (aktuell in der Beta20 da ich mit Beta21 die Bricklets Konfiguration nicht Editieren kann)

Zitat

2020-04-28 14:59:42.043 [DEBUG] [TinkerforgeConfigDescriptionProvider] - Could not find device info for configDescriptionURI thing-type:astro:config: null.

2020-04-28 14:59:42.096 [DEBUG] [TinkerforgeConfigDescriptionProvider] - Could not find device info for configDescriptionURI thing-type:ntp:ntp: null.

2020-04-28 14:59:42.312 [DEBUG] [TinkerforgeConfigDescriptionProvider] - Could not find device info for configDescriptionURI thing-type:logreader:reader: null.

Diese 3 Meldungen erscheinen sporadisch. Was ich verwirrt dass hier vom "TinkerforgeConfigDescriptionProvider" Meldungen für "Non-Tinkerforge-Bindings" kommen.

Ich setzte folgende weiter Bindings ein

-> Astro-Binding

-> LogReader Binding

-> NTP Binding

diese Bindings sind bereits in Openhab2 über  ... /paperui /Configuration / Bindings abrufbar.

ich werde das ganze System jetzt komplett neu installieren.

bearbeitet April 28, 2020 at 13:36 von StefanOHAN

[rtrbt]

Moin,

3 hours ago, StefanOHAN said:

von den IO-4 Bricklet 2.0 / IO-16 Bricklet 2.0 / IO-16 Bricklet V1 können die verschiedenen Ports nicht von Input auf Output umgestellt werden. Das Fehlerbild ist eigenartig, da ich im Edit Menü zwar die Ports von Input auf Output umstellen kann, aber im „Thing-Menü“ wird aber für den Port weiterhin „Input“ angezeigt. Wenn ich wieder in das Edit Menü wechsle wird „output“ angezeigt.

Den Fehler habe ich schon mal gesehen, bin mir aber gerade unsicher, ob das etwas war, was ich durch eine openHAB-Neuinstallation losgeworden bin, oder ob da im Code was kaputt war.

Da bei dir aber auch die anderen Bindings kaputt sind, vermute ich, dass du in das Problem gelaufen bist, dass ich beim Entwickeln manchmal treffe: Wenn man einzelne Bindings in openHAB zu oft oder mit ungünstigem Timing aktualisiert, scheint es manchmal zu passieren, dass irgendein interner Cache falsche Werte hat, dann kann man die Installation gefühlt wegwerfen. Ich habe da aber noch in keiner Weise eine Regelmäßigkeit ausmachen können, deshalb gibt es da keinen Bug-Report, den ich gefunden oder geschrieben hätte.

3 hours ago, StefanOHAN said:

ich habe eben das ganze mit der Beta20 nochmal versucht, da konnte ich die  Port der IO-Bricklets und die LED-Channel des Dual-Button wieder konfigurieren.

Haben da dann die anderen Bindings wieder mit dir geredet?

3 hours ago, StefanOHAN said:

jetzt wo nur wenige Komponenten in der Konfiguration eingebunden sind, sehe ich DEBUG-Meldungen im Log die mich verwirren (aktuell in der Beta20 da ich mit Beta21 die Bricklets Konfiguration nicht Editieren kann)

Das ist erwartet: openHAB fragt alle ThingType/ChannelType/ConfigDescriptionProvider nach, ob sie für IDs einen entsprechenden Typen oder eine Description liefern können, unabhängig davon ob die Provider zu einem spezifischen Binding gehören oder nicht. Deshalb ist die Meldung auch nur DEBUG, ich benutze die intern, um Konfigurationsfehler in der Generator-Config zu finden.

3 hours ago, StefanOHAN said:

ich werde das ganze System jetzt komplett neu installieren.

Das sollte auf jeden Fall helfen, ich hoffe das hat dir nicht dein Produktivsystem zerschossen.

Gruß,
Erik

[StefanOHAN]

Hallo Erik

 

nein keine Angst, es hat mein Entwicklungs -/Test System erwischt.

Ich hab heute Abend meinen Pi Komplett neu aufgesetzt Inklusive erzeugen einer SD-Card und update von Openhab2 auf das aktuelle Release.

Leider ist das Fehlerbild noch immer vorhanden.

Ich konnte nach der Neuinstallation die Ports der IO-16/4 nicht nach Output umstellen, im Edit-Menü wurde es zwar angezeigt, aber nicht im Thing Menü.

Hierzu habe ich eine schöne Fehlermeldung für das IO-16, diese hänge ich als Datei an.

Auch die LED-Channel des Dual-Button konnte ich nicht auf ON konfigurieren.

Anschließend wurde es aber echt wüst, auf einmal wurde der Masterbrick der über die WIFI-Extention angebunden war, laut Log aus der Konfiguration entfernt. Mir ist in der alten Konfiguration zwar aufgefallen dass dort die Anzahl der Elemente in der Inbox sich veränderten, aber auf die Schnelle konnte ich damals im Log nichts erkennen. Jetzt mit den wenigen Komponenten konnte ich diese Meldung im Log sehen.

 

Zitat

2020-04-28 21:02:44.961 [vent.ChannelTriggeredEvent] - logreader:reader:ce98bd6c:newWarningEvent triggered 2020-04-28 21:02:44.790 [WARN ] [org.eclipse.jetty.server.HttpChannel] - /rest/things/tinkerforge:brickletio16v2:H4b/config

2020-04-28 21:04:23.453 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6kMKrA' has been removed.

2020-04-28 21:04:23.460 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickletpiezospeakerv2:KGL' has been removed.

2020-04-28 21:04:23.467 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickletnfc:HoB' has been removed.

2020-04-28 21:04:23.475 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickletindustrialdigitalin4v2:HWi' has been removed.

2020-04-28 21:04:23.487 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickletepaper296x128:Jzc' has been removed

Nach einer gewissen Zeit erscheinen dann wieder alle Tinkerforge-Elemente in der Inbox.

Ich hatte bei der alten Installation den Eindruck, dass dies immer passierte wenn der „background-Discovery-Intervall“ aktiv war, dachte mir aber nichts dabei, da ich vermutete das System sei zerschossen.

 

Ich prüfte anschließend ob es mit der Beta20 wieder funktionierte:

1. beide jar-File für das Beta21-Binding über die Console entfernt,

2. das Beta20 Binding wieder ins addon Verzeichnis kopiert und openhab neu gestartet.

    

Ergebnis:

Mit der Beta20 konnte ich dann wieder die IO-Ports und die LED-Channel des Dualbutton konfigurieren.

Vorerst habe ich keine ITEM Channel Verlinkung ausgeführt. Ob es bei den anderen Brickelt auch im Edit-Menü Probleme gibt hab ich bis jetzt noch nicht getestet.

 

Die Nacht über waren keine „Bricklets“ als „Things“ Konfiguriert, sie waren nur über die Inbox zu sehen (nicht immer!)

Allerdings ist auch in der Beta20 der Effekt des Remove der Masterbriks vorhanden. Dies erfolgt alle 5 Minuten (siehe Meldung im Log)

 

Zitat

2020-04-29 06:50:02.416 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6dLEow' has been removed.

2020-04-29 06:50:02.646 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:5VHSip' has been removed.

2020-04-29 06:50:02.682 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6DzXrA' has been removed.

2020-04-29 06:55:47.342 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'tinkerforge:brickmaster:6DzXrA' to inbox.

2020-04-29 06:55:47.349 [home.event.InboxAddedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6DzXrA' has been added.

2020-04-29 06:55:47.535 [home.event.InboxAddedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:5VHSip' has been added.

2020-04-29 06:55:47.538 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'tinkerforge:brickmaster:5VHSip' to inbox. 2020-04-29 06:55:47.565 [home.event.InboxAddedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6dLEow' has been added.

2020-04-29 06:55:47.568 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'tinkerforge:brickmaster:6dLEow' to inbox.

2020-04-29 06:55:49.850 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6kMKrA' has been removed.

2020-04-29 06:59:59.245 [home.event.InboxAddedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6kMKrA' has been added.

2020-04-29 06:59:59.252 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'tinkerforge:brickmaster:6kMKrA' to inbox.

2020-04-29 07:00:01.753 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6dLEow' has been removed.

2020-04-29 07:00:01.872 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:5VHSip' has been removed.

2020-04-29 07:00:01.914 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6DzXrA' has been removed.

2020-04-29 07:05:47.359 [home.event.InboxAddedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6DzXrA' has been added.

2020-04-29 07:05:47.358 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'tinkerforge:brickmaster:6DzXrA' to inbox.

2020-04-29 07:05:47.434 [home.event.InboxAddedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:5VHSip' has been added.

2020-04-29 07:05:47.432 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'tinkerforge:brickmaster:5VHSip' to inbox.

2020-04-29 07:05:47.502 [home.event.InboxAddedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6dLEow' has been added.

2020-04-29 07:05:47.501 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'tinkerforge:brickmaster:6dLEow' to inbox.

2020-04-29 07:05:49.848 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6kMKrA' has been removed.

2020-04-29 07:09:59.240 [home.event.InboxAddedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6kMKrA' has been added.

2020-04-29 07:09:59.240 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'tinkerforge:brickmaster:6kMKrA' to inbox.

2020-04-29 07:10:02.350 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6dLEow' has been removed.

2020-04-29 07:10:02.433 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:5VHSip' has been removed.

2020-04-29 07:10:02.468 [me.event.InboxRemovedEvent] - Discovery Result with UID 'tinkerforge:brickmaster:6DzXrA' has been removed.

Entsprechend sieht es natürlich auch für die Bricklets aus. Eine „Richtige“ Fehlermeldung warum die Masterbrick‘s removed werden sehe ich allerdings nicht (hab aber das erweiterte Logging noch nicht aktiviert)

 

auszug-log-fehlermeldung-IO16.txt

Viele Grüße

 

Stefan

[rtrbt]

Ah, die Fehlermeldung war wirklich hilfreich, da habe ich das Problem direkt mit gefunden:

Ich habe ja vor einer Weile etwas Magie eingebaut, damit Channel dynamisch erzeugt und gelöscht werden können, z.B. für die IO-16-Pin-Konfiguration. Da gibt es das interessante Problem, dass ich, wenn ich alle Channel neu erstelle (also jedes Mal, wenn die Konfiguration sich ändert), die Konfiguration von Channels, die bereits da waren, behalten will, bei neu erstellten Channeln lade ich die Standardkonfiguration. Das Nachschlagen der vorhandenen Konfiguration funktioniert so, dass ich das Thing nach dem Channel mit der UID des (eventuell vorhandenen) Channels frage, was wenn das Thing den Channel gerade nicht kennt null zurückgibt. Damit muss der Code umgehen können, also wenn null zurückkommt, einen neuen Channel mit der Default-Konfiguration erstellen.

Ich hatte im Zuge der letzten Beta einmal das null-Handling aufgehübscht, da verwendet openHAB Tools um den Code zu annotieren (z.B. "Diese Funktion gibt nie null zurück") und dazu ein Analysewerkzeug, das Warnungen erstellt, wenn man das falsch macht (also z.B. bei einer Funktion die null zurückgeben kann dann ohne Prüfung den Rückgabewert verwendet). Die Analyse ist nicht ganz perfekt, und ich habe an der Stelle nicht genug nachgedacht und den Hinweis, dass da ein Nullcheck unnötig ist einfach geglaubt, das stimmte aber offensichtlich nicht, deshalb fliegt dir das gerade um die Ohren.

Ich fixe das mal und baue eine neue Beta.

Das Discovery-Remove-Problem liegt daran, dass ich in Beta 20 die alten Discovery-Ergebnisse entfernt habe, bevor die neuen eingefügt werden. Das korrekte Vorgehen (was Beta 21 auch tut) ist, erst die neuen einzufügen und dann alle, die älter sind zu entfernen.

[StefanOHAN]

Hallo Erik,

Du schreibt's

vor 16 Minuten schrieb rtrbt:

Das Discovery-Remove-Problem liegt daran, dass ich in Beta 20 die alten Discovery-Ergebnisse entfernt habe, bevor die neuen eingefügt werden. Das korrekte Vorgehen (was Beta 21 auch tut) ist, erst die neuen einzufügen und dann alle, die älter sind zu entfernen.

Wie gesagt ich hatte aber auch mit dem Beta-21 die Situation dass Bricklets in der Konfiguration nach einer gewissen Zeit als offline angezeigt wurden obwohl sie über den Brickviewer erreichbar waren.

Es war aber nicht das Problem das durch das WLAN-Optimierungs-Verhalten der AVM entstanden ist, denn es waren auch Masterbricks /Bricklets betroffen die über USB angebunden sind.

Wie siehst Du den Effekt  den ich bei der alt-Installation mit der Beta-21 hatte, dass das Astro Binding (ist openhab 2 tauglich) einfach nicht mehr automatisch den Sonnenwinkel update ausführte (funktionierte bis Beta20 da ich bei negativen Sonnenwinkel = Nacht, eine LED einschaltetet ) ?

Kann es eine Folge davon  sein, dass ich das System seit ca 10-15 Beta-Bindings nicht mehr neu installierte sondern nur die neuen Beta-Bindings einspielte (maximal die Things entfernte und neu hinzufügte) ?

 

viele Grüsse 

Stefan

 

[rtrbt]

2 hours ago, StefanOHAN said:

Kann es eine Folge davon  sein, dass ich das System seit ca 10-15 Beta-Bindings nicht mehr neu installierte sondern nur die neuen Beta-Bindings einspielte (maximal die Things entfernte und neu hinzufügte) ?

Das wäre durchaus möglich. Beim Entwickeln ist mir das zumindest manchmal passiert. Da installiere ich das Binding natürlich ungleich öfter, aber wer weiß, was genau das Problem ist.

Ich habe gerade Beta 22 hochgeladen, du kannst damit nochmal testen, ich hoffe, dass die kombiniert mit deiner Neuinstallation die ganzen Probleme löst. Wenn sich Bricklets nochmal in einem offline-Zustand festhängen oder andere Bindings nicht mehr gehen, sag unbedingt nochmal bescheid, das ist ja doch eher kritisch.

@matthiask

Das LED-Strip-Index-Problem ist in Beta 22 gefixt, du kannst bei dir mal den String "2,255,0,0,255,255,255,0,255,0,0,0,0,0,0,255" testen, der sollte zwei LEDs auslassen, dann eine rot, eine weiß, eine grün, eine schwarz (aus) und eine blau setzen.

[StefanOHAN]

Hallo Erik,

habe schnell das Beta-20 deinstalliert und beide File für Beta-22 in das addon-Verzeichnis kopiert. 

Nach dem Restart konnte ich wieder für das IO16 V1  / IO-16 V2 / IO-4 V2 die Ports auf Output umstellen (ohne Fehlermeldung )

Auch für den Dualbutton konnte ich die LED-Channel auf on setzten und die LED einzeln schalten (ohne Fehlermeldung)

Über eine Verlinkung der Channel mit dem passenden Items konnte ich die output-Port  der IO's-Briklets und die LED des Dualbutton über paper-ui / Control bedienen (über Rule & Taster kann ich erst heute Abend testen)

Zwei Punkte sind mir aufgefallen, auf die ich in der Vergangenheit aber nicht geachtet habe.

 

1) für das IO-16 V2 und das IO-4 V2 kann ich über deren Thing-Menu Configure-Channel für die INPUT Ports den Update Intervall verändern (die Standard Werte von 1000ms sind etwas lang). Für das IO-16 V1 (also alte Bauart mit 10pol Anschluss) geht das nicht, genauer ich finde da pro Port das "Stift-Symbol" nicht. Frage ist das Absicht ? Hier müsste man auch den Update-Intervall anpassen können.

2) Wenn man über paperui / Control die als Input konfigurierten Ports des IO-16 V2 und IO-4 V2 "fälschlicher" weise betätigt, schaltet sich automatisch das "Switch"-Symbol wieder auf seine Ursprungs-Postionen zurück (Warn-Meldung im Log, korrekt  ), dies erwartet man ja. Wenn ich dies hingegen beim IO-16 V1 und dem Dualbutton im Controll-Menü ausführe bleibt das "Switch"-Symbol  in der Stellung auf die man es geschoben hat (hier erscheint auch die korrekte Warn-Meldung im Log), erwarten würde ich jedoch das gleiche Verhalten wie für das IO-16 V2.  Woran liegt dies ? Test mit Rule  und angeschlossenen Taster an einem Input-Port, kann ich erst heute Abend ausführen)

Beide Effekte sind auch nach einem Reboot noch vorhanden.

 

viele Grüsse

 

Stefan

 

 

bearbeitet April 29, 2020 at 12:27 von StefanOHAN

[rtrbt]

40 minutes ago, StefanOHAN said:

1) für das IO-16 V2 und das IO-4 V2 kann ich über deren Thing-Menu Configure-Channel für die INPUT Ports den Update Intervall verändern (die Standard Werte von 1000ms sind etwas lang). Für das IO-16 V1 (also alte Bauart mit 10pol Anschluss) geht das nicht, genauer ich finde da pro Port das "Stift-Symbol" nicht. Frage ist das Absicht ? Hier müsste man auch den Update-Intervall anpassen können.

Die 1000ms sind tatsächlich etwas lang, ich setze mir mal auf die Liste, mir die Default-Werte mal anzusehen für alles, was nur Callbacks schickt, wenn der Wert sich ändert. In dem Zuge kommt dann auch das Update-Interval für die IO-16 1.0, das gibt es aber ich habe die Funktion an die falsche Stelle konfiguriert.

43 minutes ago, StefanOHAN said:

2) Wenn man über paperui / Control die als Input konfigurierten Ports des IO-16 V2 und IO-4 V2 "fälschlicher" weise betätigt, schaltet sich automatisch das "Switch"-Symbol wieder auf seine Ursprungs-Postionen zurück (Warn-Meldung im Log, korrekt  ), dies erwartet man ja. Wenn ich dies hingegen beim IO-16 V1 und dem Dualbutton im Controll-Menü ausführe bleibt das "Switch"-Symbol  in der Stellung auf die man es geschoben hat (hier erscheint auch die korrekte Warn-Meldung im Log), erwarten würde ich jedoch das gleiche Verhalten wie für das IO-16 V2.  Woran liegt dies ? Test mit Rule  und angeschlossenen Taster an einem Input-Port, kann ich erst heute Abend ausführen)

Hm, beim alten IO-16 und dem Dual Button fehlt da das read-only-Flag, füge ich mal ein.

Wie immer Danke fürs Testen!

[StefanOHAN]

Hallo Erik

ich habe gestern Abend eine Mini-Rule erstellt, die nur auf Thing-Status Änderungen der MasterBricks des HatBrick und der beiden Brick-Dämons reagiert. In dieser Rule werden u.A. auch die LED-Channel des DualButten angesprochen, hat auch alles funktioniert. (4xMasterBrick , 1xHatBrick, 2xBrickDämon)

In der Konfiguration waren nur wenige Bricklets (IO-16 / IO-16 V2 / IO-4 V2 / Piezospeaker / e-Paper / Dualbutton) eingebunden (wollte den Log übersichtlich halten).

Die Nacht über konnte ich keine „unerklärlichen“ timeout von MasterBricks / Brickles im Log erkennen. Nur das bekannte Timeout wenn die Wifi-Verbindung vom Router optimiert wurde (es ging aber alles wieder online).

Um zu prüfen ob das Astro-Binding noch funktioniert, habe ich eine Rule aktiviert, die reagiert wenn sich der  Sonnenwinkel ändert und prüft ob er kleiner  4 oder größer 4 Grad ist. Das hat auch alles geklappt, die Rule arbeitet abhängig vom Sonnenwinkel korrekt. In dieser Rule wird auch ein als Output konfigurierter Port des IO-4 V2 und ein als Input konfigurierter Port des IO-16 V1 angesprochen. Beide Ports haben wie erwartet reagiert.

Es gibt einen Punkt der mir früher schon aufgefallen ist, hat aber vermutlich nichts mit Deinem Binding zu tun.

Die Offline-Meldung eines Thing (egal ob nun BrickDämon, MasterBrick, PiezoSpeaker …) wird immer in das „events.log“ geschrieben. Wenn ein MasterBrick(Thing) wieder online geht wird dies in das "openhab.log" geschrieben und wenn ein Bricklet (Thing) z.B PiezoSpeaker online geht in das „events.log“ geschrieben. Das ist nicht dramatisch, verwirrt etwas wenn man die Log‘s nach Ausfällen durchsucht.

Ich werde die nächsten Tag mit dieser Mini-Konfig das ganze weiter beobachten

Viele Grüße

 

Stefan

[StefanOHAN]

Guten Morgen Erik,

kurzer Update. Das Beta 22 Binding läuft bis soweit ohne Fehlermeldung im Log. 

Einmal gab es (1,5 Tage nach dem Restart von Openhab mit dem Beta 22, am Freitag 1.5 abends) ein Problem mit dem NTP und dem Astro Binding ( wie gesagt ich hatte bisher mit diesen nie Probleme). Das NTP-Binding und das Astro-Binding funktionierten einfach nicht mehr (kein Update), aber auch kein Fehler im Log. Nach einem Openhab-Restart funktionierte alles wieder.

Dein Tinkerforge-Binding reagierte aber noch (ich konnte über paper UI / Control die LED-Channel des Dualbutton ein und ausschalten).

Um mehr Informationen zu erhalten, habe ich  Openhab im Debugger-Modus gestartet, das Tinkerforge-Binding Logging (trace) wieder aktiviert, den NTP-Zeitserver auf den AVM-Router umgestellt sowie das Outdoor-Weather-Bricklet mit dem TH Sensor und den Piezo-Speaker wieder in die Mini-Konfiguration aufgenommen um im Log mehr Meldungen zu sehen (mit Zeitstempel ...).

Bis jetzt läuft alles ohne Störung, ich kann mir momentan das Aussteigen des NTP/Astro-Binding nicht erklären.

Grüsse

Stefan

[rtrbt]

Das klingt seltsam. Du kannst sicherheitshalber das Log-Level vom Astro- und NTP-Binding mal auch auf Trace stellen, das sollte eigentlich genauso funktionieren.

[StefanOHAN]

Hallo Erik, 

das ist ein guter Vorschlag. 

Bis jetzt (also seit Freitag Abend) läuft alles NTP & ASTRO & Tinkerforge Binding

 

Grüsse

Stefan

[StefanOHAN]

Hallo Erik,

ich habe jetzt mit dem Beta 22 die Mini-Konfiguration ca 1 Woche laufen lasse, der Fehler dass NTP & ASTRO Binding ausgestiegen, ist nicht mehr aufgetreten.

Allerdings hatte ich einen anderen Effekt. Nachdem ich jetzt für das neue Bedienfeld die Acryl-Zuschnitte (dank Tim) habe, habe ich das e-Paper Bricklet vom Dämon der über WIFI angebunden ist, auf den Dämon gewechselt der für das HAT-Brick zuständig ist.

Der Wechsel über paperUi/Things/view ging wie immer problemlos und das Brickelt wechselte wieder auf Online. Probleme gab es aber mit der Rule die für das Bricklet zuständig ist.

Zitat

2020-05-10 17:54:48.134 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'stelle-Time-Dar': 'brickletEPaper296x128FillDisplay' is not a member of 'org.eclipse.smarthome.core.thing.binding.ThingActions'; line 47, column 5, length 44

Um Fehler zu vermeiden, habe ich erst über die Konsole den cache geleert
>>openhab-cli stop
>>openhab-cli clean-cache
>>openhab-cli start
Dies behob den Fehler nicht.
Anschließend entfernte ich das E-Paper Bricklet aus der Konfiguration und deinstallierte über die Konsole beide Tinkerforge Bindings.

Nach dem Hochlaufen wurden nicht alle Bricklets automatisch erkannt (auch das e-Pater nicht). 
Nach dem ich über PaperUi / Inbox eine manuelle Suche startete, war das e-Paper wieder verfügbar. 
Nach hinzufügen zur Konfiguration funktionierte die Rule wieder ohne Fehlermeldung.

Um sicherzugehen, dass der Fehler behoben ist, habe ich das System mit Init 6 noch einmal komplett neu gestartet, und der Fehler war wieder da.
Nach dem Reboot habe ich überprüft ob sich die Zuordnung zum Dämon geändert hat, dies war nicht der Fall 
(das Bricklet war weiterhin dem Dämon des HAT-Brick zugeordnet und online).

Ich musste das E-Paper wieder aus der Konfiguration entfernen, 
eine manuelle Suche nach neuen Bricklet starten und anschließend das Bricklet wieder zur Konfiguration hinzufügen. 
Danach arbeitet die Rule wieder fehlerlos.

Folgende Befehle rufe ich in der Rule auf (an der Rule kann es nicht liegen).

Zitat

 

val ePaperV2 = getActions("tinkerforge", "tinkerforge:brickletepaper296x128:Jzc")

 ePaperV2.brickletEPaper296x128FillDisplay(1) 

 ePaperV2.brickletEPaper296x128DrawText(0,15,7,2,0,"" + NTP_S_time.state )

 ePaperV2.brickletEPaper296x128Draw()

 

 

Das ist ein etwas eigenartiger Fehler, oder ?

Ich hab so den Eindruck, dass in irgend einem cache noch Werte liegen. Hast Du eine IDEE was ich noch versuchen könnte ?

 

Ich hab anschließend wieder alle meine „anderen Test“ Rule‘s aktiviert, es scheint alles zu funktionieren.

Grüße Stefan

P.S. Konntest Du schon mal testen wie die Konfiguration der Things über eine „Textdatei“ aussehen müssten ?

[rtrbt]

Moin,

Ich habe das hier mal getestet, bei mir funktionierte alles nach dem Stapelwechsel, nur die PaperUI zeigt an, dass das Bricklet offline ist, das hat sich aber durch einen Neustart des Stacks behoben. (Das Bricklet einfach so umstecken während alles läuft ist ja technisch gesehen nicht unterstützt)

Das Bricklet wird bei dir in der PaperUI als online angezeigt? Dann leg dir mal ein Item für den Draw Status des Bricklets an. Das Item kannst du dann mit "smarthome:send Jzc_DrawStatus REFRESH" aktualisieren, eventuell siehst du dann im Debug-Log etwas interessantes.

Die Konfiguration über Text-Dateien habe ich vor einer Weile mal getestet, aus irgendeinem Grund hatte ich dann alle Items doppelt pro Thing, dem bin ich noch nicht nachgegangen.

[StefanOHAN]

Hallo Erik

nein, ich habe natürlich vor dem Umbau für das komplette System einen shutdown gefahren und Stromlos geschaltet (für beide Stapel, also den WIFI und Raspi mit HAT-Brick).

Ein Item für den Draw-Status hatte ich schon angelegt, war also vorhanden.

Nach dem physikalischen Umbau (im stromlosen Zustand) und dem Reboot, führte ich über PaperUi den ich Switch vom Stapel WIFI zum Stapel HAT-Brick aus. Nach dem "switch" wurde das Bricklet auch als online angezeigt. Nur die Rule funktionierte nicht.

Erst nach dem entfernen und wieder hinzufügen des Bricklet funktioniert die Rule wieder, daher auch meine Vermutung dass Openhab hier irgendwo noch etwas im cache hatte.

Ich werde heute Abend einfach mal 3-4 mal einen shutdown laufen lassen, und schaun was passiert.

Welche openhab Version nutzt Du ? ich die aktuell freigegebene.

Grüsse

 

Stefan

 

 

 

 

[rtrbt]

Ich habe das bei mir mit 2.5.3 getestet, ich würde aber nicht erwarten, dass sich 2.5.4 groß anders verhält. Das Changelog scheint nur Änderungen in den Addons zu haben.

[StefanOHAN]

Hallo Erik,

 

so habe jetzt noch 3 x das ganze System neu gestartet, einmal stoppen uns starten des Service, einmal  mit init 6 einmal mit init 0

Glaub es oder nicht, der Fehler ist weg (schon nach dem 2ten roboot).

Vermutlich doch ein cache-Problem von Openhab. Sorry wenn ich Dir da Stress bereitet habe.

viele Grüsse

 

Stefan

[rtrbt]

1 hour ago, StefanOHAN said:

Sorry wenn ich Dir da Stress bereitet habe.

Kein Problem, ich hatte schon mit sowas gerechnet. Caching ist ein schweres Problem und ich bin selbst oft genug über openHAB-Caching-Probleme gestolpert

[Tamino]

Hallo Erik,

will nicht nerven, aber wie weit bist du denn mit der Umsetzung für das LED-Strip Modul für den Colorpicker? 
Und hast du mittlerweile schon eine Beispiel Rule für den DC-Brick?

 

sonnige Grüße aus Rothenburg o.d.T.

 

Alex

[StefanOHAN]

Hallo Tamino,

schön zu sehen dass hier weitere "Franken" im Forum aktiv sind 🙂

grüsse aus Ansbach

Stefan

[rtrbt]

Moin,

Ich bin bisher noch nicht dazu gekommen, muss gerade ein anderes Projekt priorisieren. Ich werde aber diese Woche noch einen Tag für diversen Kleinkram Zeit haben, da sollte auf jeden Fall die DC-Brick-Rule rausfallen.

Erik

[rtrbt]

Moin

Kurzer Zwischenstand: Ich habe die DC-Brick-Modellierung nochmal umgebaut, die Target Velocity, Acceleration usw. sind jetzt Channel, das vereinfacht das schreiben von Rules (und macht sie in manchen Fällen sogar unnötig)

Bezüglich der LED-Strip-Color-Picker-Geschichte: Das habe ich mal angefangen zu implementieren, musste aber feststellen, dass hier gerade keine RGBW-LEDs auffindbar sind. Habe mal neue bestellt. Das dauert aber noch ein paar Tage, bis die ankommen und ich die HSB->RGBW-Farbkonvertierung getestet habe.

Ich will nichts versprechen, aber eventuell gibt es nächste Woche eine neue Beta, mit der kannst du dann beides testen.

Erik

[Tamino]

vor 32 Minuten schrieb rtrbt:

Moin

Kurzer Zwischenstand: Ich habe die DC-Brick-Modellierung nochmal umgebaut, die Target Velocity, Acceleration usw. sind jetzt Channel, das vereinfacht das schreiben von Rules (und macht sie in manchen Fällen sogar unnötig)

Bezüglich der LED-Strip-Color-Picker-Geschichte: Das habe ich mal angefangen zu implementieren, musste aber feststellen, dass hier gerade keine RGBW-LEDs auffindbar sind. Habe mal neue bestellt. Das dauert aber noch ein paar Tage, bis die ankommen und ich die HSB->RGBW-Farbkonvertierung getestet habe.

Ich will nichts versprechen, aber eventuell gibt es nächste Woche eine neue Beta, mit der kannst du dann beides testen.

Erik

Hi Erik,

 

hört sich sehr gut an, mit den Channels kann ich dann schon mal arbeiten.

Vielen Dank für die Arbeit.

Dann warte ich mal gespannt auf die neue Beta.

 

Schönes Wochenende und sonnige Grüße

 

Alex