rtrbt

Moin,

wenn der Brick Viewer auf dem Raspberry Pi läuft, kannst du dich damit nach localhost verbinden. Das HAT sollte dann aufgeführt werden.

Moin,

Frage: Sollte das Number-Item sich nicht um 1 erhöhen wenn ich den als Input konfigurierten Pin betätige ? Bei mit behält das Number-Item den Wert „0“

Das funktioniert leider noch nicht automatisch, da der Edge Count kein Callback hat, ich also den Getter benutzen muss. Der wird aber nur ausgeführt, wenn du dem Item ein Refresh-Command schickst. Solche Werte automatisch zu aktualisieren steht noch auf der TODO-Liste.

Meine Rule (sind für die IO16-V1 / V2 und das IO4-V2 immer gleich aufgebaut)

rule "mono-flop"

    when

        Item Pin0IO4V2 changed to OFF

    then

    Pin2IO4V2mf.sendCommad ("TRIGGER")

  end

 

rule "mono-flop2"

    when

        Item Pin0IO4V2 changed to ON

    then

    Pin2IO4V2mf.sendCommad ("ON")

end

 

Nur das I0-4 V2 erzeugt eine Fehlermeldung (die IO-16 V1 / V2 nicht)

 

2019-10-27 19:21:40.363 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'mono-flop': 'sendCommad' is not a member of 'org.eclipse.smarthome.core.library.items.StringItem'; line 355, column 6, length 34

 

Was mache ich falsch ?

Das sollte sendCommand sein, beim Rotary Encoder 2.0 auch.

Mir ist heute mit dem neue Binding aufgefallen, dass im Log sich sehr oft diese Meldung für die verschiedenen Bricklets wiederholt.

2019-10-27 20:04:29.669 [iNFO ] [forge.internal.handler.DeviceHandler] - Checking reachability of H44

2019-10-27 20:04:29.676 [iNFO ] [forge.internal.handler.DeviceHandler] - Done checking reachability of H44

 

Ist dies Absicht ?

Technisch gesehen ja. Das ist der Mechanismus, der prüft ob die Verbindung noch besteht. Die Meldungen hatte ich aber nur testweise auf INFO gesetzt, das sollte eigentlich DEBUG sein, damit es beim normalen Log-Level nicht die Ausgabe überflutet. Repariere ich für die nächste Beta.

Moin,

Beta 12 ist jetzt im Post oben.

@Wannes: The 12th beta version should fix your wifi problems. The bindings now check periodically if a network connection was lost and then try to reconnect.

@StefanOHAN: In der neuen Version ist der Fix für dein IO16-Problem enthalten. Piezo Speaker kommt mit der nächsten Beta, das sollte aber schneller gehen als die letzte Den Speaker als Systemlautsprecher zu benutzen wird nicht gehen, da bräuchte man einen eigenen Treiber oder müsste eine openHAB-AudioSink schreiben.

Moin,

Es gibt diverse Drucksensoren, die ein Einheitssignal ausgeben. Z.B. dieser hier, oder dieser.

Auslesen kannst du ein Einheitssignal, wenn es ein Spannungssignal ist, mit dem Analog In Bricklet 3.0 oder für genauere Messungen mit dem Industrial Dual Analog In Bricklet 2.0, für Stromsignale mit dem Industrial Dual 0-20mA Bricklet 2.0.

Moin,

Die Ethernet-Extension ist ein Brick Daemon, d.h. den musst du nicht auf der cRIO installieren, sondern kannst dich mit LabVIEW auf die IP-Adresse der Ethernet-Extension verbinden.

@Wannes:

The problem with the WiFi Extension seems to be, that openHAB does not notice the lost connection caused by the restart of the stack. openHAB then still assumes, that the connection is established, but the Wifi Extension has no open connection because of the restart. Currently the Tinkerforge Protocol has no heartbeat mechanism, so to fix this, I have to query the device state periodically in the openHAB bindings (this will fail if the connection was lost) and then try to restablish lost connections. I think this fix will be in the next beta version.

@StefanOHAN

Das IO-16-Problem lag an einer fehlerhaften Konfiguration, die Getter, die openHAB für REFRESH-Commands verwenden sollte, hatte ich als Callback eingetragen, was dann später von den richtigen Callbacks überschrieben wurde. Deshalb funktionierte nur das initiale Abfragen des Zustands nicht, die Aktualisierungen aber schon. Brauchst du den Fix dringend oder reicht es, wenn ich den in die nächste Version packe?

