rtrbt

Moin, Das ist leider etwas ungünstig dokumentiert, aber die Rust-Bindings mappen die ersten 256 UTF-8 Codepoints auf auf die möglichen Werte eines Bytes um. In den Bindings sieht das so aus: fn try_to_le_byte_vec(s: String, max_len: usize) -> Result<Vec<u8>, BrickletError> { if s.chars().any(|c| c as u32 > 255) { return Err(BrickletError::InvalidParameter); } let bytes: Vec<u8> = s.chars().map(|c| c as u8).collect(); if bytes.len() > max_len { Err(BrickletError::InvalidParameter) } else { let mut result = vec![0u8; max_len]; result[0..bytes.len()].copy_from_slice(&bytes); Ok(result) } } Das heißt du solltest das Characterset mit \u{01} bis \u{FF} benutzen können. Edit: Brainfart, \u{00} terminiert den String (aus Bricklet-API-Sicht), \u{01} ist das erste sinnvolle Zeichen.

Moin, Wenn du garnicht programmieren willst, kannst du entweder den Data-Logger des Brick Viewers benutzen, der schreibt die Messdaten dann in eine CSV-Datei, die du z.B. mit Excel ö.Ä. auswerten kannst, oder alternativ nimmst du das Tabletop Weather Station Demo-Programm. Das schreibt die Messdaten in eine sqlite-Datenbank und kann sie auf einem LCD 128x64 Bricklet anzeigen.

Moin, Ich bin diese Woche noch im Urlaub, sehe mir das alles mal nächste Woche an.

Uff, ein Weihnachtswunder :D Ich bin diese Woche noch im Urlaub, nächste Woche melde ich mich dann nochmal.

Das dürfte an der Namensänderung liegen, die ich machen musste. Da jetzt intern alles anders heißt (z.b. ein Stepper Brick nicht mehr nur Stepper), betrachtet openHAB das als andere Devices. Die alten musst du vermutlich löschen und neu anlegen, sorry dafür! Edit: @sihui Diese Warnung sehe ich bei mir auch immer, habe noch auf der TODO-Liste rauszufinden, was da das Problem ist. Funktionieren tuts ja anscheinend auch so.

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.

Hast du beim Neustart des Pythonscripts (damit meinst du die MQTT-Bindings?) das init-file wieder benutzt? Sonst funktioniert es nicht, weil die Bindings die Callback-Registrierung verlieren wenn du sie neu startest.

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

Das klingt doch erstmal gut :)

tzlocal für Python 3 findest du hier. Je nach Distribution gibt es bei dir eventuell ein Package dafür, bei Debian-esken Distributionen z.b. python3-tzlocal. Das selbe Problem hast du dann eventuell noch bei pytz, da heißt das Debian-Package python3-tz. Im README haben wir inzwischen als Mindestanforderung python 3.5, d.h. am einfachsten wäre es, wenn du dein Python aktualisierst. Abgesehen davon habe ich gerade den Source nochmal durchsucht und konnte von dem Konstrukt keine weiteren Stellen finden (außer die im Render-Widget). D.h. du kannst mal probieren, ob es dich weiterbringt, wenn du jeweils *color durch color[0], color[1], color[2] ersetzt. Das sollte in den Zeilen 376, 378, 381, 383, 386 und 388 sein. Edit: Ich habe leider gerade kein python3.4 zur Hand, sonst würde ich das selber testen.

Hm, da habe ich versehentlich zu aktuelle Python-Features benutzt. Wenn du eh aus den Sourcen baust, kannst du entweder den Master-Branch pullen/neu runterladen (habe den Fix gerade committet) oder du änderst die Zeile 111 in der main.py selbst: sys.excepthook(*sys.exc_info(), self) muss stattdessen sys.excepthook(*sys.exc_info(), thread=self) sein.

Moin, Welche Version der MQTT-Bindings hast du? Tauchen die Daten der Stationen/Sensoren im Brick Viewer auf? Bekommst du über den MQTT-Broker irgendwelche Fehlermeldungen? (Subscribe mal # als Topic, dann bekommst du alles) Ich habe das hier gerade mal getestet, und es funktioniert (nachdem ich die UIDs ausgetauscht hatte), also an deinem init-file liegt es nicht. Gruß, Erik

Moin, Teste das mal mit der angehangenen Version der Bindings (habe mal die Zip und das gepackte Node-Package angehangen). Das Entpacken von bool-Arrays war anscheinend etwas verbuggt. tinkerforge_javascript_bindings_2_1_25.zip tinkerforge-2.1.25.tgz

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.

Hi, Have you printed the values each period? I'm assuming, that your power supply is fluctuating enough, that the HAT can measure this. (I've just tried this here with a USB power supply and can reproduce it.) So the value is in fact changing every period.

Wäre möglich, dann ist das vermutlich ein Stromversorgungsproblem. Das würde dann auch erklären warum der eine RED-Brick das hat und der andere nicht. Kannst ja nochmal zurücktauschen

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.

Hm, du hast da noch einen alten Kernel laufen, das sehe ich an dieser Meldung: fc-r02-sensor kernel: ring_buf_dump: f->f_op->write_iter (das ist der Debug-Code für das andere Problem, der ist nicht mehr drin) Du kannst dir mit uname -v die Zeit ausgeben lassen, zu der der Kernel kompiliert wurde. Das ist beim richtigen #10 Tue Dec 10 12:27:26 CET 2019 Hast du vielleicht die Pakete vertauscht?

Moin, Das sieht nach einem neuen Problem oder zumindest einer neuen Ausprägung aus. Ich habe dir mal wieder einen Kernel mit Debug-Ausgaben angehangen, wenn du das mit dem reproduzieren kannst, schick nochmal das ganze Kernel-Log. (Der interessante Teil beginnt dann mit dem Packet Size Error und endet mit "Dump done.") Hier her senden würde vermutlich nicht viel helfen, den Fehler habe ich so auch noch nicht gesehen, da vermute ich mal, dass die Umgebung mit reinspielt. linux-image-4_13.0-red-brick-1_4_13.0-red-brick-1_armhf.deb

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.

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?)

Die werden alle unterstützt. 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.

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.

Du schreibst, dass die SSID gleich ist. Meinst du damit den nur Anzeigenamen oder auch die BSSID? Die Extension findet das Netz vermutlich anhand der BSSID, deshalb kann es helfen, wenn du die Extension einfach nochmal neu konfigurierst. Alternativ kann es sein, dass die Extension Probleme mit der Implementierung des n-Standards der FritzBox hat. Neuere FritzBoxen deaktivieren die älteren g- und b-Standards, die mit der Extension verlässlicher laufen. Hier steht, wie man die älteren Standards aktivieren kann.

Was sagt das Kernel-Log? Und steht im Log von deinem Switch was hilfreiches? Edit: Was mir noch einfiel: Hast du die Probleme jetzt nur noch mit einem der RED-Bricks oder mit beiden?