-
Gesamte Inhalte
1.548 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
150
Alle erstellten Inhalte von rtrbt
-
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. 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. 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.
-
gleichzeitig HAT und BRICKs?
Thema antwortete auf rtrbts reinweb in: Software, Programmierung und externe Tools
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.
-
Ja. Beta fünf ist im Post oben.
-
gleichzeitig HAT und BRICKs?
Thema antwortete auf rtrbts reinweb in: Software, Programmierung und externe Tools
Ja, das ist kein Problem. -
@Jerome: Wenn du ein Motion Detector 1.0 hast, gibt es zwei Trigger-Channel: Motion Detected löst aus, wenn eine Bewegung bemerkt wurde, Detection Cycle Ended, wenn ein Bewegungserkennungszyklus beendet ist. Der Motion Detector 2.0 hat zusätzlich noch Channel für die LEDs, da kannst du jeweils Zahlen von 0 (aus) bis 255 (volle Helligkeit) reingeben und die Empfindlichkeit ist konfigurierbar. @StefanOHAN: Hm die Firmwareversion scheint man (laut diesem Thread) nicht in einer Rule auslesen zu können. Aber wie du schon sagst, ist das eher was für die Nice-to-have-Liste. Doku findest du in der Zip im Ordner Docs. Das sind die Beschreibungen usw. für Channel und Parameter, die zeigt die PaperUI selsamerweise nicht an, deshalb erstmal so. Measured Level und Edge Counter sind die Channel, die die IO-16 dir gibt, wenn ein Pin auf Input konfiguriert ist. Measured Level ist einfach der aktuelle Wert (0 oder 1), Edge Counter kannst du als Flankenzähler benutzen. Wenn du einen Pin als Output konfigurierst (lies diesbezüglich auch den @maxico-Teil), bekommst du stattdessen Set Level- (das ist der Wert (0 oder 1) den du ausgeben möchtest) und Monoflop-Channel. @maxico: Bei der Discovery (genau genommen erst wenn du in der Inbox den Haken anklickst um das Thing hinzuzufügen) setzen die Bindings das jeweilige Gerät auf einen Standardzustand. Bei der IO-16 ist das alle Pins auf Input zu setzen. Unabhängig davon war aber ein Bug in der Pinkonfiguration, der dazu geführt hat, dass man die Pins nicht auf Output konfigurieren kann. Es gibt dann heute noch Beta 5, bei der das funktioniert.
-
Moin, Ich habe mal wieder den Post editiert, Beta 4 mit vielen neuen unterstützten Bricklets ist veröffentlicht. @andreasOH: Node-RED ist derzeit nicht geplant, aber du kannst die MQTT-Bindings benutzen und dann von Node-RED aus MQTT sprechen. @StefanOHAN: Ich habe mal eingebaut, dass die Geräte ihre installierte Firmware bei der Discovery melden. openHAB zeigt das dann in den Thing-Eigenschaften an.
-
Hi, I've spent the last months extending our binding generator to be able to generate openHAB bindings. The 23rd beta version can be found here. Installation: The bindings require an openHAB 2.5.0 Milestone/Snapshot installation. To install the bindings, just copy the two JARs into the addons directory of your installation. openHAB will then load the bindings. Afterwards you can add a Brick Daemon over the inbox. Configuration: Attached devices are automagically put into the inbox after adding the Brick Daemon instance. Devices and channels can be configured: Channels typically allow changing the update rate. Some Bricklet's configuration can show/hide channels, for example the IO-4/16's pin configuration will dynamically create input or output channels. Sometimes the PaperUI needs to be refreshed by pressing F5 to show new channels. Only configuration that is stored in a Bricklet's RAM is supported. Persistant configuration has to be set externally (e.g. by using Brick Viewer), because openHAB will often reconfigure devices, for example on startup or when reconnected to a Brick Daemon. Writing persistant configuration would then take too many write-cycles. Further documentation: Can be found here: https://www.tinkerforge.com/en/doc/Software/API_Bindings_openHAB.html#api-bindings-openhab Actions in rules: There are actions to be used in rules available for all devices. To use actions of a device in a rule, first the actions have to be loaded with: var devActions = getActions("tinkerforge", "tinkerforge:[devicetype]:[Device UID]") Then they can be used with devActions.[actionname]([parameters]). The following example shows how to show a GUI on an LCD 128x64 Bricklet with the UID "HQ6": rule "startrule" when System started then var lcdActions = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQ6") lcdActions.brickletLCD128x64ClearDisplay() lcdActions.brickletLCD128x64RemoveAllGUI(); lcdActions.brickletLCD128x64SetGUIButton(0, 0, 0, 60, 20, "button"); lcdActions.brickletLCD128x64SetGUISlider(0, 0, 30, 60, 0, 50); lcdActions.brickletLCD128x64SetGUIGraphConfiguration(0, 1, 62, 0, 60, 52, "X", "Y"); lcdActions.brickletLCD128x64SetGUIGraphData(0, newArrayList(0, 10, 20, 40, 20, 15)); lcdActions.brickletLCD128x64SetGUITabConfiguration(3, false); lcdActions.brickletLCD128x64SetGUITabText(0, "Tab A"); lcdActions.brickletLCD128x64SetGUITabText(1, "Tab B"); end Functions that expect arrays as parameters can also be called with lists, as shown in the call of setGUIGraphData in the example. Results are returned as a Map<String, Object>, that can be used as follows: rule "otherrule" when Item Enx_Button changed to OFF then val lcdActions = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQ6") pixels = lcdActions.brickletLCD128x64ReadPixels(0, 0, 127, 63).get("pixels") val inverted = pixels.map[p | !p] lcdActions.brickletLCD128x64WritePixels(0, 0, 127, 63, inverted) end This rule is triggered if the Item Enx_Button changes to OFF (i.e. if the corresponding RGB LED Button is released). It will then read the pixels currently shown on the LCD Bricklet, invert them and draw the inverted pixels back on the LCD. Nearly the complete API of devices can be used as actions. Operations that invalidate the state of channels will refresh them automatically. Not supported are operations, that would write EEPROM or Flash Storage, to avoid unneccesary write-cycles. Display Bricklets: Text can be set as follows: [line],[position],[text]. Further ',' after the first two are handled as part of the text. In the text you can use the display's character set directly with \x[two hex digits]. Unicode characters are furthermore mapped to the display character set, as is done in the code examples, see f.e. here: https://www.tinkerforge.com/en/doc/Software/Bricklets/LCD20x4_Bricklet_Java.html#unicode As an example 1,2,Hello, opεnH\xE0B! will print Hallo, opεnHαB! stating at line 1, column 2 on an LCD 20x4. The small epsilon was mapped from Unicode into the LCD character set, 0xE0 (224) is the small alpha. PaperUI truncates whitespace at the start and end of commands. So to clear (parts of) a line, you can not use f.e. 1,2,[spaces]. Instead you can use the empty character like this 1,2,\xFE\xFE\xFE to delete three characters at Line 1, Column 2. Missing features: Channels accept one CommandType only. For example the LED of a RGB LED Button Bricklet can only be set using an HSBType, not the others that openHAB expects support for (e.g. if only the brightness is changed, an PercentType is sent). Known Bugs: Display Bricklets show '-' as text (NULL if clicked), if no text was already set using the UI. PaperUI does not show descriptions of channel(types) and configuration parameter groups. These are listed in the doc subfolder per device. Unknown Bugs: If you find another bug, please attach the openHAB Log. This can be found in the userdata/logs folder of your openHAB installataion. If the bug is reproducable, you can try to increase the log level with log:set TRACE org.openhab.binding.tinkerforge in the karaf console. Maybe this will show more useful information. log:exception-display can help too. If there are errors shown in the PaperUI, they can be investigated using the web developer tools of your browser. Run the network monitor, reload the page and take a look at the responses of requests with status code 500. log:exception-display (in the karaf console) could be useful here too.
-
Moin, Hier ist Beta 3 mit Support für die LED Strip und GPS Bricklet. @StefanOHAN: Was hast du mit dem Master Brick und openHAB vor? Bin mir da noch unschlüssig was sinnvoll abzubilden ist. Outdoor Weather und NFC stehen noch aus, da sie aber schwieriger umzusetzen sind, wird das noch etwas dauern. Das Outdoor Weather Bricklet werde ich voraussichtlich als eine Bridge abbilden, die gefundenen Sensoren und Stationen als Einzeldevices. Beim NFC muss ich die State-Machine implementieren. HAT Brick nehme ich mir mal für Beta 4 vor. Zu deinen weiteren Fragen: Geplant ist, dass die openHAB-Bindings bezüglich Wartung und Weiterentwicklung genauso behandelt werden wie die für alle unterstützten Programmiersprachen. Ich weiß nicht, ob Theo vor hat, seine Variante der Bindings weiterzuentwickeln. Vorteil der generierten Bindings ist, dass sie offiziell von uns unterstützt werden, also kannst du bei Feature-Wünschen und Bugreports immer ins Forum posten. @xsherlock: I've translated the readme, everything else is english anyway. I will post a thread in the General Discussion in a moment. Edit: done.
-
Ich meinte die OH2 Bindings. Ich editiere gleich den Post oben auf einen Link zur Beta 2. Die unterstützt die vier Bricklets auf deiner Liste und das Joystick V2. Vom Analog In (1) und Industrial Digital In 4 habe ich hier keins mehr gefunden, die kannst du ja mal testen
-
Moin, Geplant ist möglichst alle Bricks und Bricklets generieren zu lassen. Ich habe für die Beta nur erstmal die, die Theos Bindings unterstützen genommen, da das ja scheinbar die sind, an denen openHAB-User am wahrscheinlichsten interessiert sind. Die vier auf deiner Liste habe ich beim spontanen Codedurchsuchen in Theos aktuellen Bindings nicht gefunden, ich setze sie mir aber trotzdem mal auf der TODO-Liste nach oben.
-
Zeit für Eigenwerbung: bei den generierten Bindings hier kannst du diese Dinge kontrollieren. Der Heater vom Humidity 2.0 wird allerdings aktuell als Konfiguration, nicht als Switch-Channel abgebildet, das ist nicht all zu clever, werde ich für die nächste Beta-Version mal ändern.
-
It seems like the MQTT out node sends either to the wrong topic or to the wrong broker. Can you try again, but with mosquitto_sub -v -t '#' instead of mosquitto_sub -v -t 'tinkerforge/#' This will print everything published to the broker.
-
Can you post the output of mosquitto_sub -t tinkerforge/# and the debug output from the bindings for both cases? (Changing the color via the terminal and with a MQTT out node) Also, the debug node outputs differ: If you use the terminal, the payload is a string, with the node, it is an object. Maybe you have to convert the JSON object to a string before publishing it?
-
You have to subscribe to the [...]/response/[...] topic, instead of the [...]/request/[...] topic. So in your case mosquitto_sub -t tinkerforge/response/rgb_led_v2_bricklet/Jng/get_rgb_value If you then run mosquitto_pub -t tinkerforge/request/rgb_led_v2_bricklet/Jng/get_rgb_value -m '' in another shell, you will see the color. For debugging purposes, you can start the bindings with tinkerforge_mqtt --debug The response paths are then printed to standard out. Also you can subscribe to tinkerforge/# to see all traffic.
-
Moin, Der Generator ist dieser hier. Er erzeugt die API-Bindings für alle unterstützten Programmiersprachen und jetzt auch für openHAB. Den kannst du theoretisch bei dir ausführen, aber zur Zeit ist es noch etwas Handarbeit, die openHAB-Bindings zu kompilieren. Erik