Bezüglich dem Piezo Speaker: Support dafür kommt auf jeden Fall noch, ich bin mir nur noch unschlüssig, wie ich den modelliere. Was wäre dein Anwendungsfall dafür/Welche Features hättest du gerne?

Zum Thema HAT : Ja es ist die aktuelle FW installiert, es hat auch immer funktioniert. Nachdem es nur eine Warnmeldung war, war ich mir nicht sicher ob es was zu bedeuten hat.

Nur, dass die Initialisierung mehr als 5 Sekunden gedauert hat. Ansich sollte das deutlich schneller gehen, was openHAB auch erwartet, deshalb die Warnung. Kannst du also ignorieren.

FRAGE: Kann es sein dass die Kombination "Verbindung über RS485 Masterextention und alte V1 IO-16 diese Eigenart verursachen ?" Evtl kann ja im Binding nochmal auf den Teil für das alte IO-16 schauen.

Möglich. Das sehe ich mir nochmal an.

im Konfigurations Punkt der verschiedenen Bricklets findet man immer den Menu-Punkt

Bridge Selection

CREATE BRIDGE

 

Was ist die Funktion zur erstellen einer "Bridge" ?

Das kannst du ignorieren, die Bridge der Things ist der Brick Daemon. Aus irgendeinem Grund zeigt die PaperUI das dort aber nicht korrekt an, steht schon auf meiner TODO-Liste rauszufinden, was da kaputt ist.

Nochmal einen Frage zur Sample Rate des Humidity V2 Bricklet

Du schreibst

Du kannst ja beim Humidity Bricklet die Sample-Rate konfigurieren, wenn die wie bei dir auf 0.1 steht, dann misst das Bricklet alle 10 Sekunden. Damit weniger Rauschen auf den Daten ist, gibt das Bricklet aber nicht den Rohwert aus, sondern mittelt die letzten n Werte. Dieses n ist der Humidity Moving Average Length. Standardmäßig sind das 5, d.h. das Bricklet gibt den Durchschnitt über die letzten 5 Messwerte, also 50 Sekunden aus.

 

ich hatte meine Konfiguation wie unten eingestellt, bekam aber dennoch alle 10 sec einen Wert im Log

Averaging

Humidity Moving Average Length 20

Temperature Moving Average Length 20

Sample Rate 0.1 SPS

 

2019-10-15 06:57:43.298 [vent.ItemStateChangedEvent] - Hum1 changed from 48.36 to 48.37

 

2019-10-15 06:57:53.255 [vent.ItemStateChangedEvent] - Hum1 changed from 48.37 to 48.39

 

hätte da nicht alle 200 Sekunden nur werte erscheinen dürfen ?

Das ist etwas subtil, es gibt (ältere) Bricklets, bei denen wäre das so, da sie nicht einen gleitenden Mittelwert (= Moving Average) sondern einfach nur einen Mittelwert (= Average) ausgeben. Das Humidity berechnet aber einen gleitenden Mittelwert. Das heißt, dass das Bricklet die letzten "Moving Average Length" Werte speichert, bei dir also 20 pro Messwert und dann pro neuem Messwert, bei dir alle 10 Sekunden, den jeweils letzten Wert vergisst, den neuen dazu nimmt, den Durchschnitt berechnet und dann ausgibt. Dadurch hast du alle 10 Sekunden einen neuen Wert, der aber über die letzten 20 echten Messwerte geglättet wurde.

Bezüglich der ganzen Dinge, die so aufgelaufen sind: Ich muss mich in der Firma gerade noch um ein paar andere Dinge kümmern, d.h. die nächste Beta wird vermutlich noch ein paar Tage dauern.

Barometer 2.0

Der Druck von 1.0 bar kommt als ein Wert von 10.0 an, liegt das an mit oder stimmt da was nicht ?

Das sehe ich mir mal an, sollte so nicht sein.

UV 2.0

Bei dem Index steht jetzt bei mir in der Sitemap "one" wo die Einheiten stehen. Das Ding ist natürlich ohne Einheit, is klar, aber ist das ein OH Fehler oder kommt das vom Binding so mit ?

