photron

Please try the attched brickv version.

brickv_macos_2_4_25_snapshot_150aa4c.dmg

Sorry, this is a bug in the data logger on macOS. I will provide you a fixed version for testing on monday.

How did you conect the sensor to the Bricklet? You have to connect it to the pin header which expects 3.3V TTL signals. You cannot connect it to the D-Sub 9 connector nor the terminal block, both expect RS232 voltage levels. I think you also need to power the sensor with 3.3V to make it output 3.3V TTL signals.

Try replacing this

test = ''.join(data)

with this

test = [hex(ord(x)) for x in data]

This will give you a list of hex numbers.

Ist dort bereits ein WLAN Netzwerk vorhanden, das du nutzen kannst? Wenn ja, dann kannst du alle WIFI Extensions und deinen Rechner als Clients zu diesem WLAN Netzwerk verbinden und so die Verbindung zwischen dem Rechner und den WIFI Extensions herstellen.

Die Einstellungen sind so okay. Was zeigt den der Status Dialog an, wenn du auf den "Show Status" Knopf klickst? Das sollte in etwa so aussehen. Du musst dann in Brick Viewer als Host eingeben, was dort bei IP steht.

Hi, wenn ich dich richtig versteht, dann willst du das so bauen:

Laptop ---[USB]--- Master Brick --- WIFI Extension (Access Point) --- [WLAN] --- WIFI Extension (Client) --- Master Brick --- Industrial Dual Relay Bricklet

Das ist so nicht gedacht, daher funktioniert es so nicht.

Du kannst den ganzen Stapel am Laptop weglassen, den Stapel mit dem Industrial Dual Relay Bricklet dran als WLAN Access Point konfigurieren und dich dann direkt vom Labtop aus mit diesem Access Point verbinden. Im Brick Viewer verbindest du dich dann nicht mit localhost sondern mit 192.168.42.1:

Laptop --- [WLAN] --- WIFI Extension (Access Point) --- Master Brick --- Industrial Dual Relay Bricklet

Wenn du die Zeit über Tage halten muss, dann kannst du ein Real-Time Clock Bricklet 2.0 nehmen. Das hat eine Batterie anstelle des Super Caps und hälte dadurch viel viel länger.

Allerdings ist das Real-Time Clock Bricklet 2.0 nicht automatisch mit dem RTC System von Linux intergiert. Die Zeit des Real-Time Clock Bricklet 2.0 kannst du über Brick Viewer setzen.

Um die Systemzeit auf die Real-Time Clock Bricklet 2.0 Zeit zu setzen kannst du dieses Skript beim Boot des Raspberry Pis z.B. durch cron oder systemd ausführen lassen.

https://github.com/Tinkerforge/red-brick/blob/master/programs/rtc_time/rtc_time.py

Die RTC auf dem HAT Brick wird von einem Super Cap gestüzt und ist für kurze Unterbrechnung der Stromversorgung gedacht im bereich von Stunden, nicht Tagen.

Sobald du Internet und damit NTP Verbindung hast kümmert sich Linux darum die RTC aktuell zu halten solange das Raspberry Pi läuft.

Mit "sudo hwlock -r" kannst du abrfragen welche Uhrzeit die RTC gerade hat.

Mit "sudo hwclock --systohc" kannst du die RTC von Hand auf die aktuelle Systemzeit setzen. Das macht Linux automatisch alle 11 Minuten.

Mit "sudo hwclock --hctosys" kannst du die Systemzeit von Hand von der RTC laden. Das macht brickd automatisch beim Start des Raspberry Pis.

Genau die Kombination (Master Brick 2.1 Firmware 2.5.2) habe ich hier gerade noch mal getestet und es funktioniert.

Hast du vielleicht ein Kontaktproblem in den oberen Stapelsteckern des Master Brick 2.1?

On 6/22/2023 at 12:13 PM, MBOB said:

Der Reset im Reiter des Viewers beim Materbrick?

oder der Reset-Knopf am Brick?

Das ist der gleiche Reset. Ja, das ist der Reset der gemeint ist.

