Betaversion Brick Viewer mit PyQt5 und Python 3

photron · February 20, 2019 at 15:48

Wir haben die Grundlagen von Brick Viewer modernisiert. Brick Viewer Version 2.4.0 basiert jetzt auf PyQt5 und Python 3, statt auf PyQt4 und Python 2.

Die aktuelle Betaversion für Linux, Windows und macOS gibt es hier:

http://download.tinkerforge.com/tools/brickv_pyqt5/beta2/linux/brickv-2.4.0_all.deb

http://download.tinkerforge.com/tools/brickv_pyqt5/beta2/windows/brickv_windows_2_4_0.exe

http://download.tinkerforge.com/tools/brickv_pyqt5/beta2/macos/brickv_macos_2_4_0.dmg

Bitte testet die neue Version und meldet uns Probleme, wenn ihr welche findet.

Update (26.02.2019):

Beta2 ist jetzt verfügbar mit folgenden Änderungen:

Dialoge wurden fälschlicherweise als Toplevel-Fenster angezeigt, dies ist korrigiert.
Checkbox hinzugefügt um den Fusion GUI Style zu (de-)aktivieren. Auf macOS ist dieser standardmäßig aktive um scrollbare Tableisten und ein insgesamt kompakteres GUI Layout zu erhalten.
RED Brick Server Room Monitoring: PTC Bricklet Wire Mode Einstellung und Nagios E-Mail Konfiguration werden korrekt ausgelesen.

theo · February 20, 2019 at 17:57

Hallo photron,

ein Problem, dass schon der bisherige Brick Viewer hatte, ist der einreihige Tabreiter. Bei vielen Bricklets kann man nichts mehr erkennen (siehe Anhang).

Die NFC/RFID Bricklet View fängt das "flackern" an sobald ich mein Typ 2 Tag auflege und Scan drücke. Die Load steigt auf 100% CPU.

Sonst sieht es gut aus.

Gruß,

Theo

Loetkolben · February 20, 2019 at 18:27

Hallo photon,

kann man die beiden debian Pakete parallel installieren oder zerschiesst sich da was?

Der Loetkolben

photron · February 20, 2019 at 20:10

theo, das Problem mit der Tableiste ist das Qt da den macOS Style nachbildet und da keine scrollen einer Tableiste vorgesehen ist. Solange wir da eine Tableiste haben wird das unter macOS leider so sein. Du kannst mal brickv mit einem anderen Style starten, der eine scrollbare Tableiste hat. Das geht über einen Terminal:

/Applications/Brickv.app/Contents/MacOS/brickv -style fusion

Wenn du die Brickv.app nicht im Applications Folder hast dann muss du den Pfad entsprechend anpassen.

Das NFC/RFID Problem schauen wir uns an.

Loetkolben, das ist einfach eine neue Version des brickv Package, das ersetzt dein bisher installiertes brickv Package. Das ist kein anderer brickv, sondern einfach die nächste Version 2.4.0. Brick Viewer auf Basis von PyQt4 und Python 2 wird nicht weiterentwickelt.

theo · February 20, 2019 at 20:59

Das mit dem Fusion Style ist schon mal viel besser, das sollte der Default sein. Optimal wären gestaffelte Tabs.

Loetkolben · February 21, 2019 at 00:04

Och.

Sieht Chick aus. Das Update hat auch problemlos unter Debian 9.8 funktioniert.

Zuerst das Paket von Hand mit "dpkg -i" installiert.

Dann wird gemeckert, dass einige Abhaengigkeiten fehlen. Ein "apt --fix-broken install" behebt das Problem zuverlaessig. Ein anschliessendes "apt-get --purge autoremove" entfernt evtl. nicht mehr benoetigte Pakete der alten Version.

Aufrufen und es sieht wirklich gut aus. Tolle Arbeit!

Funktionen nicht im Detail getestet, aber aus meiner Sicht fehlt da nichts.

Nachtrag: Die Verschachtelte Darstellung (auch schon in der alten Version) der Masterbricks mag ja der internen Logik des Stacks folgen, aber mich irrtiert das jedesmal wenn ich am Stack ein Brick suche. Die Anzeige am Bildschirm sollte dem physischen Aufbau des Stacks folgen.

Der Loetkolben

rtrbt · February 21, 2019 at 12:33

