Betaversion der openHAB-Bindings

[StefanOHAN]

Hallo Erik,

also 2 Punkte haben sich geklärt

1) die Action lcdActions.drawText(0,55,6,true,“Hallo“) hatte echt nur ein Problem mit den falschen Hochkommas. Nach der Korrektur klappt es perfekt. (Problem war das hin und her kopieren)

2) der verlinkte Channel des LCD128x64SelectedGUITab übermittelt den richtigen Wert des berührten Tab. Es war mein Fehler, denn ich hab nicht ins Log geschaut nur aufs Display und einen Denkfehler in der Rule. Nach Korrektur der Rule funktioniert auch der Output richtig.

Anders sieht es mit der lcdActions.clearDisplay() action aus, die macht noch immer Probleme

So sieht meine Rule aus (sobald ich .clearDisplay() entferne läuft alles ohne Probleme)

Zitat

 

rule "LCD128x64-action3-Tab"

when

        Channel "tinkerforge:lcd20x4:f80007d9:vyU:LCD20x4Button0" triggered

then

        val lcdActions = getActions("tinkerforge", "tinkerforge:lcd128x64:f80007d9:HQJ")

        logInfo("Action-test-LCD128x64", "Rule test actions" )

        if(null === lcdActions) {

                logInfo("Action-test-LCD128x64", "Rule test actions-LCD128x64 nicht vorhanden" )

       } else {

                logInfo("Action-test-LCD128x64", "vorhanden >>" + lcdActions )

                LCD128x64_BL.sendCommand(100) // Background LED

                lcdActions.removeAllGUI();

               // LCD128x64_Clear.sendCommand("Clear")

               lcdActions.clearDisplay()

               lcdActions.setGUIButton(0, 0, 0, 60, 20, "Tast1")

               lcdActions.setGUIButton(1, 68, 0, 60, 20, "CLEAR")

               lcdActions.setGUISlider(0, 0, 30, 60, 0, 50)

      }

end

 

In Deinem Beispiel setzt Du hinter den Kommandos ein Semikolon, das ist soweit mir bekannt in Openhab nur notwendig wenn man mehre Kommando pro Zeile hat um diese zu trennen. Ich schreibe aus Übersichtlichkeit nur ein Kommando pro Zeile. Hab das mal mit Semikolon wie in Deinem Beispiel probiert, ändert nichts.

Zitat

 

Es erscheint diese Fehlermeldung:

2019-11-18 21:03:32.615 [INFO ] [e.model.script.Action-test-LCD128x64] - Rule test actions start

2019-11-18 21:03:32.622 [INFO ] [e.model.script.Action-test-LCD128x64] - vorhanden >>com.tinkerforge.BrickletLCD128x64Actions@1bcb232

2019-11-18 21:03:32.628 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'LCD128x64-action3-Tab': Instance is not an BrickletLCD20x4Actions class.

 

Jetzt wo Du es schreibst ist mir erst aufgefallen, dass die Fehlermeldung auf das LCD20x4 verweist (eines ist angeschlossen siehe unten).

Um sicher zu gehen, dass ich nicht einen Fehler verursacht habe, habe ich nochmal

>>val lcdActions = getActions("tinkerforge", "tinkerforge:lcd128x64:f80007d9:HQJ")<<

überprüft und den Wert per copy und paste aus PaperUI/Configuration/Things neu eingetragen (war aber korrekt). (es ist auch die ID des LCD128x64 und nicht die des LCD20x4)

 

Die aktuelle Konfiguration ist

#OS = openHABian v1.5-533(c7ac00c) >> auf aktuellen Stand (Sonntag ein Update laufen lassen)

## Basis = Raspbian GNU/Linux 10 (buster)

### Kernel = Linux 4.19.75-v7+

### openHAB 2.5.0~S1749-1 (Build #1749) 

 

HW: Raspberry Pi 3 Model B Rev 1.2 (der Pi wird über das HAT-Brick mit Spannung versorgt, Notebook Netzteil 14V 4,5A)