one ist eine der "Einheitenlos"-Einheiten, wie auch z.B. Prozent oder PPM, das ist so korrekt. Ich kann aber mal nachsehen, ob man das nicht sinnvollerweise ganz ohne Einheit rausgibt.

After power loss on my tinker stack and a power up again the commands from openhab don't seem to come true anymore.

Only after restart of the binding my relais and inputs work again in openhab.

The bricks seem to reconnect fine.

I added a debug log disconnecting and reconnecting again.

I was on vacation the last two weeks, but will take a look at this soon.

Hallo Erik,

 

ich hoffe Du hattest einen erholsamen Urlaub :-)

Hatte ich, danke

Es unterscheiden sich die Zeichen in der 3ten Gruppe (alt „f80007d9b“ neu „b0b51208“)

 

Warum ist dies so ? Kann dies verhindert werden ?

Was würde passieren wenn ich das System neu aufsetzte ? Müsste ich immer alle Channels neu verlinken ? (wäre es möglich einfach die Item - Datei mit dem verlinkten Channel in das neue System zu kopieren ohne diese ändern zu müssen ?)

Das ist der (automatisch generierte) Name des Brick Daemons. D.h. wenn du dem Daemon beim Anlegen einen festen Namen gibst, sollten den alle Items als dritte Gruppe haben.

Punkt 2)

Die als Input konfigurierten Ports am Stack2 bleiben nach dem Starten von Openhab in einem undefinierten Zustand (NULL) solange bis der Input Kontakt 1x betätigt wurde.

Es ist auch egal ob nun während des Starten von Openhab ein Input-Kontakt geschlossen ist oder nicht.

 

Dies ist etwas unschön, denn wenn man über den „remote“ Stack2, Fenster oder Türkontakte (IO-16) einbinden will, hat man nach dem Starten von OpenHab keine klare Aussage ob eine Rule nun starten soll oder nicht. Diese Problem könnte man umgehen wenn man den Status eines Channel abfragen könnte, geht dies mit Deinem Binding ? Wenn nein, was kann man da machen ?

Das sollte natürlich prinzipiell nicht notwendig sein, aber du kannst mit smarthome:send [itemname] REFRESH ein Refresh-Command schicken, dann sollte der Zustand aktualisiert werden.

Ein Punkt ist mir noch aufgefallen, einmal erschien im Log die Meldung dass das Hat länger zum Initialisieren benötigte. Ist dies ein Problem ?

 

2019-10-13 07:38:57.070 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'tinkerforge:hat:b0b51208:JYv' takes more than 5000ms.

Das ist etwas seltsam, weil der HAT-Handler eigentlich nicht viel tut, aber wenn das Initialisieren klappt, sollte das kein Problem sein. Hast du die aktuelle Firmware (2.0.1) auf dem HAT?

PS: Danke für die Urlaubsvertretung

Beta 11 ist jetzt im Post oben. Das LCD 128x64 hat jetzt einen Backlight-Channel. Außerdem können jetzt Decimal, Quantity oder PercentTypes in Channel gegeben werden, die Zahlen erwarten (wie z.b. den Backlight-Channel).

Ich bin erstmal zwei Wochen im Urlaub, werde aber immer mal in den Thread sehen, falls Fragen auftauchen.

Frage: Liefert der Sensor immer in gleichen Zeitintervallen Daten, oder nur wenn sich die Werte ändern ?

Der Sensor liefert alle 45 Sekunden Daten. Ich habe das mal an die Channel-Dokumentation angehangen. Da das Outdoor-Weather-Bricklet handgeschrieben ist, erscheint das aber noch nicht in meinem improvisierten Dokumentationsgenerator.

Mit etwas Testen habe ich dann erkannt, dass der gesamte Ausdruck in Hochkomma gesetzt werden muss.

Stimmt, der Channel will StringTypes, in Regeldateien brauchst du deshalb die Anführungszeichen.

Zum LCD 128x64: (hier habe ich noch nicht alles getestet)

Gibt es für das Backlight nur eine feste "Konfigurationsmöglichkeit, also nicht über Channel‘s. Ist das korrekt ?

Wenn ja, könnte Du bitte für das Backlight einen Channel einbauen (ähnlich wie beim LCD20x4).

Hm, das sehe ich mir mal an, eigentlich sollte das ein Channel sein.

