rtrbt
-
Content Count
599 -
Joined
-
Last visited
-
Days Won
23
Posts posted by rtrbt
-
-
Aus dem Log sehe ich folgendes: Dein Programm startet sehr schnell nachdem Brick Daemon und RED Brick API Daemon gestartet sind (das ist die Zeile mit "Added new client (N: 127.0.0.1..."). Der Brick Daemon resettet anscheinend erst danach den Master Brick, weshalb dieser "vergisst" dass die Bricklets angeschlossen sind und an allen Ports neu anfragt. Das Rotary Encoder Bricklet meldet sich dann ("Received enumerate-connected callback (uid: KcD)") was der Brick Daemon als "Das Bricklet wurde neu angesteckt, ich werfe alle alten Anfragen weg weil die jetzt keinen Sinn mehr ergeben" behandelt. Eine Anfrage (vermutlich die Callback-Konfiguration) wurde dann verworfen.
Mich wundert allerdings, warum du dann trotzdem 0, also keinen Fehler zurückbekommst. Hast du da eventuell einen Bug in der Anzeige auf dem LCD? Mit der Zahl-zu-String-Konvertierung? Du kannst den Rückgabewert, wenn du ihm mit printf ausgibst dann mit dem Brick Viewer sehen:
Wenn du die stdout.log anklickst solltest du die Ausgaben deines Programms sehen können.
Als grundlegende Frage: Behebt sich dein Problem, wenn du in der main (bevor du irgendetwas anderes machst) ein paar Sekunden wartest?
-
Das hängt von den Bindings ab. Bei den Python-Bindings kannst du pro Device und Callback-ID nur ein Callback registrieren. Wenn du die Registrierung mehrfach ausführst, werden die älteren Registrierungen überschrieben.
-
Laut dem Log hat dein händisches Konfigurieren funktioniert. Wenn du das HAT und angeschlossene Bricklets also immer noch nicht erreichst, ist es wohl wirklich ein Schaden am Pi oder HAT. Ich bin gespannt was bei deinem Test mit einem anderen Pi herauskommt.
-
56 minutes ago, MaxMustermann said:
Was nun? Raspberry Pi Interfache defekt?
Vermutlich. Wenn das HAT konstant blau leuchtet hat es eine funktionierende Firmware. Das heißt wir haben es hier geflasht und getestet und es hat zumindest vor dem Versand funktioniert. Ich halte einen Transportschaden für eher unwahrscheinlich. Falls du entweder ein anderes HAT (muss keins von uns sein) zur Hand hast oder alternativ noch einen Pi (mit der selben Speicherkarte) könnte man das entgültig testen.
Eine Alternative kannst du noch testen: Du kannst den laufenden Brick Daemon mit
sudo systemctl stop brickdanhalten und danach händisch mit Debugausgabe in der Konsole starten:
sudo brickd --debugEventuell bekommen wir da noch ein paar Informationen.
-
Hm das klingt als ob der Pi das HAT überhaupt nicht findet. Was macht die Status-LED des HATs (ganz rechts etwas unter der Mitte)? Eventuell steckt dein HAT im Bootloader-Modus fest, dann blinkt die Status-LED.
Du kannst auf jeden Fall mal folgendes testen: Aktiviere mit sudo raspi-config das SPI-Interface (unter Interfacing Options -> SPI -> Ja). Danach kannst du die HAT-Pins händisch konfigurieren, wie das in der HAT-Dokumentation steht (den ganzen Block einfach ans Ende von /etc/brickd.conf packen). Danach (mit HAT) neustarten. Du solltest dann zwar immer noch nicht /proc/device-tree/hat/ haben, aber trotzdem mit dem Brick Viewer das HAT, sowie angeschlossene Bricklets, sehen und flashen können.
-
Moin,
Hänge mal bitte die Rules an mit denen du den Test machst, also die mit der du den Pin setzt und die mit der du auf die ChangeEvents wartest und die (Fehler)-Zähler setzt usw. Dann kann ich das hier mal genauso nachbauen wie du das hast.
Mein Aufbau läuft übrigens immer noch. Der funktioniert aber anders, da ich die IO16s selbst benutze um einen Pin zu setzen.
-
Moin,
Gibt der Aufruf von
rotary_encoder_v2_set_count_callback_configuration([...])einen Fehlercode (also etwas anderes als 0) zurück? Gib den am besten mal aus und sieh dir hinterher mit dem Brick Viewer das Ausgabe-Log an.
-
Moin,
Du hast vermutlich den Kernel 5.4 laufen (kannst du mit uname -r prüfen). Da gab es Änderungen in der Standardkonfiguration der GPIO-Leiste mit denen das HAT nicht zurechtkommt. Mich wundert es allerdings, dass nicht noch mehr Fehlermeldungen kommen.
Du kannst testweise mal die Brick Daemon-Variante aus diesem Post installieren, die das Problem umgeht. Danach kannst du dich mit dem Brick Viewer zum Pi verbinden und die HAT-Firmware auf 2.0.2 aktualisieren, danach sollte es auch mit der normalen Brick Daemon-Version funktionieren.
Falls das nicht hilft, melde dich nochmal, dann hast du ein anderes Problem.
Gruß,
Erik -
Moin,
Die Callbacks werden intern den Devices zugeordnet. Du kannst also z.B. folgendes machen:
def cb_1(channel, changed, value): print("1") def cb_2(channel, changed, value): print("2") io = BrickletIO16V2("UID1", ipcon) io2 = BrickletIO16V2("UID2", ipcon) io.register_callback(io.CALLBACK_INPUT_VALUE, cb_1) io2.register_callback(io.CALLBACK_INPUT_VALUE, cb_2)
Dann wird dir eine 1 ausgegeben, wenn das erste IO-Bricklet das Callback ausgelöst hat, und eine 2 wenn es das zweite war.
Du kannst dann noch cleverer sein und dir bei der Registrierung des Callbacks mitgeben, welches Device das ist, indem du einen Lambda-Ausdruck benutzt, z.b. so:
def cb(device, channel, changed, value): print("Ich bin {}".format(device)) print(channel, changed, value) io = BrickletIO16V2("UID1", ipcon) io2 = BrickletIO16V2("UID2", ipcon) io.register_callback(io.CALLBACK_INPUT_VALUE, lambda *args: cb("UID1", *args)) io2.register_callback(io.CALLBACK_INPUT_VALUE, lambda *args: cb("UID2", *args))
Das ganze kannst du soweit führen, dass du dir statt der UID gleich das Device-Objekt in das Callback reingibst, falls du direkt mit dem Bricklet etwas machen willst (z.B. wenn Pin 1 sich ändert Pin 2 auch ändern o.Ä.)
-
Hi,
I'm currently still occupied with other projects, but the openHAB binding development will continue sooner or later. As per the feedback in the german thread, I will probably target openHAB 3 for the "finished" release of the bindings.
-
Moin,
On 10/23/2020 at 11:07 PM, Tracker said:Wenn ich das richtige Kennwort eingebe, wie kann ich das dann speichern? Das habe ich sicher vergessen.
Du kannst nicht explizit die Verbindungsdaten speichern, das wird nur gemacht, wenn du Connect klickst. Das geht bei dir aber nicht, weil der RED-Brick kein angeschlossenes Modem detektiert. Du hast da ja vermutlich gerade einen WLAN-Stick angeschlossen. Du musst dich also vermutlich mal per Mini-USB mit dem RED-Brick verbinden, den 3G-Stick anschließen und dann die Konfiguration machen.
-
Moin,
Das ist mehr oder weniger normal. Der Brick Daemon pollt alle Anschlüsse (mit fallender Frequenz) selbst wenn nichts angeschlossen ist, damit er es mitbekommt, wenn du eben doch etwas anschließt.
Mit der nächsten Brick Daemon-Version wechseln wir für den Raspberry Pi aber vermutlich das Backend, was zu einer niedrigeren CPU-Last führen sollte. Den Effekt wirst du dann trotzdem, wenn auch schwächer, sehen.
Edit:
Wenn du Bricklets angeschlossen hast, die keine großen Performanceanforderungen haben (also z.b. ein Barometer Bricklet im Gegensatz zum Thermal Imaging Bricklet), kannst du in /etc/brickd.conf die Zeit zwischen den Polling-Vorgängen erhöhen. Dafür musst du die folgenden Einträge hinzufügen oder verändern:
bricklet.portA.sleep_between_reads = 200 bricklet.portB.sleep_between_reads = 200 [usw bis portH] bricklet.portHAT.sleep_between_reads = 200200 heißt dabei, dass der entsprechende Port alle 200µs auf ein neues Datenpaket gepollt wird. Du kannst damit experimentieren, es ist aber möglich, dass du dir die Performance der Bricklets deutlich verschlechterst, wenn du die Zeiten zu hoch stellst.
-
Da sehe ich spontan nicht was das Problem ist, hier ein paar Gedanken dazu:
Du hast vermutlich kein WiFi-Problem zwischen dem Stapel und openHAB/Brick Viewer: Das Bricklet zählt den "Last Change" selbst mit, d.h. wenn die 12403 Sekunden sich sekündlich aktualisieren kommst du ohne Probleme zum Bricklet. (Übrigens: Siehst du im Brick Viewer Timeouts oder funktioniert das auch alles wie es soll?)
3 hours ago, KlausGünther said:Aber von Zeit zu Zeit stieg irgendwie der Windmesser mal aus, also die Daten kamen nicht mehr im Bricklet an (Weder im openHAB noch im Brick Viewer auf Windows).
Das ist mir abgesehen von einem Hardware-Defekt absolut unklar wie das passieren kann. Eigentlich solltest du nicht "halbe Pakete" oder so empfangen können.
3 hours ago, KlausGünther said:Das beide Sender mehr oder weniger gleichzeitig den zuverlässigen Betrieb einstellen, halte ich irgendwie auch für unwahrscheinlich.
Hast du eventuell etwas anderes in der Nähe, das das Frequenzband stört? Das ist natürlich der schwierigste Punkt um ihn herauszufinden, das kannst du vermutlich am einfachsten testen, indem du das Outdoor Weather Bricklet direkt neben den Sensor legst oder andersrum.
-
Moin,
Die Presets bekommen wir von diesem Projekt. Da gibt es immer mal Änderungen, die sind aber außerhalb unserer Kontrolle. Das sind aber, wie der Name schon sagt, Presets. Du kannst also auch die notwendigen Informationen von Hand eintragen, danach sollte es gehen. Fragen dazu:
- Wie heißt der Provider genau? Entweder bin ich unfähig zu suchen oder "Simply" gab es so nie in der Liste.
- Bei welcher Version gab es Simply in der Liste noch? Wenn du den Brick Viewer wieder auf diese Version down-gradest, funktioniert es dann?
- Funktioniert es, wenn du die Provider-Informationen von Hand einträgst oder ist das prinzipiell kaputt?
Gruß,
Erik -
Moin,
16 hours ago, wehnerc said:Wie es scheint hab ich keine dedizierte GPU
Das scheint zu stimmen. Deshalb bekommst du da auch keinen Unterschied, macOS hat ja jeweils nur eine Option wie der Brick Viewer gerendert werden kann.
-
Moin,
Das sieht von außen nicht openHAB-spezifisch aus. Passiert das auch, wenn du (je nachdem was einfacher ist) das Bricklet aus openHAB entfernst und oder openHAB kurz runterfährst, dann das Bricklet neustartest und mit dem Brick Viewer nachsiehst? Das würde das Debugging schonmal immens erleichtern, wenn es kein openHAB-Problem ist ;)
-
Moin,
Wir suchen einen oder mehrere Freiwillige, die die angehangene Brick Viewer-Version auf einen Mac testen können, der sowohl einen in die CPU integrierten Graphikchip, als auch einen dedizierten Graphikchip hat.
Hintergrund ist, dass das normale Verhalten von Qt-Programmen scheinbar ist, dass sie immer auf dem dedizierten Chip gerendert werden, was den Energieverbrauch erhöht. Ich habe deshalb eine Version des Brick Viewers gebaut, die macOS mitteilt, das sie auch auf dem integrierten Chip laufen kann.
Wir haben leider weder in der Firma noch privat Macs mit dediziertem Chip, was das Testen erschwert.
Mich würden folgende Dinge interessieren:
- Was zeigt der Energietab der Aktivitätsanzeige an, wenn die "normale" Brick Viewer-Version 2.4.14 läuft? Meine Erwartungshaltung wäre "Graphics Card: High Perf.". (Siehe die Screenshots im unten verlinkten Issue)
- Wenn jetzt stattdessen die angehangene Brick Viewer-Version verwendet wird, wird dann stattdessen "Graphics Card: Integrated" angezeigt?
Damit der Test sinnvoll ist muss aber "Integrated" bereits angezeigt werden, wenn keine Version des Brick Viewers läuft. Ansonsten hat ein anderes Programm den Wechsel auf "High Perf." ausgelöst.
Weitere Details finden sich in diesem Issue auf Github.
Gruß und danke für's testen!
Erik -
Moin,
Interpretiere ich den Graphen richtig, dass sich die Kommunikation mit dem Bricklet nicht mehr komplett aufhängt? Wenn du jede Minute den Pin änderst müsste ja ansonsten der FailureCounter ab diesem Punkt jede Minute um eins wachsen. Es sind aber in beiden Graphen Zeitabschnitte deutlich größer eine Minute bis der Zähler weiter hochspringt.
-
Moin,
Bei dir passieren zwei Dinge:
1. Können die Bindings nicht das Distance US Bricklet mit der UID 123 finden. Hast du da eventuell einfach die falsche UID? Sieh am besten mal mit dem Brick Viewer nach.
2. Wird genau dieser Fehler falsch behandelt, deshalb die komische Ausgabe. Eigentlich sollte da der übliche Timeout ausgegeben werden.Das erste Problem musst du auf deiner Seite fixen, das zweite sollte mit der Version im Anhang repariert sein.
Gruß,
Erik -
22 hours ago, cuky3 said:
The ipcon.Disconnect(); only works if it is in public void Prikupljanje() or public void AccelerationCB(BrickletAccelerometerV2 sender, short[] acceleration), outside of these two methods I always get NotConnectedException.
This is really strange. To find out when the IPConnection is disconnected, you can use the DisconnectedCallback, for example like this:
static void DisconnectedCB(IPConnection sender, short disconnectReason) { Debug.WriteLine(string.format("Disconnected at {}; reason: {}", DateTime.Now, disconnectReason)); }Then register the callback with
ipcon.DisconnectedCallback += DisconnectedCB;in the Start_Click function.
If you also add similar debug logging to the other functions, you should be able to see when the disconnect happens.
-
Sorry für die späte Antwort, war im Urlaub.
On 10/4/2020 at 9:32 AM, KlausGünther said:Können wir Dich bis dahin noch irgendwie unterstützen ?
Im Moment nur durch Bug-Reports. Ich bin leider immer noch mit anderen Projekten beschäftigt.
On 10/4/2020 at 2:01 PM, roben said:Oh man, danke für diesen Hinweis! Ich habe meinen Garagentorsensor seit der Umstellung auf OH2.5 / Beta-Binding nicht mehr an Laufen bekommen und es lag einfach nur daran, dass ich vom alten Binding noch "Contact" stehen hatte. DAS wäre definitiv noch ein guter Punk für die Doku, zumindest zum Umstieg vom alten Binding.
Wenn du jetzt auf Switch umstellst, musst du aber daran denken, eventuell in ein paar Monaten wieder auf Contact zu wechseln. Langfristig werden reine Inputs wieder Contacts sein.
On 10/5/2020 at 7:56 AM, StefanOHAN said:Als ich dann über den Brickviewer das Bricklet zurück setzte, funktionierte alles wieder und die Steckdose schaltete sich mehrfach ein und aus, als ob alle "aufgestauten" KDO für die Steckdose von Bricklet abgearbeitet wurden. Nach dem Reset sah ich im Log auch wieder Meldungen wenn ich die Fernbedienung betätigte.
Frage kann es sein dass sich hier das Bricklet selber aufgehängt hat ?
Hm da hast du einen interessanten Bug getroffen. Anscheinend passiert folgendes: Ich habe ja die Remote Switch Bricklets von Hand implementiert, damit sie Bridges sind für die Funksteckdosen usw. Ich habe da eine Warteschlange von Tasks (z.b. Schalte die Dose xyz), eine Funktion die die Tasks abarbeitet und eine Variable über die ich mir merke, ob das Bricklet gerade schaltet (Die Funktion darf dann keinen neuen Schaltvorgang auslösen, wenn die Variable gesetzt ist). Diese Variable wird über das isSwitchingDone-Callback des Bricklets zurückgesetzt.
Du hattest da jetzt anscheinend das Pech, dass das Callback verloren gegangen ist, also die Variable nie zurückgesetzt wird und deshalb keine Tasks mehr abgearbeitet werden. Der Reset über den Brick Viewer führt dazu, dass openHAB das Device neu initialisiert, da wird auch die Variable zurückgesetzt, die Warteschlange aber nicht geleert, deshalb die aufgestauten Schaltvorgänge.
Ich baue mal einen Fix dafür, indem ich einfach ~alle 2 Sekunden explizit den Schaltzustand des Bricklets abfrage und darüber die Variable zurücksetze, falls es fertig ist. Dann kann dieses Problem nicht mehr auftreten.
Der Aufbau von oben lief bei mir seit dem 2.10. durch und die LEDs blinken noch. Falls sich das ganze doch aufhängt melde ich mich nochmal.
-
This is strange: This exception is only thrown if your IPConnection was not connected. However I don't see how you can reach the Timer1_Tick without first calling connect in your "Prikupljanje" function.
1 hour ago, cuky3 said:And if I remove ipcon.Disconnect() completely the values in Debug.WriteLine(string.Join(",", x)); just keep on coming and my text area is still empty.
This is because if you never call .Disconnect(), you will still receive callbacks.
If you use the following implementation of Timer1_Tick
public void Timer1_Tick(object sender, EventArgs e) { Timer1.Enabled = false; Debug.WriteLine("Timer1_Tick"); }Do you get the "Timer1_Tick" output only once? If not, your single-shot logic does not work.
Some other things: You should switch the order of the following lines:
Timer1.Enabled = true; Timer1.Interval = t2;If you enable the Timer before setting the interval, it is possible, that the timer runs with the wrong pre-configured interval first.
A similar problem is with these lines:
a.SetContinuousAccelerationConfiguration(true, true, true, Convert.ToByte(1)); a.ContinuousAcceleration16BitCallback += AccelerationCB;If you first register the callback and then call the Set...Configuration function to enable the callback, you don't miss any callback packets.
-
Hi,
After registering the callback, you are calling ipcon.Disconnect(), but if you disconnect from the Ethernet Extension, no callbacks can be delivered. Removing this line should fix your problem.
Closing the connection is still a good idea, but I think you do this (i.e. call ipcon.Disconnect()) in the Timer1_Tick handler.
-
2 hours ago, StefanOHAN said:
Du hast mir ja die spezial-Version wegen meines Recconect Problem der 2-Dämon's bereitgestellt. Baust Du diese Korrektur noch in das 2.5 Binding ein (oder erst in die 3) ?
Der Fix sollte automatisch in der nächsten Beta landen, er ist schon im Repository.
2 hours ago, StefanOHAN said:Planst Du auch noch das Thema der IO-Brickets die als Input konfiguriert sind wieder als "Contact" und nicht mehr als Switch in das 2.5-Binding einzubauen bevor Du dann nach 3.x umstellst ?
Das ist ein interessanter Punkt über den ich so noch nicht nachgedacht hatte. Das hängt ja daran, dass ich nochmal alle (Generator-)Konfigurationen durchgehe und die deutsche Doku schreibe usw. Das heißt es ist vermutlich sinnvoll, wenn ich den Wechsel auf openHAB-3-Only möglichst spät mache, damit möglichst viel was noch auf meiner Liste steht es in eine 2.5er Beta schafft. Werde ich auf jeden Fall berücksichtigen.
C/C++-Programm auf RED-Brick reagiert nicht auf Rotary Encoder 2.0
in Software, Programmierung und externe Tools
Posted
Das sollte inzwischen gefixt sein, auf dem Download-Server lag eine falsche Test-Datei die dazu führte, dass der Update-Check durcheinander kam.
Wie sieht das Farbenspiel genau aus? Mach am besten mal ein Foto. Was passiert wenn du den Desktop siehst und dann den RED-Brick z.B. über Brick Viewer rebootest (dabei aber nicht Display oder RED-Brick vom Strom trennst)?