>>TF-Hat-Brick

    >> 1x LCD128x64 (FW 2.0.7)

    >> 1x MultiTouch V2 (FW 2.0.0)

    >>1x Motion Detector V2 (FW2.0.2)

    >>1x Rotary Encoder V2 (FW 2.0.4)

    >>1x Rotary Poti V2 (FW 2.0.0)

    >>1x Humidity V2 (FW 2.0.6)

    >>1x Piezo Speaker (FW2.0.2)

    >>1x Outdoor Weather (FW 2.0.4)

1xMasterbrick (HW-Rev2.1 / FW 2.4.10) per USB an den Pi angeschlossen

    >>1x LCD20x4 (FW 2.0.6)

    >>1x IO-4 V2 (FW 2.0.4)

    >>1x IO-16 V1 (FW 2.0.6)

    >>1xRS485 Extention (Master)

 

1xMasterbrick (HW-Rev2.1 / FW 2.4.10) per RS485 mit ersten Stapel verbunden

    >>1x IO-16 V1 (FW 2.0.6)

    >>1x IO-16 V2 (FW 2.0.2)

    >>2x Indust Quad Relays V2 (FW 2.0.3)

    >>1xRS485 Extention (Slave)

    >>Step Down PowerSupply (Industrie Netzteil VerteilerEinbau 24V 2,5A)

 

Ich hab über die letzten 2 Monate die TF HW ein paar mal umgebaut, aber danach meist das OpenHab System zurück gesetzt (über die Openhabian Configurations-Console). Letztes Rücksetzten war So 10.11.2019. 

----------

Zur WiFi Master-Extention, hat einen eigene Dämon in Openhab konfiguriert, läuft gemeinsam mit dem Dämon für das HAT / Masterbrick in der gleichen Openhab Konfiguration

1xMasterbrick (HW-Rev2.1 / FW 2.4.10) per WIFI mit AVM (über WLAN Repeater 1750) verbunden

    >> e-Paper 296x128 (FW 2.0.1)

    >> WIFI Extention V2 (FW 2.1.3)

    >>Step Down PowerSupply (Industrie Netzteil VerteilerEinbau 24V 2,5A)

Die Signal-Stärke am Wifi ist laut BrickViewer 87/88 dB (am 18.11 abends) und 67 db (am 19.11 morgens)

Im AVM 7590 Log als auch im Repeater Log finde ich keine Infos (weder am 18.11 abends noch am 19.11 morgens).

Ich habe jetzt (19.11.2019 6Uhr) über den BrickViewer das logging im Debugg Modus gestartet, mal schaun was abends dort zu lesen ist.

Den Log-Auszug von Openhab lade ich mit hoch. Es ist momentan nicht viel los auf meinem Openhab-System, daher kann man diesen 6 Stunden Zyklus gut sehen.

Ich werde mal die Tage meine Konfig ändern und ein 16-fach IO an den Stapel mit der WiFI Extension hängen um zu schauen was passiert wenn während eines "disconnect" und reconnect ein Port (input) von offen nach geschlossen oder umgekehrt wechselt (Frage ob der Status des Port nach dem reconnect stimmt)

Ich hoffe ich hab jetzt nichts vergessen.

Viele Grüsse Stefan

 

P.S Das Forum-System hat das Icon meiner eventlog-datei mitten in den Text rein geklebt. Ich konnte nach dem Logoff die Datei auch nicht mehr öffnen.

Zitat

This attachment is not available. It may have been removed or the person who shared it may not have permission to share it to this location

Update: ich hab den Logfile gerade gelöscht, siehe Auszug Log im Post von mir am 20.11.2019 6:50Uhr

 

 

bearbeitet November 20, 2019 at 05:52 von StefanOHAN
Update Infos eingearbeitet

[StefanOHAN]

Hallo Erik

das Thema mit dem 6 Stunden Zyclus des off und online gehen der WIFI-Extension hat sich jetzt geklärt. Es liegt an einer Funktion der AVM, der "Optimierung der genutzten WLAN Kanäle". Kurz die AVM optimiert die WLAN Kanäle, daher kann es vorkommen dass die WLAN Devices ab und wieder angemeldet werden.

Nachdem ich im AVM Log noch die Zusatzinformationen für WLAN aktiviert habe, konnte ich folgende zusammenhänge auslesen

---LogMeldung der Basis-Station AVM7590

Zitat

 

