rtrbt
-
Gesamte Inhalte
1.548 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
150
Posts erstellt von rtrbt
-
-
Damit ich da den Überblick nicht verliere, du hast folgendes Ausgangszenario: LAN-Kabel sind alle eingesteckt, das USB-Kabel am RED-Brick nicht, Switch ist aus.
Und dann folgende Tests gemacht?
- Switch an, RED-Brick bootet über PoE, Netzwerkverbindung funktioniert
- Dann USB-Kabel eingesteckt, dann verlierst du die Netzwerkverbindung zum anderen Stapel
- Alles aus, USB-Kabel eingesteckt gelassen, dann alles wieder gebootet, dann funktioniert es nur, wenn du die Thermofühler an den Bricklets angeschlossen hast?
-
Moin,
Das klingt alles sehr verwirrend. Mich würde mal ein Foto vom Aufbau interessieren. Zusätzlich kannst du auf der RED-Brick-Konsole mal versuchen, die IP des Switches und der Stapel jeweils anzupingen (mit
ping 192.168.0.1usw.)
Edit: Wenn du beim Switch die IP konfigurieren kannst, ist das ein Managed Switch, d.h. mit eigener Konfiguration per Web-Interface oder so? Eventuell ist da auch etwas falsch konfiguriert.
-
Der InvalidParameter-Fehler der von der Rule geworfen wird kommt direkt vom Bricklet. Das heißt in dem Fall, dass requestTagID aufgerufen wurde, obwohl das Bricklet nicht in einem der Idle-States war. Hast du eventuell noch etwas nebenbei laufen? (Andere Rules, die das Bricklet benutzen, andere Programme, den Brick Viewer?) Eventuell ist es sinnvoll, die Rule so umzuschreiben, dass periodisch requestTagID aufgerufen wird und eine zweite Rule das Ergebnis abfragt, dann ist das zumindest selbstreparierend.
Zu dem LED-Strip-Problem: Ich erinnere mich, dass es beim Testen ein Krampf war, mit den short-Arrays umzugehen, dazu kommt auf jeden Fall noch ein Beispiel. Dass das Bricklet short-Arrays erwartet, liegt an den Java-Bindings, deren Typmapping (von Java-Typen auf Device-Typen) ich unverändert übernehme: Das war in den ersten Versionen effizient im Sinne von short benutzen, wenn der Wertebereich klein genug ist. Da das in Java aber zu vielen nötigen Casts usw. führt, wurde das irgendwann umgestellt. Für die da schon veröffentlichten Devices kann das aber nicht geändert werden, ohne dass die Bindings nicht mehr rückwärtskompatibel zu alten Programmen sind.
-
Was hast du in deinem Python-Programm als HOST eingetragen? Das steht leider nicht in der Fehlermeldung mit drin.
Ansonsten fällt mir nur auf, dass ein paar deiner Subnetzmasken nicht ganz passen: Das sollte eigentlich immer 255.255.255.0 sein.
Edit: Wo führst du das Programm aus? Auf dem RED-Brick? Und mit dem PC bist du per USB an den Stacks verbunden?
-
Dann kannst du eigentlich das selbe machen: Solange die Extensions sich einig sind, wie das Netz funktioniert, können sie auch untereinander kommunizieren.
-
Moin,
Was hast du denn genau konfiguriert? Folgendermaßen sollte es klappen:
- Sieh mal nach was der IP-Präfix ist, den deine FritzBox verwendet (Das siehst du in deren Einstellungen, oder indem du eine der Extensions auf DHCP stellst und dir dann die IP ansiehst, die sie bekommt). Standardmäßig ist das 192.168.178., wenn es was anderes ist musst du den Rest anpassen.
- Die statischen IPs sollten nicht mit denen kollidieren, die die FritzBox vergibt. Normalerweise vergibt sie IPs bis .200, also sollten 192.168.178.201 usw. gefahrlos nutzbar sein.
- Dann kannst du pro Extension eine IP vergeben, z.b. 192.168.178.201 für die erste ....202 für die zweite usw. Wenn du sicher gehen willst, dass die IPs frei sind, kannst du auf der Konsole die IP mit "ping 192.168.178.201" oder so anpingen, wenn keine Antwort kommt ist die IP noch nicht vergeben.
- Die Subnetzmaske ist typischerweise 255.255.255.0 (das heißt, dass dein Netz, einen festen Präfix auf den ersten drei Blöcken hat, der vierte Block ist dann die Adressierung im Netz, das wird hier ganz gut erklärt)
- Das Gateway ist die IP deiner FritzBox, also vermutlich die 192.168.178.1
Edit: Subnetzmaske war falsch herum
-
Moin,
Eins vorweg: Alle Aussagen hier gelten nur, wenn du ganze Stacks ansteckst/abziehst. Hot-Plug einzelner Bricks/Bricklets an einen laufenden Stapel wird nicht unterstützt.
On 4/21/2020 at 10:01 AM, DoIT said:Was ist aber wenn das LCD schon mal angesteckt war aktuell aber nicht. Also das Objekt einen Wert hat. Hier würde es doch zu einem Laufzeitfehler kommen oder?
Gleiches Thema. Wie verhält sich das ganze wenn ich Ausgänge Schalten möchte die zwar schonmal angesteckt waren jedoch (Das Objeckt somit einen Wert hat) aktuell nicht mehr verbunden sind?
Da gibt es mindestens die folgenden zwei Möglichkeiten:
Du kannst, wenn dein Stapel per USB angeschlossen ist, im enumerate-Callback den ENUMERATION_TYPE_DISCONNECTED verwenden: Wenn du das USB-Kabel ziehst, bekommst du das Callback für jedes Gerät im Stapel, das angeschlossen war und mindestens einmal eine Nachricht geschickt hat. Da kannst du dann das entsprechende Objekt auf None setzen. Achtung: Da sind nur der enumeration_type und die UID sinnvolle Werte, du musst dir bei den _CONNECTED und _AVAILABLE-Enumerations die UIDs speichern und in den _DISCONNECTED-Enumerations dann nachschlagen.
Alternativ kannst du bei jedem Aufruf warten, ob ein Timeout kommt (Bei Settern wie backlight_on() musst du response-expected aktivieren, sonst bekommst du das nicht mit). Da bietet es sich an eine Wrapper-Funktion zu schreiben wie z.B. (Achtung, ungetesteter Code):
from tinkerforge.ip_connection import Error def wrapper(device, fn): try: fn() except Error as e: if e.value == Error.TIMEOUT: device = None # Verwendung wrapper(self.lcd, self.lcd.backlight_off) # oder wenn der Aufruf Parameter hat wrapper(self.lcd, lambda: self.lcd.write_line(0, 0, s))
Die Fehlerbehandlung kann dann natürlich beliebig komplex sein, je nachdem was du brauchst.
On 4/21/2020 at 10:01 AM, DoIT said:Gibt es eine Prüfung ob das Objekt noch angeschloßen ist und reagiert? So eine Art Ping?
Du kannst prinzipiell prüfen, ob ein Brick/Bricklet noch da ist, indem du irgendeine Funktion davon aufrufst (Es bietet sich get_identity an, das wird von allen Bricks/Bricklets unterstützt und hat keine Nebeneffekte)
On 4/21/2020 at 10:01 AM, DoIT said:Eine weiter Frage wäre noch. Ich möchte außerhalb dieser Klasse die Objekte z.B. das LCD ansprechen. Wie kann ich nun sicherstellen das die Nachricht am LCD angekommen ist bzw. es zu keinem Laufzeitfehler kommt ohne jedesmal den Aufruf des Objektes in einen try catch anweisung zu packen. Denn es kann ja sein das das Display zum Beispiel noch gar nicht verbunden war. Bzw. aktuell nicht verbunden ist.
Das kommt auch ganz darauf an, was du brauchst. Eine relativ einfache Variante ist es, wenn du alles was du mit dem LCD machst in zwei Gruppen aufteilst: 1. Konfiguration, die nur einmal passiert, dann aber funktionieren muss. (Das kannst du dann aus dem enumerate-Callback heraus ausführen und self.lcd nur zuweisen, wenn alles fehlerlos durchgelaufen ist) 2. Ausgaben/Anzeigen die du dauerhaft aktualisieren willst, bei denen es aber nicht kritisch ist, wenn eine Aktualisierung verloren geht, weil die nächste das ganze wieder repariert. (z.B. die Temperaturanzeige wie im Beispielcode). Bei denen kannst du mit der Fehlerbehandlung dann lax sein (z.B. ein try...except um alles nur damit das Programm nicht beendet wird)
Wenn du periodische Aufgaben hast, die definitiv durchgeführt werden müssen, musst du dir etwas komplexeres bauen, zum Beispiel eine Warteschlange von Tasks, die nacheinander abgearbeitet und bei Fehlern wiederholt werden. So eine Warteschlange kannst du dann auch von außerhalb befüllen.
-
Moin,
Dein LCD128x64-Problem war ein Firmware-Bug: DIe Bindings nutzen die neue Version der Java-Bindings, die explizit die Länge der Antwortpakete prüft. Das LCD hat aber fälschlicherweise bei dem remove eines spezifischen Tabs nicht wie von den Bindings erwartet ein leeres Paket zurückgeschickt, sondern die Nummer des Tabs mit hineingeschrieben. Das war ein Byte zuviel, deshalb die Fehlermeldung.
Bei dem IO-16 1.0 musst du den Parameter für GetEdgeCount nach short casten, dann sollte es funktionieren:
val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(1 as short, true).get("count") as shortDas NFC-Beispiel sehe ich mir nochmal an, danke dafür!
Das muss ich mir nochmal in Ruhe ansehen, war die letzte Woche im Urlaub. Ich melde mich dazu nochmal.
Gruß,
Erik -
Moin,
Sorry, beim LEDValueIndex hast du vollkommen recht, da habe ich den Bug für das LED Strip V2 gefixt und es damit für das alte Bricklet wieder kaputt gemacht. Das LED Strip V2 addressiert auf Farb-Ebene.
16 hours ago, matthiask said:Mit der vorhandenen Action brickletLEDStripSetRGBValues hatte ich probiert, habe damit aber keinen Erfolg gehabt und dann erstmal das String-Attribut mit einer Xtend-Function verwendet.
Was klappte mit der Action nicht?
16 hours ago, matthiask said:Kommt zu den LED Strip Actions noch etwas mehr Doku bzgl. Parametern?
Findet sich hier
16 hours ago, matthiask said:Habe noch ein NFC/RFID Bricklet. Weiter oben im Thread war ein Beispiel bzgl. NFC Scan Loop. Ich finde die Xtend - Skripte grundsätzlich schon recht hakelig, da wäre das mit dem Timer und Tag nachlesen vielleicht ganz gut als openHAB Event modelliert...
Es gab da mal die Überlegung, einen Simple-Mode direkt in die Firmware einzubauen, dann aber vermutlich nur für das neuere NFC-Bricklet oder einen eventuellen Nachfolger. (Der Flash ist schon recht voll, vorallem beim alten NFC-RFID). Deshalb würde ich da erstmal ungern eine openHAB-spezifische Lösung bauen.
Du kannst übrigens anstelle der Xtend-Skripte auch die experimentelle Rule-Engine verwenden, mit der du in diversen "richtigen" Programmiersprachen skripten kannst.
-
Firmware: Industrial Dual Analog In 2.0 Bricklet 2.0.5
- Fix callback generation limit of 500 voltage callbacks per second per channel
Download: Industrial Dual Analog In 2.0
-
Firmware: Industrial Dual Analog In 2.0 Bricklet 2.0.5
- Entferne Callback-Limit von 500 Voltage-Callbacks pro Sekunde pro Channel
Download: Industrial Dual Analog In 2.0
-
Moin,
Vorweg: get_adc_values gibt dir die Rohwerte des ADCs, die solltest du eigentlich nur benötigen, wenn du das Bricklet kalibrieren möchtest.
3 hours ago, cl- said:Selbst wenn ich einen Kanal einzeln abfrage mittels get_voltage() bekomme ich nur 500 Werte pro Sekunde.
Wenn du get_voltages benutzt erreichst du nur 500 Nachrichten pro Sekunde, weil 500 Nachrichten zum Bricklet geschickt werden (die Anfragen) und dann 500 Nachrichten wieder vom Bricklet zurück (die Antworten)
1 hour ago, cl- said:Wie kommt man denn auf die 1000 Nachrichten pro Sekunde, wie in deinem Beispiel? Was ist der Unterschied zwischen Nachrichten pro Sekunde und Messwerte pro Sekunde?
Die ~1000 Nachrichten pro Sekunde sind die Limitierung, wie viel Durchsatz ein Master Brick an USB erreichen kann: Der Master Brick ist per USB 2.0 angebunden, was mit 1000Hz auf neue Nachrichten pollt. Daraus leitet sich dann auch die Tick-Rate der Firmware des Master Bricks ab, die auch bei 1000Hz liegt. Das hat mit den 976 Messwerten pro Sekunde des Bricklets keinen direkten Zusammenhang: Die bis zu 976 Messungen pro Sekunde macht der Chip, der auf dem Bricklet verbaut ist, das Bricklet selbst kann dann mit bis zu 1000 Nachrichten pro Sekunde die Messwerte kommunizieren. Das heißt dann auch, dass du, wenn du die Sample-Rate auf 1 Sample pro Sekunde setzt, das Callback aber auf einer Millisekunde (und value_has_to_change=false) lässt, du theoretisch 1000 Nachrichten pro Sekunde bekommen solltest, die dann aber nur eine Messwertänderung pro Sekunde beinhalten, du bekommst also sehr viele gleiche Nachrichten.
Ich habe hier das ganze mal getestet und festgestellt, dass die Firmware einen Bug hat: Wenn man nur einen Channel verwendet, ist die Callback-Geschwindigkeit (nicht die Messrate!) auf 500 Nachrichten pro Sekunde limitiert. Teste bitte nochmal mit und ohne Isolator Bricklet mit der Firmware 2.0.5, die gerade veröffentlicht wurde.
Da zwischen dem Bricklet und dem Programm auf dem Rechner einige Buffer liegen, die asynchron gepollt werden, kann es da zu unintuitiven Effekten kommen: Bei meinen Tests schaffe ich ohne Isolator Bricklet nur ~ 900 Nachrichten, mit Isolator aber 1000. Es kann auch helfen, wenn du den Master Brick an einen USB-3 Hub hängst, es gibt manche, die auch USB-2-Geräte mit mehr als 1000 Hz pollen. Falls du einen Raspberry Pi mit HAT zur Hand hast, könnte das auch helfen.
Ich habe dir mal mein Testprogramm angehangen, das noch ein paar Tricks verwendet, damit die Kommunikation möglichst effizient läuft: Wenn du damit testen willst, musst du noch die UIDs austauschen, gegebenenfalls den Port am Master Brick und, wenn du mit Isolator testest, die Zeilen 22 bis 24 mit reinnehmen.
Gruß,
Erik -
Hi,
I agree, the documentation is a bit confusing there. I've changed this to
For a Bricklet this is the UID of the Brick or Bricklet it is connected to.
For a Brick it is the UID of the bottommost Brick in the stack.
For the bottommost Brick in a stack it is "0".The change will soon be in the online documentation. The Rust (and Go) documentation in the code and on docs.rs will be updated with the next bindings release.
-
Moin,
Beta 21 ist jetzt im Post oben. Bitte darauf achten, dass sie von den Java-Bindings (als Maven-Package, ist auch in der Zip enthalten) abhängen, die auch in das Addons-Verzeichnis gelegt werden müssen.
Die nächsten Wochen werde ich an einem anderen Projekt arbeiten müssen, das etwas dringender geworden ist. Die Bindings nähern sich aber sowieso langsam einem "fertigen" Zustand. Ich würde deshalb die Entwicklung für die nächsten Wochen erstmal ruhen lassen, und nur nach und nach die deutsche Dokumentation schreiben. Dabei sehe ich mir nochmal die Modellierung aller Devices an, und verpasse ihr einen Feinschliff, insbesondere für die möglichst einfache Verwendung mit Channels, da kompliziertere Anwendungsfälle mit Actions abgebildet werden können. Zum Beispiel werde ich den LEDStrip Values Channel so umstellen, dass man mit einem ColorPicker-Item alle angeschlossenen LEDs konfigurieren kann. Nebenbei kümmere ich mich dann auch darum, wie die Bindings nach dem Ende der Betaphase zur Verfügung gestellt werden (Lies: ob sie in die openHAB-Distribution integriert werden).
Was mir sehr helfen würde ist, wenn Ihr alle Bugs, die im Betrieb auftreten nochmal hier erwähnt, damit möglichst nichts übersehen wird.
@matthiask Sorry für die späte Antwort, du hast da vollkommen recht. Teste bitte nochmal mit Beta 21, da ist der Fix drin. Da du einer der mir bisher bekannten Nutzer des LED-Strip Bricklets bist: würde es dir für deinen Anwendungsfall reichen, wenn du alle LEDs auf einmal mit einem Color-Item kontrollieren könntest, oder machst du kompliziertere Dinge? Hast du dir schon die Actions des Bricklets angesehen?
Gruß und Frohe Ostern,
Erik -
Moin,
Das unterstützt die Firmware bereits: Wenn du dein Relay nicht mit set_state sondern set_monoflop schaltest, hast du im Endeffekt einen Watchdog. Hier wird das genauer erklärt.
-
Moin André,
Sind die Werte 0 und 1 Rohwerte, die das Bricklet zurück liefert oder hast du da schon durch 100 geteilt um Lux zu bekommen? Falls ja: Ist das Problem einfach, dass du keine float-Division machst, weshalb Rohwerte kleiner 100 eine 0 erzeugen?
Ich habe mal in der Firmware nachgesehen, der zurückgegebene Wert wird auf 1 gesetzt, wenn bei der Berechnung etwas kleineres rauskommen sollte (siehe hier). Das heißt die 0 (als Rohwert) bedeutet wirklich, dass der Sensor saturiert ist (siehe hier). Das sind die einzigen beiden Stellen, an denen der Illuminance-Wert zugewiesen wird.
Gruß,
Erik -
Moin,
Die GUI wird in einem separaten Buffer gezeichnet. Die API des Bricklets hat zur Zeit keine Möglichkeit, den Buffer auszulesen. Ich setze mir mal auf die Liste, dafür eine Funktion einzubauen.
-
Moin,
23 hours ago, StefanOHAN said:Frage: Hast Du in der Doku auch Beispiele & Besonderheiten vorgesehen ? Ich habe keine gesehen.
Beispiele sind eine interessante Frage, das ist nicht unbedingt bei jedem Device nötig, z.B. ein Temperatursensor funktioniert ja einfach so. Ich tendiere im Moment dazu, als Beispiel für jedes Bricklet nur das Grundgerüst, damit man die Actions benutzen kann zu generieren und zusätzlich die etwas komplizierteren Beispiele die teilweise ja hier im Thread schon gewachsen sind zu übernehmen.
Das Remote Switch ist ein schwieriger Fall. Ich muss dem Doku-Generator noch beibringen, mit den speziellen Devices (Den Sockets, aber auch der Wetterstation usw.) umzugehen. Prinzipiell ist die Doku aber korrekt, du kannst mit den Actions direkt schalten ohne eigene Devices anzulegen. Das ist nur schwieriger weil du händisch dafür sorgen musst, dass immer nur ein Schaltvorgang gleichzeitig läuft.
23 hours ago, StefanOHAN said:Auch Hinweise dass man z.B. einem Channel-verlinktem ITEM eines EdgeCount (der verschiedenen Bricklet) ein „REFRESH“ übergeben kann um einen Update der Werte zu erzwingen wäre nicht schlecht.
Bezüglich der REFRESHs: Das sollte eigentlich nicht mehr nötig sein, weil die Channel sich periodisch selbst aktualisieren. Hast du da noch Probleme bei irgendeinem Bricklet? Ich schreibe das trotzdem mal in die Doku, es gibt eventuell Anwendungsfälle, wo man das kontrollieren will, wann der Channel sich aktualisiert.
-
Moin,
Es gibt jetzt einen ersten Prototypen der openHAB-Dokumentation. Erstmal nur auf Englisch und noch ohne die allgemeinen Dinge wie Installationsanleitung, Beispiele usw.
Falls noch device-spezifische Dinge fehlen, oder euch etwas anderes auffällt, bitte melden.
Gruß,
Erik -
Ich meinte damit nur die CPU-Last von Brick Daemon.
Wenn ich mir deinen nmon-Screenshot ansehe, ist dein Problem anscheinend, dass der Arbeitsspeicher voll ist, der Java-Prozess lässt dann die ganze Zeit den Garbage Collector laufen, was die CPU-Last in die Höhe treibt. Du kannst etwas Arbeitsspeicher freiräumen, wenn mit dem Brick Viewer alle Services deaktivierst, die du nicht brauchst, z.B. die graphische Oberfläche, usw.
Du kannst mit der available-Spalte von free -m nachsehen, wie viel Arbeitsspeicher wirklich frei ist. Linux benutzt freien Arbeitsspeicher gerne um Daten zu cachen, wirft die Caches aber weg, wenn der RAM knapp wird, damit Anwendungen ihn benutzen können. Deshalb ist die free-Spalte nicht so aussagekräftig.
-
Moin,
Das ist normal, wenn du einen Stapel auf dem RED-Brick hast. Der RED-Brick hat nur einen CPU-Kern, der ungefähr so schnell ist wie ein Raspberry Pi 1.
-
Moin,
Hast du das Problem mit einem Industrial Dual Analog In 1.0 oder 2.0? Ich habe es hier mit dem 2.0 getestet und es funktioniert so wie es soll. Hast du eventuell beide Channels auf das selbe Item registriert?
-
Moin,
Die Limits, die hier angegeben sind, kannst du mit einem Master Brick über USB erreichen, andere Verbindungen wie Ethernet, Wifi oder auch die HATs schaffen laut meiner ad-hoc-Tests weniger.
-
Moin,
Das Problem tritt anscheinend manchmal bei Perl auf. Teste mal das hier beschriebene Vorgehen mit den bei dir passenden Versionsnummern (also denen, die in /var/cache/apt/archives/ liegen).
Gruß,
Erik
Konfiguration LAN ohne DHCP
in Anfängerfragen und FAQ
Geschrieben
Die Wärmeentwicklung ist erwartet: Die Ethernet-Extension muss von 48 Volt auf 5 Volt Spannungswandeln und der RED-Brick zieht deutlich mehr Strom als der andere Stapel. Außerdem erzeugt er selbst einiges an Abwärme.
Ansonsten bin ich mir noch nicht sicher, was genau das Problem ist.
Stell als erstes mal mit dem Brick Viewer die Systemzeit des RED-Bricks ein: Das geht unter RED Brick->Settings->Date/Time da gibt es den Update Brick to Local Time Button.
Ich habe dir mal ein Testskript gebaut, den Anhang kannst du im Import/Export-Tab des RED-Bricks importieren. Das Programm läuft einmal pro Minute und schreibt in die Log-Dateien des Program-Tabs. Damit du auch wenn das USB-Kabel nicht angeschlossen ist, siehst ob das Programm durchgelaufen ist, habe ich eingebaut, dass es die rote LED des RED-Bricks kontrolliert:
Im Idealfall probierst du zuerst aus, ob das Programm bei dir funktioniert, indem du einen Aufbau baust, bei dem du den anderen Stack erreichst und es dann ausführen lässt. Im Brick Viewer unter RED Brick->Program->Logs sollte dann unter Continuous eine stderr.log und eine stdout.log liegen, die stderr.log sollte nur die Zeit der Ausführung enthalten, die stdout.log hat die Zeit, die Ping-Tests und die IP-Connection-Tests mit jeweils den Enumerate-Ergebnissen (also die Hardware die an dieser IP angeschlossen ist) und falls Thermocouple-Bricklets gefunden wurden deren Zustand.
Teste dann mal bitte folgende Aufbauten:
Folgende Tests dann für jeden der Aufbauten durchführen:
Wenn du das für alle Aufbauten gemacht hast, häng hier mal die Logs an. Die kannst du mit dem Brick Viewer im Programs-Tab des RED-Bricks unter Logs runterladen. Dazu brauche ich dann noch die Zeit->Test-Aufschlüsselung.
Sorry, dass das so ein komplizierter Test ist, aber es ist ja auch ein kompliziertes Problem
thermotester.tfrba