Hast du auf dem Master Brick die aktuelle Firmware 2.5.2 laufen?

Blinkt/Leuchtet an der RJ45 Buchse die linke/orange LED?

Hast du mal ein anderes Netzwerkkabel probiert?

Ich habe das unter Fedora 37 (Live System) getestet und es verhält sich genau so wie unter Debian. Der Brick im Bootloader taucht als /dev/ttyACM0 auf und gehört root und der Gruppe dialout. Wenn ich den liveuser der Gruppe dialout hinzufüge klappt der Zugriff als User wie erwartet.

Warum fürhst du brickv als root aus? Das sollte nicht notwendig sein.

Ich habe das jetzt in Fedora 37 ausprobiert. Das debhelper Package hat Probleme, dpkg findet es nicht, auch wenn es installiert ist. Zusätzlich ist es dann auch noch kaputt, es fehlt das dh_strip_nondeterminism Skript.

Damit es überhaupt geht hab ich dh_strip_nondeterminism einfach durch einen Symlink erzeugt:

ln -s /usr/bin/true /usr/bin/dh_strip_nondeterminism

Neu im git ist jetzt die --dpkg-no-check-builddeps Option, damit dpkg die Probleme mit dem debhelper Package ignoriert. So kann ich jetzt auf Fedora 37 wieder das Debian Package bauen:

./build_pkg.py --dpkg-no-check-builddeps

Nimm bitte die Änderung zurück, die ich die vorher genannt hatte, update auf den aktuellen git Stand und probier es nochmal aus.

Fedora 37 scheint debhelper 13 zu haben. 

Teste bitte mal diese Änderung, die die Anforderung für debhelper abschwächt als schnelle Lösung:

diff --git a/src/build_data/linux/brickv/debian/control b/src/build_data/linux/brickv/debian/control
index bff8b534..f57ed506 100644
--- a/src/build_data/linux/brickv/debian/control
+++ b/src/build_data/linux/brickv/debian/control
@@ -2,7 +2,7 @@ Source: tinkerforge-brickv
 Section: electronics
 Priority: optional
 Maintainer: Matthias Bolte <matthias@tinkerforge.com>
-Build-Depends: debhelper-compat (= 10)
+Build-Depends: debhelper (>= 10)
 Standards-Version: 4.1.3
 Homepage: https://www.tinkerforge.com/

Firmware: WARP Energy Manager 1.0.5

• Unendlich wachsende Energiebilanz auf der Statusseite im Safari-Browser repariert
• Energiebilanz ohne Höhe in älteren Browsern repariert

Download: WARP Energy Manager 1.0.5

If you only have TX connected then hardware flowcontrol does nothing, as it needs extra pins connected. With software flowcontrol you also need to turn that on on the Arduino side.

Maybe you're sending the data faster than the Bricklet can transfer it or the Arduino can handle it.

What's the baudrate? How big is the data you send? How long does the Arduino take to handle the data?

Maybe simplify your C# program to just do a single write and make sure that works.

Der ESP32 (Ethernet) Brick meldet aktuell keine Fehlerzähler. Brick Viewer geht mit dieser Situation nicht richtig um. Das ist ein reines Anzeigeproblem in Brick Viewer und keine wirklichen Fehler. Das wird mit der nächsten Brick Viewer Version behoben sein.

On 5/9/2023 at 2:51 PM, KevinB said:

vor ca einer Stunde habe ich den ESP32 Ethernet Brick in Betrieb genommen und wollte mit JavaScript vom angeschlossenen Temperatur-Bricklet Daten erhalten.

Mit JavaScript meinst du unsere JavaScript Bindings? Leider werden diese aktuell noch nicht für den ESP32 (Ethernet) Brick unterstüzt. Alle anderen Bindings werden unterstüzt.

https://www.tinkerforge.com/de/doc/Software/Bricklets/TemperatureV2_Bricklet_JavaScript.html

On 5/9/2023 at 2:51 PM, KevinB said:

Also bin ich im Brick Viewer auch mal auf Advanced Functions gegangen, worauf hin sich die Anwendung, bevor ich irgendwas hätte falsch klicken können aufgehängt hat.