20.11.19 05:03:50 WLAN-Autokanal: Aktuelle Erfassung der WLAN-Umgebung (2,4 GHz) zur Optimierung der genutzten WLAN Kanäle läuft, WLAN-Geräte werden daher unter Umständen neu angemeldet.

20.11.19 05:04:02 WLAN-Autokanal: Die Kanaleinstellungen (vorher Kanal 11 (2,4 GHz)) wurden geändert, aktiv auf Kanal 6 (2,4 GHz).

20.11.19 05:04:02 WLAN-Gerät wurde abgemeldet (2,4 GHz), Repeater.repeater, IP xxx.xxx.xxx.xxx, MAC xx:xx:xx:xx:xx:xx. (dies ist der Repeater)

20.11.19 05:04:16 WLAN-Gerät angemeldet (2,4 GHz), 216 Mbit/s, Repeater.repeater, IP xxx.xxx.xxx.xxx, MAC xx:xx:xx:xx:xx:xx.. (dies ist der Repeater)

 

---LogMeldung Repeater

Zitat

 

20.11.19 05:04:09 WLAN-Gerät wurde abgemeldet (2,4 GHz), TFWIFI-xxx-xxx-xxx-xxx, IP xxx.xxx.xxx.xxx, MAC xx:xx:xx:xx:xx:xx. (dies ist ist die WIFI-Extensioin)

20.11.19 05:04:17 Repeater an der Basis angemeldet, 216 Mbit/s,

20.11.19 05:04:45 WLAN-Gerät angemeldet (2,4 GHz), 54 Mbit/s, TFWIFI-xxx-xxx-xxx-xxx, IP xxx.xxx.xxx.xxx, MAC xx:xx:xx:xx:xx:xx. (dies ist ist die WIFI-Extensioin)

 

----LogMeldung Openhab

Zitat

 

2019-11-20 05:04:22.586 [hingStatusInfoChangedEvent] - 'tinkerforge:brickd:wifi2test' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Connection lost. Trying to reconnect.

2019-11-20 05:04:54.767 [hingStatusInfoChangedEvent] - 'tinkerforge:brickd:wifi2test' changed from OFFLINE to ONLINE (COMMUNICATION_ERROR): Connection lost. Trying to reconnect.

 

Der Zeitliche Ablauf in den verschiedenen Logfile zeigt dass diese Optimierungs-Funkion der "Übeltäter" ist.
 

Leider hatte ich nicht den vollen Logging-Umfang in der AVM aktiviert, daher konnte ich erst nachträglich den Zusammenhang erkennen 😞

Sorry 

viele Grüsse

 

Stefan

[rtrbt]

Moin,

Gut, dass sich das WLAN-Problem behoben hat. Ist auch für mich hilfreich zu wissen, was die Ursache war, der nächste User mit dem Problem kommt bestimmt.

Bezüglich der clearDisplay-Action bin ich immer noch nicht schlauer. Ich habe mal eine neue Installation mit Milestone 5 getestet, kurz geflucht, weil die Bindings nicht mehr kompilieren wollten und den Fehler gefixt (das landet in der nächsten Beta, damit die Bindings mit Milestone 5 funktionieren). Nachdem ich dann die ganzen IDs angepasst habe, funktioniert deine Rule, auch mit clearDisplay(). Danach habe ich openHAB neu gestartet und habe jetzt den selben Fehler wie du. Das ist anscheinend nicht deterministisch kaputt.

[rtrbt]

Ich habe mir die clearDisplay-Problematik nochmal angesehen. openHAB kommt anscheinend nicht damit zurecht, wenn zwei Actions von unterschiedlichen Devices den selben Namen haben, selbst wenn sie (was ich testweise mal gemacht habe) in unterschiedlichen Scopes liegen. Ich habe hier mal einen Bug-Report eingereicht. Interessanterweise tritt der Fehler nicht bei der neuen (experimentellen) Rule-Engine auf.

[StefanOHAN]

Hallo Erik,

nachdem ich Deinen Post zu dem Rule-Engine Problem gelesen habe, dachte ich mir nur mal so zum Spaß, es mit anderen Bricklet-Actions zu testen. Bei mir hat sich das IO-16 und IO-4 angeboten denn beide haben die getValue action.

Also wenn ich mich nicht vertippt habe, kann ich mit der getValue Action Deine Erkenntnis zur Auswirkung des RuleEngine Problem bestätigen.

