remotecontrol

Hallo zusammen, ich habe jetzt brickv-2.4.25 - runtergeladen - entpackt - in brickv-2.4.25/src das ./build_src.py aufgerufen - danach im brickv Verzeichnis "phython3 main.py", das liefert: Traceback (most recent call last): File "main.py", line 438, in main main_window = MainWindow(brickv_version, args.host, args.port, args.secret, args.remember_secret) File "/home/holger/Downloads/brickv-2.4.25/src/brickv/mainwindow.py", line 92, in __init__ if sys.flags.dev_mode: AttributeError: 'sys.flags' object has no attribute 'dev_mode' QThread: Destroyed while thread is still running Konkret habe ich Python 3.6.15 Sollte das damit gehen ? Kommetiere ich Zeile 92 und 93 in mainwindow.py aus, dann startet es fehlerfrei.

hmm, also mit einem echo none > package_type klappt das nicht, da kommen der Fehler immer noch. Ich bleibe erstmal bei der alten Version. Dennoch danke für die Klärung.

Hallo zusammen, ich erzeuge mir einen brickv immer aus dem Source Package für SuSE Linux über build_src.py, hat bisher auch immer funktioniert. Mit der letzten Version bekomme ich aber einen Fehler beim Start danach: Traceback (most recent call last): File "main.py", line 454, in <module> main(not getattr(sys, 'frozen', False)) File "main.py", line 384, in main if not args.no_dev_mode and dev_mode and not sys.flags.dev_mode: AttributeError: 'sys.flags' object has no attribute 'dev_mode' Aktuell ist ein Python 3.6.15 installiert.

Ich muss mal aufräumen und meine Bastelkiste leeren, darum verkaufe ich: 1x Stepper-Brick 1.2, 25 € 1x Master-Brick 2.1, 20 € 1x Red-Brick mit 16 GB Samsung Micro-SD, 30 € (verkauft) 1x OLED 128x64 1.1, 12 € 1x Remote Switch 2.0, 10 € zzgl. Versand im Polsterumschlag 3€. Bei Interesse bitte eine Nachricht senden.

Ich habe drei Temperatur / Feuchte Sensoren und eine echte Wetterstation. Laut Protokoll kommt ein Callback für einen Sensor mit ID 222. Für eine Wetterstation würde ja ein anderer Callback aufgerufen. Aber: die Wetterstation hat ID 111 und hat zu dem Zeitpunkt auch länger nichts mehr geschickt, dann kommt was mit ID 222 ? Und nachdem 222 länger nichts gesendet hat kommt die 111 wieder. Ich werde das Gefühl nicht los, dass die Übertragung ab und zu einen Bit-Shift hat und zufällig ein korrekter CRC kommt. Vielleicht kommen ja auch viele fehlerhafte Pakete, darum so viele Timeouts. Und ab und zu kommt was, was zumindest einen korrekten CRC hat, aufgrund der "kaputten" Daten aber als Sensor erkannt wird. Dann passen die Werte natürlich nicht. Denkbar?

Nochmal eine andere Frage: kann ein Sensor fremder Art, der auf derselben Frequenz arbeitet das System stören ? Ich habe nämlich seit einige Zeit den Effekt, dass ein Sensor mit einer neuen ID auftaucht, ganze schräge Werte liefert (Feuchtigkeit über 100%, auch Temperatur 90°) und dann wieder "verschwindet". Verschwindet in dem Sinne, dass nur ganz sporadisch mal ein Wert gemeldet wird und dann wieder lange nicht. Da frage ich mich jetzt gerade: klappt die Kommunikation mit meinen Sensoren nicht richtig und da geht mal ein Bit verloren oder funkt da wer quer ?

Sieht alles trocken aus. Die Kabel sind schon etwas verwittert, aber Batteriefach ist ganz sauber. Auch frische Batterien machen keinen Unterschied.

Hallo TF Team, seit knapp 2 Jahren betreibe ich eine Außen-Wetterstation. Funktionierte soweit einwandfrei, aber seit gut 3 Monaten setzt diese bei Regen aus: sie sendet dann keine Signale mehr an das Outdoor-Weather-Bricklet. Wenn es alles wieder trocken ist (4-5 Stunden nach Regen) dann kommt sie wieder und meldet auch ein paar mm Niederschlag mehr, als sie zuletzt hatte. Also ganz scheint sie in der Zeit nicht auszufallen, nur kommen keine Werte mehr am Bricklet an. Zuerst dachte habe ich das gar nicht richtig zuordnen können, aber inzwischen ist das klar erkennbar immer bei Regen: nach einer Weile setzt sie aus und kommt dann wieder nachdem es zu regnen aufgehört hat. Was kann ich da machen? Die Kontakte der Stecker habe ich schon mal kontrolliert, alles soweit sauber.