Theo, kannst du das Problem mit dieser Version http://download.tinkerforge.com/tools/brickv_pyqt5/beta1/macos/brickv_macos_2_4_0_theo.dmg reproduzieren und das Log, das in /tmp/brickv_nfc_debug_[Datum].log angelegt wird, hier posten?

Danke,

Erik

Equinox · February 21, 2019 at 16:53

Hallo,

in Bezug auf diesen Thread:

https://www.tinkerunity.org/forum/index.php/topic,4751.0.html:

Das Update der Firmware hat jetzt funktioniert, aber das Air Quality Bricklet wird noch immer an Position "Z" angezeigt.

borg · February 21, 2019 at 17:07

Das Update der Firmware hat jetzt funktioniert, aber das Air Quality Bricklet wird noch immer an Position "Z" angezeigt.

Der Bug dort liegt im Bootloader des Air Quality Bricklets, da kann der Brick Viewer leider nichts gegen machen.

theo · February 21, 2019 at 17:45

Hallo Erik,

das Problem ist reproduzierbar. Den Log habe ich angehängt.

Gruß,

Theo

brickv_nfc_debug.log

theo · February 21, 2019 at 17:50

Hier noch ein Screencast auf dem das NFC/RFID Problem zu sehen ist:

https://m1theo.de/ncloud/index.php/s/GFxnQrgkKgJtqA4

Equinox · February 21, 2019 at 19:10

Hallo,

Das Update der Firmware hat jetzt funktioniert, aber das Air Quality Bricklet wird noch immer an Position "Z" angezeigt.

Der Bug dort liegt im Bootloader des Air Quality Bricklets, da kann der Brick Viewer leider nichts gegen machen.

Auch in der Firmware 2.0.3?

Nach ein paar Connects/Disconnects habe ich festgestellt, dass es manchmal auch korrekt angezeigt wird. Meistens aber an Position "Z".

borg · February 21, 2019 at 19:49

Nach ein paar Connects/Disconnects habe ich festgestellt, dass es manchmal auch korrekt angezeigt wird. Meistens aber an Position "Z".

Ja, da ist ein Stück uninitalisierter Speicher im Bootloader. Wenn dort an einer bestimmten Stelle zufällig 90 drin steht ('Z'), dann wird das beim Enumerate mit zum Master übertragen. Normalerweise setzt der Master Brick den Port in der Nachricht (Das Bricklet weiß gar nicht an welchem Port es angeschlossen ist). Aber bei 'Z' geht er davon aus dass das Air Quality Bricklet an einem Isolator Bricklet angeschlossen ist, da der Port des Isolator Bricklet ist immer 'Z' ist.

Hier ist der Fix im Bootloader dafür: https://github.com/Tinkerforge/brickletboot_xmc/commit/bedbb6a29dbd9d4189506aaa4e45238d37a11285

Und hier ist der Code im Master Brick der das Problem verursacht: https://github.com/Tinkerforge/bricklib/blob/master/bricklet/bricklet_co_mcu.c#L244

Der Bootloader wird allerdings nicht aktualisiert wenn du die Firmware aktualisierst. Der wird nur einmal von uns ganz am Anfang geschrieben.

Da die Bootphase deterministisch ist, passiert das beim Air Quality Bricklet zumindest am Anfang jedes mal, auch wenn die Chance dass das überhaupt passieren kann eigentlich nur 1 zu 256 ist .

Edit: Ha! Jetzt wo ich mir das nochmal in Ruhe angeschaut hab ist die Lösung eigentlich ganz einfach. Die "connected uid" wird von den Bricklets immer als "\0" initialisiert, von einem Isolator Bricklet aber entsprechend auf die UID des Isolator Bricklets gesetzt. D.h. der Check muss einfach

if(gir->position != 'Z' || gir->connected_uid[0] == '\0')

sein. Dann ist das Stück uninitialisierter Speicher wieder kein Problem mehr . Muss ich mir morgen nochmal genau ansehen, aber ich denke das ist die Lösung.

rtrbt · February 22, 2019 at 09:28

Hi Theo,

Hast du noch ein anderes Programm parallel laufen, dass mit dem NFC-RFID-Bricklet kommuniziert? Im Log kommen über das state-changed-Callback Antworten auf Anfragen, die der Brick Viewer nicht abgesetzt haben kann. Das Flackern wird dann dadurch ausgelöst, dass das Bricklet in kurzer Zeit (~10ms) zwei Mal nach der Tag-ID sucht und erst die richtige ID findet und danach einen Fehler zurückgibt.