Interessant war, als ich anfangs nur die IO-16 actions nutze (ohne dass ich für das IO-4 getAction in der Rule hatte), die IO-16 getValue action funktionierte. Erst als ich dann beim zweiten Versuch ebenfalls getAction für das IO-4 in der rule hatte, kam es immer zur Fehlermeldung.

Auch als ich anschließend aus der Rule das getAction und getvalue für das IO-4 entfernte, blieb es bei der Fehlermeldung für das IO-4 wenn ich für das IO-16 das getValue nutzte.

Ich bin ja gespannt was Du als Antwort auf Deinen Post bei den Openhab Entwicklern bekommst (ob es ein bekanntes Problem ist, oder nicht)

Zitat

 

//-check rule mit bug in Rule-Engine

rule "teste-ruleengine"

when

Item LCD128x64_BL changed

then

val io16v2Actions = getActions("tinkerforge" , "tinkerforge:io16v2:f80007d9:H4b")

val io4v2Actions = getActions("tinkerforge" , "tinkerforge:io4v2:f80007d9:G7y")

// io16v2Actions.getValue(true)

io4v2Actions.getValue(true)

end

 

Fehlermeldung wenn für das IO16 die getValue Action in der Rule enthalten ist.

Zitat

2019-11-24 16:14:06.461 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'teste-ruleengine': Instance is not an BrickletIO4V2Actions class.

viele Grüße

Stefan

[StefanOHAN]

Hallo Erik,

 

wie sieht Eure Planung bezüglich des RedBrick aus ?

Ihr stellt doch momentan noch die Openhab 1.8x version für Ihn bereit, oder ? (ich meine diese schönen kleine Funktion über den Brickviewer Openhab zu aktivieren) 

Wenn Dein neues Binding mal fertig ist, plant Ihr dann auch die Openhab 2.x Version für den RedBrick so bereit zu stellen ?

Ich hätte ein mini Projekt, da wäre RedBrick & Masterbrick ideal (klein und kompakt)

 

viele Grüsse

 

Stefan

 

[rtrbt]

Moin,

Im aktuellen Image ist openHAB 2.4 vorinstalliert, aber das hat bei meinem spontanen Test nicht funktioniert, bis ich auf der Konsole einmal

sudo apt remove openhab2
sudo apt install openhab2

ausgeführt habe. Da ist scheinbar irgendwas kaputt. Wenn von 2.5 die finale Version raus ist, sollte man die auch direkt installieren können, der RED-Brick benutzt das normale openHAB-Debian-Repository.

[rasby]

Moin, 

wie sieht es mit der Unterstützung für Temperature, Temperature 2.0, PTC, AirQuality und IO16-Bricklet aus?

Unterstützt das One Wire Bricklet Plugin auch z.B. das automatische finden von DS18B20 Temperatur-Sensoren und bietet diese als Temperature-Channel an?

VG 

[StefanOHAN]

Hallo Erik,

 

Danke für die schnelle Antwort

Gut zu wissen, dann werde ich bei der nächsten Bestellung ein RedBrick in den Warenkorb legen. 😀

 

viele Grüsse

[rtrbt]

On 12/7/2019 at 12:43 PM, rasby said:

wie sieht es mit der Unterstützung für Temperature, Temperature 2.0, PTC, AirQuality und IO16-Bricklet aus?

Die werden alle unterstützt.

 

On 12/7/2019 at 12:43 PM, rasby said:

Unterstützt das One Wire Bricklet Plugin auch z.B. das automatische finden von DS18B20 Temperatur-Sensoren und bietet diese als Temperature-Channel an?

Nein, das musst du von Hand bauen: Das Java-Beispiel hier sollte relativ gut in eine Rule konvertierbar sein. Wenn das automatisch funktionieren soll, könntest du eine Rule bauen, die periodisch searchBus ausführt und mit der REST API von openHAB Items anlegt. Das wird aber relativ viel Aufwand, deshalb würde ich eher statisch Items für die Temperatursensoren anlegen und mit einer Rule mit Werten befüllen.

[KlausGünther]

Guten Morgen,

um es kurz zu machen. Ich kann keine Things in der Inbox löschen.

