Jump to content

Betaversion der openHAB-Bindings


Recommended Posts

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

Link to post
Share on other sites
  • Replies 343
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Hallo Tamino, schön zu sehen dass hier weitere "Franken" im Forum aktiv sind 🙂 grĂŒsse aus Ansbach Stefan

Hallo riro ich habe das Outdoor Weather Bicklet gemeinsam mit dem TH-6148 Sensor von Tinkerforge im Einsatz. Der Sensor liefert Temperatur & relative Luftfeuchte und einen String wann de

Moin, Das klingt seltsam, ich sehe mir das am Montag mal beides an. (Dann aber gleich mit der fertigen 2.5-Version, die soll angeblich am Sonntag erscheinen). Vor Weihnachten gibt es dann auch no

Posted Images

@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.

Link to post
Share on other sites

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.

Edited by StefanOHAN
Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

 

Link to post
Share on other sites
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.

Link to post
Share on other sites

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

 

 

Edited by StefanOHAN
Link to post
Share on other sites
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!

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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 ?

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

 

 

 

 

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites
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 ;)

Link to post
Share on other sites

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

Link to post
Share on other sites

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

  • Like 1
Link to post
Share on other sites

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

Link to post
Share on other sites
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

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...