StefanOHAN
-
Gesamte Inhalte
189 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
7
Posts erstellt von StefanOHAN
-
-
Hallo Alex (Tamino)
stimmt jetzt wo ich Deine Frage nochmal genau gelesen habe, sehe ich dass du auf den Punkt mit der Whitelist schon hingewiesen hast.
Einen Vorschlag hätte ich noch, und zwar mit executeCommandLine(String commandLine)
Kannst du Du Deinen Skript auf eine Befehl reduzieren ? Eventuell kann man mit exceuteCommandLine auch ein Shell Skript aufrufen.
Die Syntax in Openhab2 scheint ähnlich zu sein wie in Openhab 1.9. Ich bin leider mit meiner Migration von Openhab1.9 auf Openhab2 noch nicht beim exexuteCommandLine angekommen und habe daher noch keine Erfahrung damit in Openhab2.
In meiner alten Openhab 1.9 Konfiguration führe ich damit einen Reboot/Shutdown aus.
So sieht mein Shutdown aus
ZitatexecuteCommandLine("sudo@@/sbin/init@@0")
Die @ Zeichen anstelle der Leerzeichen waren bei mir notwendig, da ansonsten der Befehl nicht sauber ausgeführt wurde. Hierzu gibt es auch Hinweise in der Dokumentation.
Dein User hat ja schon sudo Rechte, also sollte es funktionieren.
Ich hatte damals Probleme zu erkennen dass die Berechtigungen / Zugriffsrechte für den User nicht korrekt waren, da die Zugriffsberechtigung's Fehler nicht im Openhab-Log erschienen und mein Prod-OpenHab-Service einen anderen User verwendete als der User den ich nutzte wenn ich das "Test"-System über die Kommandozeile startete (also nicht als Service).
Viele Grüße
Stefan
-
Hallo Tamino,
Ich hatte kürzlich versucht mit dem Exec-Binding "/bin/date" aufzurufen und es funktionierte nicht (in meiner Openhab 1.9 Konfiguration funktioniert das ohne Probleme) . Ich fand dann in der Doku des EXEC-Binding den Hinweis, dass seit Openhab2 alle Befehle die über das Exec-Binding ausgeführt werden sollen, in die Datei "exec.whitelist" eintragen werden müssen.
ZitatFor security reasons all commands need to be whitelisted. Allowed commands need to be added to the
misc/exec.whitelistfile in the configuration directory. Every command needs to be on a separate line.Nachdem ich die Datei "/bin/date" eingetragen hatte und einen neustart ausführte, klappte der Aufruf wieder.
Eventuell gilt dies auch für Shell-Skripte die Du über das Exec-Binding aufrufen willst.
Die Datei findest Du unter "openhab2-conf/misc/exec.whitelist"
viele Grüsse
Stefan
-
Hallo Erik
ich habe heute das neu Bindings (23) installiert. Leider kam es wieder zur gleichen Fehlermeldung für das Bricklet das ich beim HW-Umbau von WIFI-Dämon auf Dämon-USB/HAT umgestellt hatte.
Nach erneutem leeren des openhab-cache sowie 2 x System Neustart (per Init-6), war der Fehler weg.
Jetzt scheint wieder alles zu funktionieren.
Viele Grüsse
Stefan
-
Hallo Tamino,
schön zu sehen dass hier weitere "Franken" im Forum aktiv sind 🙂
grüsse aus Ansbach
Stefan
-
2
-
-
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
-
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
-
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.
Zitat2020-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).
Zitatval 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 ?
-
Hallo Erik,
das ist ein guter Vorschlag.
Bis jetzt (also seit Freitag Abend) läuft alles NTP & ASTRO & Tinkerforge Binding
Grüsse
Stefan
-
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
-
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
-
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
-
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
-
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.
Zitat2020-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:
-
beide jar-File für das Beta21-Binding über die Console entfernt,
-
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)
Zitat2020-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
-
-
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 weiterviele 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)
Zitat2020-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.
-
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
-
Hallo Erik,
ich habe das neue Beta-21 Binding eingespielt, nach einem System (OS/Openhab) update funktioniert „fast“ alles wieder.
Folgende Punkte sind mir aufgefallen
>> LCD 128x64
Wenn ich einen einzelnen Tab mit der action „lcdActions128x64.brickletLCD128x64RemoveGUITab(3)“ löschen will (es ist egal ob Tab 0 / 1 / 2 oder 3)
erhalte ich folgende Fehlermeldung (mit der alten Beta-20 gab es da keine Probleme)
Zitat„[ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Display Menue-Aufbau': Expected response of 8 byte for function ID 39, got 9 byte instead“
Wenn ich hingegen alle Tabs mit „lcdActions128x64.brickletLCD128x64RemoveGUITab(255)“ lösche, gibt es keine Fehlermeldung und alle Tabs werden gelöscht.
Remove „GUIbutton“ und Remove „GUISlider“ funktionieren ohne Probleme.
>> brickletIO16GetEdgeCount (nur für das alte IO-16 hw-Version 1.1.0)
das auslesen des EdgeCount funktioniert, jedoch bekomme ich den alten Fehler wenn ich den EdgeCount zurücksetzen will.
Für das IO-16 Bricklet 2.0 / Industrial Digital In 4 Bricklet 2.0 / IO-4 Bricklet 2.0 funktioniert es ohne Probleme.
Wo liegt mein Fehler ? (ich habe nach der neuen Doku erst einen short dann auf verdacht mit einen int gearbeitet)
>> Aufruf in der Rule Version A mit short
Zitatval ioActions16v1 = getActions("tinkerforge" , "tinkerforge:brickletio16:wip")
val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(1, true).get("count") as short
>> Aufruf in der Rule Version B mit int
Zitatval ioActions16v1 = getActions("tinkerforge" , "tinkerforge:brickletio16:wip")
val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(1, true).get("count") as int
>>Fehlermeldung
Zitat2020-04-13 15:33:38.137 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'teste edgecount': An error occurred during the script execution: Cannot convert number literal to typejava.lang.Short
für mich sieht das nach so einen Type-Casting Problem von JAVA aus. Aber wie müsse ich es richtig eintragen ?
Noch ein Hinweis zur Deiner neuen Dokumentation:
In Deiner neuen Doku für das NFC-Bricklet ist mir bei dem Beispiel ein kleiner Fehler aufgefallen.
Dort steht in Zeile 15
Zitat>>val stateVal = newState as Number
müsste es nicht lauten
Zitat>>val stateVal = newState.state as Number
Weiter schreibst du als Kommentar im Beispiel
Zitat„For this example create an item linked to the state channel of your NFC Bricklet“
könnte Du im Beispiel noch zusätzlich hinweisen, dass es sich bei „newState“ (in Zeile 15) um diese linked item handelt ?
Ansonsten funktioniert soweit alles wie gehabt.
Viele Grüße
Stefan
-
Hallo Erik,
ich gebe Dir recht man braucht nicht für jedes Bricklet ein Beispiel.
Das Remot Switch wäre eines, oder Hinweise wenn zum Ausführen ein Text-String an das Item übergeben werden muss.
Beim LCD 128x64 ClearDisplay schreibst Du in Deiner Doku dass ein beliebiger String übergeben werden kann, in dieser Art die Hinweise.
viele Grüsse
Stefan
-
Hallo Erik
ich habe mir für ein paar meiner Bricklest Deine neue Doku angeschaut, Sie gefällt mir gut.
Frage: Hast Du in der Doku auch Beispiele & Besonderheiten vorgesehen ? Ich habe keine gesehen.
Hintergrund der Frage anhand des Remote Switch Bricklet betrachtet
Du schreibst:
Zitat>>To switch a type A socket you have to give the house code, receiver code and the state (on or off) you want to switch to
Wenn ich jetzt nicht über das Forum Deine Beiträge gelesen hätte, wäre mir nicht klar gewesen dass ich bei dem Channel-verlinktem String-Item (für Socket-A), dem String-Item „on“ oder „off“ übergeben muss. (also als String)
Beispiel einer hilfreichen Zusatzinformation in der Dokumentation :
ZitatItem >> String remoteSteckdose1 "gesendeter Befehl an [%s]" (TestFf) {channel="tinkerforge:remotesockettypea:21ec0b7d:RemoteSocketTypeACommand"}
Rule >> remoteSteckdose1.sendCommand(„on“)
Auch Hinweise dass man z.B. einem Channel-verlinktem ITEM eines EdgeCount (der verschiedenen Bricklet) ein „REFRESH“ übergeben kann um einen Update der Werte zu erzwingen wäre nicht schlecht.
Generell bin ich für jeden Hinweis dankbar um Fehler zu finden oder zu vermeiden.
Ich könnte mir vorstellen, dass diese zusätzlichen Informationen / Beispiele Anfängern oder "Teilzeit" Openhab-Anwendern helfen würden (zumindest geht es mir so).
An dieser Stelle nochmal Danke an Deine tolle Arbeit
Viele Grüße
Stefan
-
Hallo Erik,
kurzer Update
ich habe diese Woche meinen zusätzlichen Komponenten bekommen
1 x Air Quality Bricklet
1 x PTC V2 mit Sensor
durch den zusätzlichen Masterbrick war ich auch in der Lage ein altes Temperatur Bricklet (HW Version 1.1.0) in die Konfiguration auf zu nehmen.
Alle Bricklets funktionieren mit dem Binding und liefern Werte, allerdings habe ich bis jetzt noch keine Action mit diesen Bricklets getestet.
Ich vergleich gerade mal wie die verschieden Temperatur-Sensoren Daten liefern. Bist jetzt habe ich den Eindruck dass die Werte des PTC 2 die des Humidty V2 (Temperatur) und die des Air Quallity (Temperatur) sehr nahe zusammen liegen. Die TH-Sensoren liegen näher an den Werten des alten Temperatur Bricklets.
Was mir auch gut gefällt ist, dass am PTC V2 ein Offset eingestellt werden kann. Vermutlich werde ich einen Kombination aus Air Quallity Bricklet für innen, PTC & Humidity V2 Bricklet für Außen einsetzten.
viele Grüsse
Stefan
-
Hallo Tim,
klar macht mehr Sinn das Thema über Privat Nachrichten zu klären, hab Dir hier über die Forum-Funktion einen PV-Nachricht gesendet, ich hoffe Sie ist angekommen.
viele Grüsse
Stefan
-
Hallo Tim (Teddy)
danke für Dein Angebot bezüglich der „Taster-Abdeckungen“
In meiner aktuellen produktiven Openhab 1.9 Umgebung habe ich ein Bedienfeld mit einem LCD20x4 und einem Multitouch 3x4 Key-Pad. (siehe Bild unten, besteht aus Acryl 5mm, wurde mit einem Laser-Cutter bei einem Lokalen Acryl-Glas Handel hergestellt)
Diese Bedienfeld-V1 möchte ich mit der Umstellung meines Prod-System auf OpenHab2 komplett neu aufbauen und aktuelle Tinkerforge Komponenten integrieren.
Vom Aufbau würde ich wieder 5mm Acryl nutzen, die Bricklets würde auf einem Basis-UnterRahmen befestigt und mit einem „Abdeckrahmen“ mit entsprechenden Ausschnitt für die Bedienelemente geschützt.
Im groben würde folgenden Komponenten in diesem Bedienfeld verbaut sein
1x LCD 128x64
1x Multi-Touch mit 4x3 Key-Pad
1x NFC
1x Dual Button
1x Rotary Encoder
1x Rotary Poti
bis auf den Dual-Button sind es im Grunde nur entsprechende Ausschnitte / Bohrungen in der Bedienfeld-Abdeckung. Siehe die Grob-skizze unten.
Ich würde vermuten dass mir die reinen Abdeckungen ausreichen würden, hast Du auch ein Bild wie diese Abdeckungen ohne Gehäuse aussehen (evtl wenn sie auf dem Dual-Button liegen) ?
Selber steht mir kein 3D Drucker zur Verfügung.
Daher würde ich gerne auf Dein Angebot zurück kommen.
Jetzt und hier ein große Lob an das gesamte Tinkerforge TEAM 🙂
viele Grüße Stefan
-
1
-
-
Hallo Erik,
Thema on/offline Meldung „Thing“ Dämon.
Die Meldung „Bridge of [UID] went online “ sehe ich für alle Bricklets und den Masterbrick der über den Dämon verwaltet werden. Ich sehe aber keine Meldung dass der Dämon online geht.
Meine Rule nutze folgenden Trigger
Zitat„Thing "tinkerforge:brickd:wifi2test" changed“
und schaltet eine der beiden LED des Dual-Button ein / aus.
Gerade eben musste ich feststellen dass die doch Rule funktioniert, auch wenn ich keine „online-Meldung“ des Thing-Dämon im Log sehe. Dass ich fälschlicherweise dachte die Rule funktioniere nicht mehr, hatte einen anderen Grund.
Beim neu anlegen der Things, hatte ich für den Dual-Button in der Konfiguration vergessen die beiden LED auf „Channel default on“ zu konfigurieren. Nachdem die LED‘s nicht auf die Zustandsänderung des Dämon reagierten, dachte ich es lag an der fehlenden Meldung im Log. Mit anpassen der Dual-Button Konfiguration waren die LED‘s auch wieder vorhanden und bei der Zustandsänderung des Dämon wurden sie ein / ausgeschaltet.
Sorry mein Fehler, Asche auf mein Haupt.
Beta 20 habe ich eingespielt, jetzt funktioniert das IO-16 (alt) und auch die Darstellung der Port Konfiguration des IO-16 / IO-16 2.0 / IO4 2.0 zeigt jetzt den richtigen Text an 🙂
Danke für die schnelle Reaktion 🙂
viele Grüße Stefan
-
Hallo Erik,
wow ich war ganz erstaunt als ich sah, dass Du auch am Sonntag die Forum-Einträge liest. Alle Achtung
Beim Update auf Beta 19 hatte ich für ein Bricklet einen Fehler die ich nicht beheben konnte.
Alle Bricklets bis auf ein „altes“ IO-16 (HW Version 1.1.0 /FW Version 2.0.3 ) gingen wieder online. Um einen Fehler auszuschließen, habe ich anschließend alle Things inklusive der Tinkerforge Dämons deinstalliert und anschließend das System neu gestartet. Auch dann konnte ich das IO-16 nicht online nehmen. Es erschien im Log immer folgende Fehlermeldung
Zitat2020-02-29 15:33:36.077 [DEBUG] [forge.internal.handler.DeviceHandler] - Initializing wip
2020-02-29 15:33:36.078 [DEBUG] [forge.internal.handler.DeviceHandler] - Removing old manual update handler for wip
2020-02-29 15:33:36.357 [DEBUG] [forge.internal.handler.DeviceHandler] - Failed to initialize wip: Got invalid parameter for function ID 15
2020-02-29 15:33:36.359 [TRACE] [.internal.handler.BrickDaemonHandler] - Timeout for device tinkerforge:brickletio16:wip
2020-02-29 15:33:36.360 [DEBUG] [forge.internal.handler.DeviceHandler] - Checking reachability of wip
2020-02-29 15:33:36.368 [DEBUG] [forge.internal.handler.DeviceHandler] - wip is not in bootloader mode.
2020-02-29 15:33:36.369 [DEBUG] [forge.internal.handler.DeviceHandler] - Done checking reachability of wip
2020-02-29 15:33:36.370 [DEBUG] [forge.internal.handler.DeviceHandler] - wip was not already online. Reinitializing
Erst nach einem Restart von Openhab konnte ich das IO-16 aus der Konfiguration entfernen.
Das IO-16 2.0 und das IO-4 2.0 ließen sich ohne Probleme online nehmen.
Weiter ist mir aufgefallen, das sich bei der Port Konfiguration des IO-16 / IO-4 (HW 2.0) die Darstellung fehlerhaft ist.
Immer wenn ich auswähle „output (Initial low)“ und dies speichere, erscheint bei erneutem Aufruf der Port Konfiguration der Text „Add or search“. In der Übersicht des IO-16 Thing wird angezeigt dass der Port als Output Konfiguriert ist, aber mit Status Low / High
Es ist auch egal ob ich über Firefox oder Chrome das versuche. (siehe auch Bild im Anhang)
Weiter Frage: Hast Du die Online/Offline Meldungen der Things / Dämon usw verändert ?
Ich habe mir eine Rule gebaut, die das off und online gehen der beiden „Dämon‘s“ (WIFI & USB/HAT) überwacht.
Offline Meldungen kommt für Things & Dämon, jedoch sehe ich im Log nur noch die „changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE“ Meldung für die Things (Bricklets) aber nicht mehr für den Dämon. Somit funzt meinen Rule zur Überwachung der Dämons nicht mehr.
(Übrigens seit Deinem Beta18 Update hatte ich keine „Ungeplanten“ Dämon Aussetzer mehr)
Bis jetzt sind keine weiteren Fehler bei „alten“ Rule‘s / Things aufgefallen.
Weiter mit dem Test des Tinkerforge NFC Bricklet (HW Version 1.0.0 / Modell-ID 286 / FW Version 2.0.1)
Das Auslesen der TAG-ID hat beim zweiten Anlauf funktioniert.
Nachdem ich nicht so ein JAVA Fachman bin, verstehe ich nicht so ganz was die beiden Zeilen
Zitatval stateVal = newState as Number
val int state = stateVal.intValue
in Deinem Beispiel bedeuten.
Sie haben bei mir einen Fehler im Log verursacht.
Zitat2020-03-01 10:49:02.019 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'lese TAG': The name 'newState' cannot be resolved to an item or type; line 9, column 20, length 8
Nachdem ich für den NFC-Status aber ein „Number-Item“ mit dem entsprechenden Channel verlinkt habe, habe ich Deine Rule auf diese „Item-Status-Abfrage“ umgebaut und die Rule hat funktioniert.
Frage: Was ist die Aufgabe des „newState“ value ?
Ich sehe schon um das NFC optimal nutzen zu können, müsste ich tiefere JAVA Kenntnisse haben, denn Deine Zeilen aus der Beispiel Rule
Zitatval tagID = ret.get("tagID") as List<Integer>
val tag = String.join(" ", tagID.stream().map([i | String.format("0x%02X", i)]).collect(Collectors.toList()));
sind für mich schon fast „grosses JAVA Kino“ 😉
Bis auf ein paar ältere 10-polige V1 Bricklets (Humidity / Temperatur / Industrial Quad Relais / Dual-Relais /PTC ) die noch in meiner Produktiv Umgebung verbaut sind, habe ich alle mir zur Verfügung stehenden Brickles in meine Test eingebunden. Ich hoffe diese alten Bricklets auch mit dem neuen Binding funktionieren, dies sehe ich aber erst wenn ich die Prod Umgebung von Openhab 1.9 auf 2.x umstelle.
Ich würde noch zwei weiter Bricklets testen, aber beide sind leider nicht über Euren Shop verfügbar
a) das neue „Servo-Brick“ dass sich noch in Entwicklung befindet (wird es auch vom Binding unterstützt ?)
b) das PTC-Bricklet 2.0 (ist aktuell nicht verfügbar)
Was mir Echt gut gefällt ist, Euer Dual-Button-Bricklet 2.0
Frage: Gibt es eine passende „Taster-Abdeckung“?
Wenn man diese in ein Paneel einbaut, wäre es viel schöner wenn man eine Abdeckung dafür hätte.
Ich werde noch weiter an den Rule‘s Testen und berichten.
Viele Grüße
Stefan
P.S.
Ich weiß ich werde mir jetzt den Unmut vieler Openhab 2.x User zuziehen, aber bei großen Umgebung finde ich die alte, über einen Thing-Datei Konfiguration, übersichtlicher. Welche Negativen Auswirkungen hätte die Nutzung einer "Thing" Konfiguration's Datei anstelle der GUI ?
Wird es auch mal eine Anleitung geben, wie ich diese Tinkerforge Thing‘s Datei anlegen müsste ?
-
Hallo Max
jetzt mal unabhängig von Eriks Hinweis bezüglich des Restart.
Kann es sein, dass Du noch mit einem alten Binding arbeitest ?
Wenn ich das richtig sehe enthält Dein Channel noch die ID des TF-Dämons. Erik hat in den verschiedenen Bindings das System ein paar mal umgebaut, mal waren die „Dämon-ID‘s“ Bestandteil des Channel, mal nicht. In den letzten Bindings ist die Dämon-ID nicht mehr Bestandteil des Channel. Dieser Umbau hat zur Folge dass Du Deine Channel-Verlinkung der Item‘s und auch die Rule‘s mit Channel Trigger auf die neue Schreibweise anpassen musst.
Welche Binding Version hast Du ?
Dein Aufruf (siehe markiert, Deine Dämon-ID )
Zitatval lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:ac8b6ac8:KYL")
Mein Aufruf (gilt für Binding Beta18/19)
Zitatval lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQJ")
viele Grüße Stefan
Betaversion der openHAB-Bindings
in Allgemeine Diskussionen
Geschrieben
Hallo Alex,
Vorschläge für Rule's habe ich keine mehr. Vermutlich hast Du auch schon in den System-log's nachgeschaut.
Mein Erfahrung mit Zugriffs/Berechtigung Fehler im Zusammenhang mit executeCommandline und Exec war, dass diese selten in den Openhab Logs zu finden waren sondern meist nur in den verschiedenen System log's (/var/log/ ...). Dies mir nur durch Zufall aufgefallen, als der "Openhab playSound" nicht funktionierte. Erst als ich in den verschiedenen Linux System-logs suchte, fand ich eine Fehlermeldung die mir half das Problem beseitigen. Obwohl der Openhab-User sudo-Rechte hatte fehlten Zugriffsrechte auf die Sound-Datei.
Viele Grüsse
Stefan