Messages

1

Software, Programmierung und externe Tools / Re: Rust solution for rugged approach

« on: June 19, 2019, 16:22:05 »

Is that what you mean with "hot plugging devices to already powered stacks is not supported"? At least your software supports adding new devices while in operation.

Bricklets without a co-processor won't automatically show up in Brick Viewer while in operation (I tried with some older bricklets).

Not supported in this case means "works in some cases, but not in enough to support it.": The firmware of bricklets with co-processor sends an enumerate when booting and bricks poll their ports with an exponentional decreasing rate, which in conjunction allows hot plugging. But bricks are not able to tell if a bricklet gets disconnected. So if your use case only requires adding co-processor bricklets and never removing them, you could reasonably expect this to work, but as I've said it is not supported.

2

Software, Programmierung und externe Tools / Re: Rust solution for rugged approach

« on: June 19, 2019, 14:14:42 »

Another question came up when using the new version:
What happens with the thread (that was spawned from within the enumerate callback function), when the bricklet cable gets disconnected? One could check for EnumerationType::Disconnected and do some manual clean up work (that's not the problem). But how do I make sure, that the spawned thread (related to the previously connected bricklet) will be joined? Is manual clean up required?

You mean threads spawned in the enumerate callback to handle callbacks of the found devices? If you use the

Code: [Select]

thread::spawn(move || {
    for x in receiver {
        //[...]
    }
}
pattern, then the thread will join, when the corresponding sender is dropped in the IpConnection, e.g. when the IpConnection is dropped. Another way would be to explicitly drop the receiver, but then you can not use the for loop pattern anymore.

In cases without using the enumerate callback function, I guess the spawned thread joins automatically when the callback_receiver object (ConvertingCallbackReceiver) is dropped, which in turn happens after the bricklet object goes out of scope?

Dropping the bricklet does not close callback channels. Instead you have to either drop the IpConnection or the receiver. The device object does not hold any information abount the callback channels.

Background for my question:
I'm trying to develop Rust code that properly responds to changed hardware components while running, so one could achieve Hot Plugging support.

Unfortunately, hot plugging devices to already powered stacks is not supported (for electrical reasons as well as in software). The EnumerationType::Disconnected is only sent, if the Brick Daemon on a PC notices that the USB connection to a stack is lost.

3

Allgemeine Diskussionen / Re: Haltbarkeit microSD-Karte

« on: June 19, 2019, 13:05:29 »

Moin,
Bei manchen Karten wird angegeben, wie viele Daten geschrieben werden können. Wenn du da auf Nummer sicher gehen willst, kaufst du eine für den industriellen Einsatz geeignete Karte, die haben dann Datenblätter wie dieses hier (keine Werbung, das war das erstbeste Suchergebnis) Die Karte hält laut Datenblatt 600TB aus (unter Terabytes Written (Max.)). D.h. du kannst zwei Jahre lang pro Minute mehrere Hundert Megabyte schreiben, falls meine Schätzung stimmt.

Du kannst natürlich immer Pech haben und eine Karte erwischen, die nach zwei Monaten hin ist, aber das Risiko hat man ja immer.

Erik

4

Software, Programmierung und externe Tools / Re: Rust solution for rugged approach

« on: June 18, 2019, 14:29:02 »

Hi,
You've found a design mistake in the bindings. The IpConnectionRequestSender has the purpose to allow multi-threaded calling of IpConnection functions and device creation, but for some reason I've forgot to accept the RequestSender in the [device]::new functions.

The attached version (which will probably be released as 2.0.11 soon) fixes this. With this version everything you can do with an IpConnection should also be possible with the RequestSender, that can be cloned for as many threads as needed. Also attached is an example, that shows how to use the RequestSender in an enumerate callback handler.

To use the local version of the bindings, extract the src folder and Cargo.toml into a tinkerforge folder inside your project's src folder, remove the tinkerforge=... line in your Cargo.toml and add

Code: [Select]

[dependencies.tinkerforge]
path = "src/tinkerforge"
instead.

Erik

5

Anfängerfragen und FAQ / Re: Bei Update Fehler:kein Internet

« on: June 17, 2019, 17:04:10 »

Vermutlich ist die Netzwerkfirewall da zu aggressiv: Die Requests die der Brick Viewer sendet, sehen nicht aus, als kämen sie von einem Browser. Deshalb werden die wohl blockiert.

Als work-around kannst du die Firmwares von Hand runterladen und im Flashing-Fenster per Custom flashen.

6

Anfängerfragen und FAQ / Re: Bei Update Fehler:kein Internet

« on: June 17, 2019, 10:20:34 »

Moin,
Sieh mal nach, ob die Firewall von Windows den Brick Viewer blockiert hat.

Mit dem Explorer komm ich aber problemlos drauf.

heißt, du kommst mit einem Browser auf http://download.tinkerforge.com/ ?

Erik

7

Anfängerfragen und FAQ / Re: tinkerforge und Python

« on: June 14, 2019, 10:44:51 »

Wenn ich nochmal darüber nachdenke: Das Verhalten, was du siehst, ließe sich erklären, wenn du bei beiden Beispielen statt der UID des jeweiligen Bricklets die des Master Bricks eingetragen hast.

8

Anfängerfragen und FAQ / Re: tinkerforge und Python

« on: June 14, 2019, 09:14:25 »

Moin,
hast du daran gedacht, die UIDs in den Beispielen zu ändern? Das übersieht man gerne. Die Logs kannst du mal anhängen, eventuell findet sich da ja was.

Erik

9

Anfängerfragen und FAQ / Re: Red Brick suspend mit rtcwake / Alternativen

« on: June 06, 2019, 12:08:45 »

Suspend kann zwar der Linux-Kernel, aber auf dem RED-Brick funktioniert er hardwareseitig nicht.

Du könntest dir mit einem per USB angeschlossenen Master-Brick und einem Relay-Bricklet etwas basteln, das hat aber folgende Nachteile:

• Das Timing wird sehr ungenau (im Bereich von einer Minute pro Stunde, das hängt vom Quartz auf dem Master Brick ab).
• Der Master Brick braucht eine Stromversorgung, da brauchst du entweder eine Step-Down-Power-Supply oder musst dir ein USB-Kabel zurecht bauen.
• Der RED-Brick würde sich selbst die Stromversorgung (sofort) wegnehmen, also kann das Linux nicht sauber herunterfahren.

Hängt also von deinem Einsatzzweck ab, ob das sinnvoll ist.

Bei den Relaymodulen von Amazon musst du mal sehen, ob du mit dem Timing hinkommst. Das erste scheint auf maximal 999 Minuten (16 Stunden 39 Minuten) konfigurierbar zu sein.

10

Anfängerfragen und FAQ / Re: Probleme Callback MQTT

« on: June 06, 2019, 11:19:11 »

Code: [Select]

Payload was: b'{"register": true}'
Steht das b für Byte oder ist das Bestandteil des Payloads?

Das b steht für Byte. Dass der Payload an der Stelle des Codes noch (nicht dekodierte) Bytes sind, ist ein Bug in den Bindings. Ich habe mal eine Version mit Bugfix angehangen.

Ich hatte in der Mosquitto-Doku übrigens schon vor meinem ersten Posting geschaut, inwiefern man beeinflussen kann, ob String oder Byte als Datentyp verwendet wird, aber nichts dazu gefunden. Weiß diesbezüglich jemand was?

Du kannst mosquitto_pub mit -s beliebige Dinge auf der Standardeingabe füttern, die Bindings verstehen aber nur UTF-8 kodiertes JSON.

Bei Node-Red habe ich sowohl String als auch JSON als Payload-Typ ausprobiert. Auch hier wird die Payload vom Binding, wie oben, mit dem vorangestellten b angegeben.

Das sollte auch an dem Bug in den Bindings liegen.

11

Anfängerfragen und FAQ / Re: Probleme Callback MQTT

« on: June 05, 2019, 16:34:49 »

Moin,
Das scheint ein seltsames Problem zu sein. Wenn ich die Befehle copy-paste und die UID anpasse, funktioniert es bei mir. Du kannst mal versuchen, die Bindings mit --debug --show-payload starten. Dann sollte in der Fehlermeldung die du bekommst hinten der Payload stehen, wie ihn die Bindings empfangen haben.

Erik

12

Software, Programmierung und externe Tools / Re: Stabiler Ansatz mit C-Bindings

« on: June 04, 2019, 17:13:29 »

Habe dir nochmal eine neue Firmware angehangen, da war noch ein Rundungsfehler in dem Fall den du getroffen hattest, der u.U. dazu führt, dass doch zwei Callbacks (das erste eins größer als das zweite) zugestellt werden. Die angehangene Firmware ist identisch zur offiziellen 2.0.3.

13

Software, Programmierung und externe Tools / Re: Stabiler Ansatz mit C-Bindings

« on: June 04, 2019, 15:08:44 »

Moin,

Frage 1: Beim IPCON_ENUMERATION_TYPE_DISCONNECTED wird dem Callback zwar die uid des nicht mehr vorhandenen RotaryPoti übergeben, aber nicht der device_identifier, der immer 0 ist.

Warum?

Dass nur UID (und enumeration type) gültig sind, liegt daran, dass der Brick Daemon nur diese Werte zwischenspeichert, um sie mit dem Callback rauszugeben. Das ist absichtlich so, da es Fälle gibt, wo nicht mehr Informationen verfügbar sind.

Frage 2: Warum wird mein Callback doppelt aufgerufen? Und dann auch noch beim ersten Mal mit einem ungültigen Poti-Wert 150?

Das war in der Firmware kaputt. Das Problem ist, dass dein Programm, weil in C, so schnell ist, dass das Callback schon registriert und aktiviert ist, wenn der erste Wert abgefragt wird. Weil die Firmware da die Reihenfolge falsch hatte, wurde erst der (geglättete) Positionswert aus nicht vorhandenen Daten berechnet und danach der erste echte Wert vom Poti gelesen. Teste mal bitte die angehangene Firmware, die löst das Problem bei mir.

Erik

14

Hardware / Re: "FEAr" auf Segment Display

« on: May 27, 2019, 10:32:34 »

Klingt gruselig
Hast du eventuell ein anderes Programm laufen, dass die Segmente setzt? Das kannst du am einfachsten testen, indem du mit dem Brick Viewer die UID des Bricklets änderst. Andere Programme sollten dann ins Leere laufen, falls sie die UID hardgecoded haben.

Alternativ könnte auch ein Programm laufen, dass die falsche UID verwendet und deshalb seine Nachrichten an das Segment Display schickt, statt an das richtige Bricklet.

Erik

15

Software, Programmierung und externe Tools / Re: "Remote Switch Bricklet 2.0" und "ELRO Home Easy - HE872"

« on: May 24, 2019, 10:54:21 »

Ich habe mir gerade nochmal das Timing angesehen. Wie lange musst du beim Anlernen warten, vom Switch On senden bis die LED aufhört zu blinken? Die sollte, wenn es klappt, fast sofort aufhören zu leuchten und dann konstant an sein. Falls die Fassung nichts empfängt, hört sie 20 Sekunden nach dem Knopfdruck auf zu blinken.

Ich vermute aber, weil du ja andere Dinge mit dem Bricklet steuern kannst, dass die Fassung hin ist.

Hast du eine Fernbedienung oder irgendetwas anderes mit dem du die Fassung testen kannst?

Wegen anderen Lampenfassungen kann ich dich nur auf die Kompatiblitätsliste verweisen. Da ist aber leider nicht aufgelistet, welche als Switch und welche als Dimmer arbeiten.