Hallo TF-Team, in der API vom DigitalInV2 gibt es eine Methode setEdgeCountConfiguration(int channel, int edgeType, int debounce) aber wofür dient der Parameter "debounce" ? Ich habe keinen EdgeCount Callback gesehen (oder habe ich das übersehen)? D.h. aktuell muss man eh immer getEdgeCount rufen. Oder ist das eher "for future use" ? Viele Grüße

Danke für die Infos. D.h. ich müsste eine Wallbox ohne Stecker bestellen, der Elektriker baut einen an und für den Stecker alleine brauche ich eine separate Rechnung.

Hallo TF Team, wenn ich in meiner Garage schon einen Kraftanschluß mit CEE Stecker (3x20A) habe, dann muss ich die Wallbox (für 11 KW) doch nur befestigen und anstecken - oder muss das noch von einem Elektriker "abgenommen" werden? Ihr schreibt im Blog: Aber ich würde davon ausgehen, dass die 11 KW Boxen so voreingestellt sind. Beim KfW steht wieder Wenn ich nur die 11 KW Variante bestelle müsste das ja aus der Rechnung hervor gehen - oder ? Ich werde meinen Elektriker mal fragen, ob der Anschluß wirklich die 20 A pro Phase aushält.

Hallo TF-Team, wenn man bei E-Paper Bricklet per e_paper_296x128_draw_text Text an der Position 0,0 ausgibt (links oben), dann ist die Schrift nicht ganz sichtbar, mit Ausnahme des kleinsten Fonts 6x8. Alle Anderen Fonts scheinen die Ziffern um einige Pixel zu hoch anzusetzen. Ist das gewollt bzw. bekannt?

OK ich werde die bricklet nochmal flashen. Auf die UID habe ich nie geachtet (meine Anwendung ermittelt die Bricklets nur über den Typ, solange sie eindeutig sind). Habs jetzt aber dennoch mal auf einen 3-stelligen Wert gesetzt. Die Temperatur setze ich nur 1x bei Start der Anwendung. Da ich aber gerade am rumtesten war, habe ich das den Abend sicher öfter gestartet und somit auch neu gesetzt. Wenn die Anwendung später mal länger läuft wird das nur noch selten gesetzt. Jetzt lese ich bei Start auch den aktuellen Wert wieder aus und wenn sich nichts geändert hat zum Zielwert mache ich nichts. Danke für die Antworten.

Nachtrag: ich habe jetzt mal explizit den Temperatur-Offset auf 0 gesetzt und der Effekt scheint weg, jetzt kommen wieder Werte im => Speichert das Bricklet den Offset auf nach Reset / Trennung von der Stromversorgung ? Und laut Doku reduziert ein Offset von 10 die gemessene Temperatur um 0.1°, also muss ich 200 übergeben, um 2° zu reduzieren - ist doch richtig oder nicht ?

Hallo TF-Team, ich habe meinen Aufbau eine Weile laufen lassen (MasterBrick mit WLAN, Co2, Barometer + EPaper) - sah eigentlich gut aus, alle Werte plausibel. Jetzt zeigt das CO2 Bricklet aber extreme Werte bei Temperatur und Luftfeuchte an - der CO2 Wert sieht noch OK aus: Auch nach Neustart kommen wieder solche Werte - eine Idee was falsch sein kann? Ich hatte den Aufbau nicht verändert, also keine Stecker o.Ä. geändert. Stromversorgung ist eine große Powerbank per USB am Master. Noch ein Nachtrag: es sieht so aus, als würde die Temperatur ständig in Stufen sinken, bis ein Integer Overflow kommt, dann spring die Temperatur von ca. -300° auf 300° und sinkt dann wieder. Also die Stufen im Temperaturdiagramm im Bild setzen sich immer so fort. Viele Grüße

Hallo TF-Team, ich habe jetzt auch ein CO2 Bricklet und Fragen zum Temperatur-Offset und Luftdruck: * Bei der Temperatur sieht es so aus, als würde mein Bricklet konstant ca 2° zu viel anzeigen - ohne Gehäuse, frei auf dem Tisch liegend. Ist das im erwarteten Bereich ? Das würde ich dann konstant 1x bei der Initilisierung reduzieren. * wenn ich den Luftdruck setze: das ist schon der Luftdruck auf aktueller Höhe, nicht auf Meeresspiegel normiert - oder ? Ich bin auf 500m Höhe und es macht einen merklichen Unterschied ob ich den Luftdruck dazu gebe oder nicht (ppm Wert ist jetzt höher) * in welchem Zyklus sollte man den Luftdruck aktualisieren ? Wenn ich die Dezimalstellen vom Barometerbricklet abschneide (/ 1000), dann ändert sich das eh nicht so oft, vielleicht 1x pro Minute. Viele Grüße Holger