Frage: Sieht Du die Möglichkeit eines Channel (online/offline) für den MasterBrick die per Trigger in einer Rule verarbeitet werden kann ?

Das könnte eventuell gehen. Rausfinden, ob ein Master Brick offline ist, ist nicht ganz trivial, aber da kann ich eventuell was bauen.

Beta 10 ist jetzt im Post oben.

Leider funktioniert jetzt der Motion-Dedector nicht mehr.

Da ich habe beim Umbauen der Channelrekonfiguration eine Feinheit für Trigger-Channel übersehen, das wird mit Beta 10 (heute Nachmittag) wieder funktionieren.

Frage zum Outdoor Weather Temperature/Humidity Sensor TH-6148 :

Erik, ist es möglich auch noch einen „Batterie“ Status anzeigen zu lassen ?

Nein, da das der Sensor selbst nicht meldet.

Erik noch eine Frage zum NFC-Bricklet, was planst Du alles für diese Bricklet ?

- Ich würde es gerne für Security Themen verwenden, wenn ich das richtig verstanden habe muss dazu aber auf einen gesicherten Bereich zugegriffen werden.

Geplant ist, für das NFC-Bricklet die API für einfache Anwendungsfälle zu erweitern und dann mit openHAB diese API zu verwenden, da die aktuelle API zu komplex ist um sie abbilden zu können. Das wird aber noch eine Weile dauern.

Beta 9 mit Support für das Outdoor Weather Bricklet ist jetzt im Post oben.

Tinkerforge Humidity Bricklet 2.0

Frage: Mit „Humidity Moving Average Length“ habe ich doch Einfluss auf das Messverhalten bei Schwankungen, wie muss ich diese Werte interpretieren ? z.B. „10“ bedeutet nur Schwankungen > 0.1    ? (in der Werte Auflösung sehe ich 2 Nachkommastellen, daher meine Vermutung)

Ah die Frage hatte ich übersehen. Du kannst ja beim Humidity Bricklet die Sample-Rate konfigurieren, wenn die wie bei dir auf 0.1 steht, dann misst das Bricklet alle 10 Sekunden. Damit weniger Rauschen auf den Daten ist, gibt das Bricklet aber nicht den Rohwert aus, sondern mittelt die letzten n Werte. Dieses n ist der Humidity Moving Average Length. Standardmäßig sind das 5, d.h. das Bricklet gibt den Durchschnitt über die letzten 5 Messwerte, also 50 Sekunden aus. Wenn du das Bricklet auf eine so niedrige Sample-Rate stellst, ist es vermutlich sinnvoll, die Durchschnittsberechnung abzuschalten (also den Moving Average auf 1 zu setzen), damit der Wert nicht ganz so träge ist.

Moin,

Freut mich, dass so viel schon funktioniert. Danke nochmal für die rigorosen Tests

[quote name="maxico

2019-09-23 21:49:42.792 [nt.ItemStatePredictedEvent] - RD9_MonoflopPin3 predicted to become TRIGGER

"PredictedEvents" habe ich sonst keine. Ist das normal?

Das ist ein "fancy new feature" wie es die openHAB-Entwickler hier nennen. Der Hintergrund ist wohl, dass openHAB vorhersagt, das Zustandsänderungen funktionieren werden, falls das entsprechende Thing nicht offline ist. Das wird hier genauer erklärt. Das muss ich mir nochmal genauer ansehen, ob das für alle Geräte eine gute Idee ist, oder ich es eventuell im Generator wegkonfiguriere.

Frage: „Ist es egal welchem Wert man dem String zuweist ?“

Ja, das ist egal. Hintergrund ist, dass ich ein StringItem mit CommandOptions benutze, da damit in der PaperUI Buttons erzeugt werden. Für Channel, bei denen es nur eine mögliche Aktion gibt ist mir dann aber egal, was der genaue Text ist, sobald ein Item reinkommt, löst die Aktion aus.

Beta 8 ist im Post oben. Diesmal ohne neue Bricklets, das Outdoor Weather Bricklet braucht noch etwas Überzeugungsarbeit. Der Channelrekonfigurationsbug sollte aber behoben sein.

Moin,

@Jerome: Das LED Strip Bricklet hat einen LED Values-Channel, in den du Text geben kannst (also StringCommands). Der Text muss eine Komma-separierte Liste von Zahlen sein, dabei ist die erste Zahl die erste LED die du steuern möchtest, danach folgen die Farben für die LEDs als RGB oder RGBW (also drei oder vier Zahlen jeweils von 0 bis 255), je nachdem ob du RGB oder RGBW-LEDs hast. Zum Beispiel kannst du mit 2,255,0,0,0,255,0,0,0,255 die zweite angeschlossene LED auf rot, die dritte auf grün und die vierte auf blau setzen. Wenn du das mit einem ColorPicker steuern willst, musst du dir eine Regel schreiben, die vom HSBCommand, dass der ColorPicker ausgibt, auf so einen String übersetzt.

@Stefan, Ulf: Die Fehler beim Umkonfigurieren der IO-16-Pins treten, zumindest bei mir, nur auf, wenn zwischen dem Hinzufügen des Bricklets zu openHAB und der Konfiguration ein openHAB-Neustart liegt. Was da passiert ist, dass die Bindings vergessen, welche Channel unterstützt werden und dann beim umkonfigurieren nicht die "neuen" Channel findet. Ich habe die ganze Channelrekonfiguration mal umgebaut, das kommt nachher in Beta 8 und fixt hoffentlich alle Pinkonfigurationsprobleme die aufgelaufen sind.

1) für was nutze ich den „Edge Count Pin 1/A1“ nachdem er Item-Typ Number hat, kann er doch nur zum Zählen genutzt werden, oder ?