Hattest du das Problem schon mit dem alten Brick Viewer?

theo · February 22, 2019 at 17:05

Hi Erik,

Ok, das war es. Ich hatte auch schon sowas vermutet und auf meinem Rechner nach laufenden Programmen (openHAB) gesucht und da lief nichts. Jetzt hab ich mit lsof noch nach offenen Verbindungen zum brickd gesucht und gefunden. Da war noch eine openHAB Testinstallation auf einem Pi, die remote am brickd hing :-((

Jetzt funktioniert alles wie es soll.

Sorry für die Umstände.

Gruß,

Theo

rtrbt · February 23, 2019 at 08:34

Kein Problem, hauptsache es funktioniert jetzt.

Gruß,

Erik

photron · February 26, 2019 at 14:15

Beta2 ist verfügbar, siehe ersten Post.

Loetkolben · February 26, 2019 at 16:51

Das Starten auf meinem vServer dauert ein wenig. Ca. 15 Sekunden. Mal abgesehen von kraftvollen Desktop PC wird es wohl auch auf Raspberrys recht lang dauern.

Damit man das Programm nicht aus versehen in der Zeit ein zweites mal startet waere ein sofort erscheinendes Splash Logo evtl. gut?!

Es muss ja nicht gross sein und darf auch per default fehlen. Die Frage ist nur, wie schnell koennte es erscheinen, wenn eben der Rechner recht langsam ist.

Der Loetkolben

photron · February 26, 2019 at 18:15

Loetkolben, ist das jetzt neu mit Brick Viewer 2.4.0 oder war das schon immer so?

Ich würde da eher die Ladezeit verbessern wollen anstatt das mit einem Splash Screen zu kaschieren.

Ich vermute das steckt im Laden der Plugins. Test mal bitte wie es die Startzeit beeinflusst, wenn du das Laden der Plugins deaktivierst. Dazu in dieser Datei:

/usr/share/brickv/plugin_system/plugin_manager.py

Zeile 27 von:

from brickv.plugin_system.plugins import device_classes

auf

device_classes = []

ändern.

Loetkolben · February 26, 2019 at 19:09

Hallo photron,

das liegt nicht wirklich an euch.

Das war bisher auch schon so, aber es war nicht wichtig extra einen Thread dafuer aufzumachen, aber da ihr gerade am Brickviewer am arbeiten seit, dachte ich, dass ich das mal einwerfen koennte.

Es liegt am virtuellem System (vServer). Alle Zeiten von Hand zwei mal gestoppt. Das laden der plugins benoetigt also rund 1/3 Zeit mehr. Da nur das laden vom IO System (Wer weiss was die dahinter haben) so lange dauert, ist das eigentlich keine Baustelle von euch das zu optimieren.

Wenn aber mehrere User und/oder ihr der Meinung seit, da muesste man was aendern, dann faende ich das prima. Wegen mir alleine muss das nicht sein.

Meine Ergebnisse: vServer, Debian 9, 2 GB Ram

# Mit "from brickv.plugin_system.plugins import device_classes"
echo 1 > /proc/sys/vm/drop_caches # Memory Cache leeren
brickv
=> 21 Sekunden
# Beenden und dann neu starten (Kommt wohl aus dem Memory Cache)
brickv
=> 2 Sekunden

# Mit "device_classes = []"
echo 1 > /proc/sys/vm/drop_caches # Memory Cache leeren
brickv
=> 13 Sekunden
# Beenden und dann neu starten (Kommt wohl aus dem Memory Cache)
brickv
=> 1,5 Sekunden

Der Loetkolben

photron · February 27, 2019 at 14:28

Loetkolben, teste mal bitte diese Version. Die beinhaltet jetzt auch die .pyc Dateien. Das sollte die Startzeit verbessern:

http://download.tinkerforge.com/tools/brickv_pyqt5/beta2/linux/brickv-2.4.0_all_loetkolben.deb

Loetkolben · February 27, 2019 at 15:46

Hallo photron,

habe die Spezialversion installiert, einen Vorteil hat sie nicht gebracht.

Dreimal mit leeren Cache (echo 1 > drop_caches) gestartet:

19, 19, 27 Sekunden Startzeit. Woher die 27 Sekunden kommen weiss ich nicht.

Danach aus dem Cache gestartet: 1,5 Sekunden. Zeitmessung erfolgte durch Blick auf die Uhr.

Auch die mitgelieferten *.pyc Dateien haben keinen Vorteil gebracht, da ich davon ausgehe, dass weder die Rechenleistung (python precompile) noch das RAM (Start from Cache) das Problem darstellen. Das IO Subsystem kenne ich bei dem vServer nicht, wird aber hoechstwahrscheinlich ein HDD Raid mit gemeinsamen Zugriff sein.

Habt ihr den Brickviewer mal von einem NAS mit HDD oder einer lokalen HDD (jeweils mit leerem Memory Cache) gestartet, also ohne SSD? Bei den heutigen SSD als C: bzw. root Laufwerk ist IO Latenz ja kaum noch vorhanden.

BTW, meine Meinung/Erfahrung: Ich habe zwei gleiche Rechner (Dell Dualcore ca. 5 Jahre alt) einmal mit einer einfachen SSD und einmal mit einer HDD am laufen. Das starten von Windows ist alles noch halbwegs vergleichbar, aber bei Updates mit vielen kleinen Dateien (VLC, Sicherungspunkt setzen, Datentraegerbereinigung) hat man gerne die 4 bis 10 fache Zeit. Seit dem aufkommen der SSDs hat niemand mehr beim File IO etwas optimiert.

Fuer Heim PC und Laptops mit SSD ist das Problem gegessen, fuer Rechenzentrumsrechner die per SAN/NAS/iSCSI und/oder als Raid angebunden sind ist das Bumerang, bzw. wird durch caching minimiert.

Noch ein Beispiel vom vServer: Softmaker Textmaker: 10 zu 1 Sekunde.

Der Loetkolben

photron · February 27, 2019 at 17:42

Loetkolben, dann hier eine Version mit Splash Screen:

http://download.tinkerforge.com/tools/brickv_pyqt5/beta2/linux/brickv-2.4.0_all_loetkolben_2.deb

Loetkolben · February 27, 2019 at 23:39

Hallo photron,

bin knapp in der Zeit. Tut nicht, da Import fehlt schlaegt. Siehe unten.

Fehler bei mir?

# dpkg -i brickv-2.4.0_all_loetkolben_2.deb
(Lese Datenbank ... 92974 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von brickv-2.4.0_all_loetkolben_2.deb ...
Entpacken von brickv (2.4.0) über (2.4.0) ...
brickv (2.4.0) wird eingerichtet ...
Trigger für gnome-menus (3.13.3-9) werden verarbeitet ...
Trigger für desktop-file-utils (0.23-1) werden verarbeitet ...
Trigger für mime-support (3.60) werden verarbeitet ...

## Alles ok, keine Fehler.

# brickv
Traceback (most recent call last):
  File "/usr/share/brickv/main.py", line 75, in <module>
    from PyQt5 import QtWebEngineWidgets
ImportError: cannot import name 'QtWebEngineWidgets'

## Tut nicht. Google "hochfahren"

# apt-get install python-pyqt5
[...]
The following additional packages will be installed:
  python-sip
Vorgeschlagene Pakete:
  python-pyqt5-dbg
Die folgenden NEUEN Pakete werden installiert:
  python-pyqt5 python-sip
[...}
python-sip (4.18.1+dfsg-2) wird eingerichtet ...
python-pyqt5 (5.7+dfsg-5) wird eingerichtet ...

## Passendes? Paket installiert?

# brickv
Traceback (most recent call last):
  File "/usr/share/brickv/main.py", line 75, in <module>
    from PyQt5 import QtWebEngineWidgets
ImportError: cannot import name 'QtWebEngineWidgets'

## Tut trotzdem nicht.

BTW: Bin heute in Nuernberg unterwegs. Evtl. dauern meine Rueckmeldungen.

Der Loetkolben

photron · February 28, 2019 at 10:58

Loetkolben, das ist ein Bug in der Version, auf deiner Seite ist alles okay. Hier eine korrigierte Version:

http://download.tinkerforge.com/tools/brickv_pyqt5/beta2/linux/brickv-2.4.0_all_loetkolben_3.deb

Anmelden

Betaversion Brick Viewer mit PyQt5 und Python 3

Recommended Posts

photron

theo

Loetkolben

photron

theo

Loetkolben

rtrbt

Equinox

borg

theo

theo

Equinox

borg

rtrbt

theo

rtrbt

photron

Loetkolben

photron

Loetkolben

photron

Loetkolben

photron

Loetkolben

photron

Join the conversation

Umsehen

Aktivitäten