Sorry, das ist ein Bug zwischen Brick Viewer und ESP32 (Ethernet) Brick. Das betrifft aber wirklich nur den Advanced Functions Dialog, auf dem es aber nichts zu tun gibt für den ESP32 (Ethernet) Brick. Daher ist das nicht kritisch. Ich habe es das Problem behoben und es wird mit der nächsten Version von ESP32 (Ethernet) Brick Firmware und Brick Viewer behoben sein.

On 5/9/2023 at 2:51 PM, KevinB said:

Es kommt mir so vor, als würde seit dem die WebOberfläche des esp32 Benutzername und Passwort erwarten - habe allerdings nirgends etwas entsprechendes eingestellt.

Ohne das du das eingestellt hast sollte das Webinterface danach nicht verlangen.

On 5/5/2023 at 8:39 AM, Paulkerl said:

Aufrufe mit Command oder Flag liefert:

Configurations file will me moved and updated to new format
Error while moving config file

Hätte auf ein Rechteproblem getippt, das scheints aber nicht zu sein.

Ich habe mal kurz in den Code geguckt. Es sieht für mich so aus also ob in dieser Zeile Code ein Typo ist:

https://github.com/HappyTobi/warp/blob/ac97a5154077a0b2d1b677d160d5385a98f696a5/cmd/root.go#L49

Ich denke, da müsste "filepath.Join(home, ".warp.yaml")" statt "filepath.Join(home, "warp.yaml")" stehen.

Falls du das selbst compilierst, dann kannst du mal testen ob diese Änderung hilft.

Do you have the latest firmware installed on the HAT Brick? You can check with brickv. It should be version 2.0.3. If not please update using brickv. On the HAT Brick tab in brickv in the bottom left you can switch the RTC chip type. Try changing it to the other one and reboot the Raspberry Pi.

Der Kernel meldet EINVAL (ungültiges Argument) für den Versuch den SPI Modus auf SPI_MODE_3|SPI_NO_CS zu konfigurieren.

Ich habe in den Kernel Source Code geschaut und vermute, dass das Rock Pi 4 den SPI_NO_CS Modus nicht unterstüzt.

https://elixir.bootlin.com/linux/v5.10/source/drivers/spi/spi.c#L3342

https://elixir.bootlin.com/linux/v5.10/source/drivers/spi/spi-rockchip.c#L725

https://elixir.bootlin.com/linux/v5.10/source/drivers/spi/spi-bcm2835.c#L1289

Teste mal bitte die angehängt brickd Version. Die versucht jetzt nicht mehr SPI_NO_CS zu setzen. Dadurch bewegt die SPI Hardware-Einheit dann unnötigerweise den Chip-Select-Pin, was aber hoffentlich ins Leere läuft.

brickd_2.4.4+snapshot~889c425_arm64.deb

Du bekommst den spidev Fehler nicht mehr, weil brickd jetzt gar nicht mehr soweit kommt.

2023-03-31 19:40:46.085011 <D> <bricklet.c:546> Found no bricklet.* section in config file

brickd versteht die /etc/brckd.conf Datei nicht mehr.

2023-03-31 19:40:46.068252 <W> <main_linux.c:394> Warning(s) in config file '/etc/brickd.conf', run with --check-config option for details

Führe bitte diesen Befehl in eine Terminal aus und poste die Ausgabe hier.

sudo brickd --check-config

Der Linux Kernel mag nicht wie wir das spidev konfigurieren wollen.

Was hast du genau in die /etc/brickd.conf Datei geschrieben?

Die 32766 wundert mich etwas.

2023-03-27 15:21:03.316473 <I> <bricklet.c:530> Found Bricklet port A (spidev: /dev/spidev32766.0, driver: gpio, name: gpio23, num: 23)

Python verwendet auf Windows CP1252 als Encoding, auf Linux aber UTF-8. Wir entwicklen hier alle auf Linux, daher ist es leider nicht aufgefallen, dass wir nicht an allen Stellen Textdateien explizit als UTF-8 öffnen, sorry. Ich habe das gerade im git Repo repariert.