OK, danke für den Hinweis. Vielleicht habe ich mich auch verguckt (17 <-> 12), werd ich mal beobachten.

Hallo zusammen, auf welchen Zeitraum bezieht sich der Niederschlagwert der Wetterstation? Ich habe die gestern aufgebaut und initial waren es 0.3mm, heute früh auch noch. Heute hat es geregnet und es ging auf 17.9mm hoch. Aber jetzt geht es wieder runter auf 12 und weniger. Ist das Niederschlag in den letzten 8 Stunden, 10 oder 12 Stunden ?

Nachtrag - Ports getauscht: Quad-Relay an Port C und Temp-IR an Port D mit 2m Kabel => geht ! Vorher war es umgekehrt: Temp-IR an C oder "unten" (A oder B) und Quad-Relay an D.

Es scheint am Quad Relay zu liegen: stecke ich das ab, dann bekomme ich realistische Werte am Temp-IR Sensor ! Aufbau dann nur noch Master mit 2m Kabel zum Temp-IR (also auch kein WIFI mehr). Stecke ich das Quad Relay wieder an => 0° Habe das Quad-Relay mit dem 6cm Kabel und dem 15cm Kabel versucht, am dem das Temp-IR funktioniert ... Kann es sein, dass die Gesamtkabellänge am Stack das Problem ist? Mit einem 2m Kabel geht es, kommt aber ein Kabel dazu, sei es auch nur ein Kurzes, dann kommen Fehler ... Oder ich nehme kurze Kabel, dann geht es auch.

Also ein Rotary Poti funktioniert an dem 2m Kabel. Aber auch an einem zweiten 2m Kabel funktioniert das Temp-IR nicht (zeigt 0° bei beiden Werten). Hänge ich ein Quad Relay dran zeigt der Brickv erstmal nichts Auffälliges: alle 4 Ports lassen sich schalten und der Status wird nach Disconnect / Connect korrekt erkannt. Ich habe aber die Ausgänge nicht real nachgemessen. Am Bricklet scheint es aber anzukommen, sonst würde der Status nach reconnect nicht korrekt ausgelesen werden - oder ?

Hallo TF Team, ich habe folgenden Aufbau: Master WIFI ext 2.0 Industrial Quad Relay (mit 6cm Kabel am Master) Temperature IR 1.0 Und ich habe auch noch die "alten" geschirmten 2m Kabel mit 10pol Stecker. Wenn ich das Temperature Bricklet mit 15cm oder 50cm Kabel anschließe funktioniert es einwandfrei. Nehme ich das 2m Kabel wird es erkannt, aber für beide Temperaturwerte kommt nur 0.0 zurück. D.h. das Bricklet scheint mit dem langen Kabel nicht zu funktionieren? Ist das generell so oder eher Zufall? Jetzt hätte ich tatsächlich mal den Bedarf für eine längere Verbindung und habe noch ein langes Kabel, nur tut es nicht ... Wenn das eh nicht geht kann ich das lange Kabel mal entsorgen.

Hatte den PI jetzt 3 Tage aus Nach Neustart war das Datum 14. Februar 2019 Nach einer Weile (~ 30 Sekunden) fing die Zeit an, langsam hochzuzählen, das wurde dann schneller bis die aktuelle Zeit erreicht wurde der ganze Vorgang ging ca. über 2 Minuten Sieht für mich so aus, als verliert die RTC im HAT die Zeit und der NTP braucht einfach eine Weile bis die korrekte Zeit im System eingestellt ist. Das Hochzählen scheint mit systemd-timesynd und NTP ähnlich zu sein. Ist der PI nur ein paar Stunden aus, so ist die Zeit quasi nach Booten sofort korrekt.

OK versuche ich bei Gelegenheit. Wie lange puffert die RTC im HAT denn ca. die Zeit? Ich muss den PI ja min. 12h Stunden aus lassen damit beim Neustart die Zeit sichtlich hoch geht und der Vorgang lange genug dauert.

Mit NTP und Ethernetverbindung beim Booten tritt das Problem nicht mehr auf. Das NTP gar nicht installiert war ist mir nicht aufgefallen, dachte jede Distro installiert das mit ... nutze das Standard Raspbian. Die fake-hwclock habe ich mal deinstalliert.