Genau, damit kannst du Flanken zählen, z.B. wie oft eine 10ml-Schaufel an einem selbstgebauten Regenzähler auslöst, damit du dann ausrechnen kannst, wie viel Regen gefallen ist oder sowas.

Gruß,

Erik

Moin,

Beta 7 ist jetzt im Post oben. Das Readme listet jetzt die noch nicht unterstützten Geräte auf, die Liste ist kürzer.

Wegen dem openHAB v1-Binding musst du Theo fragen, da bin ich nicht im Thema.

Die v2-Bindings brauchen openHAB 2.5. Es hat sich zuviel in den Schnittstellen getan (u.A. ist ja das Eclipse Smarthome-Projekt gestorben), als dass es sich lohnen würde, die Bindings rückzuportieren.

Hm, ja das ist verwirrend. Ich habe das mal für die nächste Brick Viewer Version repariert.

Das IO16 kann nur auf den ersten beiden Pins Flanken zählen, deshalb siehst du nur die beiden Channel. Das ist hier (etwas notdürftig) dokumentiert.

Das Analog In hat nur den Voltage-Channel. Die Sache mit dem Create Bridge-Button ist kaputt, aber darüber sollten keine Channels angelegt werden, den kannst du also ignorieren. (Den gibt es bei jedem Gerät und er tut nichts)

Du kannst dich mit dem Brick Viewer zu deinem Raspberry Pi verbinden, dann findest du das HAT(-Zero) unter dem Bricklets-Tab des Updates/Flashing-Fensters mit Parent None.

Du kannst das einfach dranstecken, der Brick Daemon auf dem Raspberry Pi findet sowohl HAT und daran angeschlossene Bricklets, als auch Bricks, die per USB angeschlossen sind. Du kannst dann mit einer IP-Connection beides steuern, so als ob alles am HAT oder per USB angeschlossen wäre.

Beta 6 ist jetzt im Post oben.

@maxico:

Das mit dem Averaging war ein Copy-Paste-Fehler, das Analog In 2 hat einen Moving Average, Version 1 einen "normalen" Durchschnitt. Das hatte ich irgendwie übersehen.

Du kannst die Channel selbst in der PaperUI auch konfigurieren, die meisten (wie auch das Analog In) haben ein Update Interval. Mit dem Bugfix gestern habe ich das Speichern der Channelkonfiguration aber zerlegt, heute Nachmittag kommt dann Beta 6, die das wieder repariert, sorry dafür.

@StefanOHAN:

Actions kann der Generator noch nicht, d.h. die GUI kannst du mit den Bindings noch nicht benutzen. Das steht noch auf meiner TODO-Liste.

Die Fragen nerven nicht, im Gegenteil, das Feedback ist immer hilfreich. Ich teste immer mit der PaperUI, das geht schneller. Du kannst aber auch Rule-Dateien verwenden, die Items würde ich aber über die UI anlegen, das spart Tipp-Arbeit.