Ich nutze OH 2.5M6 (ging mit M5 aber auch nicht) und das 13er Beta-Binding.

Da ich die Outdoor-Wetterstation nutze habe ich die jetzt drei mal, zweimal
in der Inbox, einmal als echtes Thing. Nur löschen kann ich sie in der Inbox nicht.....(ausblenden geht)

[rtrbt]

Moin,

Kannst du wirklich keine Things löschen, oder erscheinen sie nur nach dem Löschen wieder (nach ein paar Minuten)? Das läge dann daran, dass die Bindings alle 10 Minuten nach angeschlossenen Bricks und Bricklets suchen. Dabei landen auch gelöschte Things wieder in der Inbox. Ausblenden ist da der richtige Weg.

Dass du aber die Wetterstation in der Inbox hast, obwohl sie schon als Thing hinzugefügt ist, ist aber definitiv kaputt. Weißt du, was du gemacht hast, um die Inboxeinträge zu erzeugen? (openHAB-Updates oder oft in der Inbox löschen und suchen oder sowas?)

[KlausGünther]

Ich hatte die Station erst auf der Terasse zum testen, d.h. mit der esten ID im System, habe sie dann aufs Dach gebaut (2.te ID) und dann musste ich sie leider noch mal runter holen und etwas umbauen (3.te ID). D.h. als Thing ist sie nur einmal angelegt aber die beiden alten ID´s tauchen noch auf. Ich kann sie löschen, aber nach reboot oder beim suchen tauchen sie wieder auf.

[rtrbt]

Behebt sich das Problem, wenn du den Stack, an dem das Outdoor Weather Bricklet angeschlossen ist, neu startest? (Also Strom weg und Strom wieder dran)

Das Bricklet merkt sich einmal gesehene Stations-IDs, seit Firmware Version 2.0.2 (prüfe übrigens mal, ob du die aktuelle Firmware hast) werden Stations-IDs, wenn von ihnen 12 Stunden lang keine Daten empfangen wurden, wieder gelöscht.

[KlausGünther]

Das es die aktuelle Frimware hat wüsste ich auswendig, alles andere müsste ich probieren, wird aber vermutlich erst am Wochenende was. Aber ich bin mir ziemlich sicher das Bricklet danach nicht neu gestartet zu haben.

[KlausGünther]

So, ich habe das heute getestet. Der ganze Stapel war vom Strom, OH auch neu gestartet, tauchen immer noch auf.

 

Andere Sache. Ich habe heute mal mit meiner "Backup-Karte" versucht auf OH 2.5RC1 zu wechseln (von M6), leider
hat danach TF nicht mehr funktioniert. Eine Idee woran das liegen könnte ? Die Thinks u Items tauchen zwar auch,
liefern aber keine Werte. Online sind sie auch (inkl. Bridge)

[rtrbt]

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 noch eine neue Beta-Version der Bindings.

[KlausGünther]

vor 18 Stunden schrieb rtrbt:

Das klingt seltsam, ich sehe mir das am Montag mal beides an. .

Ich habe das Problem gefunden. Irgendwo zwischen Tastatur und Stuhl....man sollte auch nicht probieren von 2.5M6 auf 2.4 zu wechseln wenn man auch 2.5RC1 will.....

Nix desto trotz, die alten beiden Wetterstationen sind immer noch da.

[rtrbt]

Moin,

Das Problem mit den Stationen/Sensoren die in der Inbox bleiben habe ich gefunden, wird in Beta 14 (die diese Woche noch kommt) gefixt sein.

[rtrbt]

Moin,

Beta 14 ist jetzt im Post oben.

@KlausGünther Das Wetterstations-Problem sollte jetzt weg sein, da fehlte einfach das Wegräumen der alten Discovery-Ergebnisse. Außerdem verkraften die Bindings es jetzt besser, wenn man das Outdoor Weather Bricklet resettet (oder z.b. neu flasht)

@StefanOHAN Der Bug mit den Actions ist in der finalen 2.5 Version noch drin. Ich habe jetzt kurzerhand die Actions alle mit dem Gerätetyp- und Namen geprefixt. Das ist leider mehr Schreibarbeit, aber funktioniert wenigstens:  lcdActions.clearDisplay() ist jetzt lcdActions.brickletLCD128x64ClearDisplay().

@sihui Support für die Remote Switch Bricklets ist jetzt drin, das musst du aber über Rules bauen, z.B. so hier:

rule "remoteswitch"
    when
        Item Enx_Button changed to ON
    then
        val remoteActions = getActions("tinkerforge", "tinkerforge:brickletremoteswitch:01234567:XYZ")
        remoteActions.brickletRemoteSwitchSwitchSocketA(12, 21, 1)        
    end

Ansonsten nennenswerte Neuerungen sind (habe ich mal aus dem Changelog kopiert):

- Add missing labels to channels
- Use correct character set for displays
- Allow configuration of status LED and SPI baudrates
- Add more color palettes to Thermal Imaging Bricklet
- Use unused and remove unnecessary configuration parameters
- Set defaults for run-time generated channels
- Prefix action and channel type names with device category and name
- Fix Outdoor Weather Bricklet reset behaviour
- Mark configuration as advanced if API is flagged so
- Show a warning if a device's firmware is too old

Schöne Weihnachten und so!

Erik

[StefanOHAN]

Hallo Erik,

ich werde mich dieses WE gleich mal ans Testen machen.

Das mit der mehr Schreibarbeit ist ok, Hauptsache man kann die Actions nutzen.

 

Viele Grüsse, ein frohes Fest und ein gesundes und glückliches Jahr 2020

 

Stefan

[sihui]

vor 21 Stunden schrieb rtrbt:

Support für die Remote Switch Bricklets ist jetzt drin

Perfekt, danke!

Ich habe folgende Konfiguration in meiner Rule (openHAB Snapshot 3.0.0 #1780):

val remoteActions = getActions("tinkerforge", "tinkerforge:brickletremoteswitch:master241:ooc")
remoteActions.brickletRemoteSwitchSwitchSocketA(28, 1, 1)  

Housecode 28, Receivercode 1, die letzte "1"  steht ja für ON.

Mein Log:

2019-12-20 12:40:29.580 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'remoteswitch': An error occurred during the script execution: Cannot convert number literal to typejava.lang.Short

Dies ist die Konfig für die Steckdose in der Version 1 vom Binding:

rs_rcs_1000n_1.uid=ooc
rs_rcs_1000n_1.subid=rcs_1000n_1
rs_rcs_1000n_1.type=remote_switch_a
rs_rcs_1000n_1.houseCode=28
rs_rcs_1000n_1.receiverCode=1

 

Habe ich irgendetwas übersehen?

Euch allen ebenfalls ein Frohes Fest und Guten Rutsch 🌲

bearbeitet December 20, 2019 at 11:49 von sihui

[rtrbt]

Versuch mal

remoteActions.brickletRemoteSwitchSwitchSocketA(28 as short, 1 as short, 1 as short)

Das Remote Switch 1.0 ist aus der Zeit, in der die Java-Bindings noch versuchten clever zu sein und kleinere Datentypen zu benutzen. Leider konvertieren Literale nicht automatisch nach short.

[sihui]

vor 18 Stunden schrieb rtrbt:

Versuch mal

Jawohl, funktioniert 👍

Beim Speichern der Rule gibt es noch eine kleine Info, sonst ist aber alles paletti:

2019-12-21 07:47:45.821 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'tf.rules', using it anyway:
The method brickletRemoteSwitchSwitchSocketA(ThingActions, short, short, short) from the type BrickletRemoteSwitchActions refers to the missing type Object

 

[KlausGünther]

Ich habe mal wieder ein Problem :-D

Bisher war es so, dass ich das alte Bricklet im AddOns Ordner gelöscht habe, dann das neue
dorthin kopiert, kurz warten und schon lief alles wie vorher (Items, Things, usw.).

Beim Beta 14 Bindung (Auf RPi4, OH 2.5) ist es jetzt so, dass auf einmal alle Bricklets in der
Inbox neu angezeigt werden. Sprich ich habe die Neu in der Inbox und Alt in bei den Things, letzte
sind dann allerdings nicht erreichbar bzw. geben keine Werte an. Lustigerweise macht das Weather
Bricklet bzw. die Wetterstation eine ausnahme, die liefert nach wie vor Daten.

Hat da jemand eine Idee woran das liegen kann ?