AskSin Analyzer XS - Der Analyzer als Desktop-App ohne ESP

[HMSteve]

Noch ein paar Gedanken zu App und UI, das mir mit den Balken jetzt sehr gut gefaellt:
- Schoen waere, die RSSI line ausblenden zu koennen, da eher selten gebraucht und beim Beobachten von Paketen doch eher irritierend.
- x-Achsen-Beschriftung habe ich noch nicht durchschaut, im Gegensatz zu meiner Testversion des urspruenglichen Analyzer sind die labels nicht im gleichen Abstand, also bspw mal 10s, mal 15s, mal 20s im gleichen Chart, siehe auch Dein Bild auf github. Resultiert das aus dem krummen Takt der eintreffenden RSSI-Datenpunkte?
- In der Paketliste ist der Pakettyp leer?
- Idee einer node app finde ich toll, die koennte doch sicher neben IOBroker auf dem gleiche Raspi leben? Nur ein ungewoehnlicherer Port als 8081 waere dann gut, damit nichts Gewoehnliches mit dem Analyzer kollidiert.

Viele Gruesse,
Stephan

[Psi]

Hey Steve,
vllt sollte wir uns da mal direkt Kurzschließen über irgend nen Messenger.

Die Node-App wird bereits gebaut und du kannst sie natürlich auf dem Raspi (oder sonst wo) laufen lassen; Port kannst du über die EnvVar PORT festlegen (Bind Iface aktuell aber noch nicht). Anzumerken ist hier aber vor allem: Es werden Serverseitig noch keine Daten gespeichert. Machst du die UI auf geht es immer bei "jetzt" los. Wie eine wirkliche Langzeitspeicherung hübsch gelöst wird ist mir noch nicht ganz klar weshalb ich das erst mal hintenan stellen würde.
Ich bin auch nach wie vor wirklich unschlüssig ob man Langzeitdaten überhaupt braucht. Man nutzt den Analyzer doch um gewissen Dinge zu debuggen und nicht um zu schauen ob vor nem Monat der Fensterkontakt was geschickt hat??
Also vielleicht können wir hier (wie in der UI) eine grenze von XX Telegrammen definieren die "gepuffert" (in Memory?) werden.

[jp112sdl]

Ich bin auch nach wie vor wirklich unschlüssig ob man Langzeitdaten überhaupt braucht.

Ich nutze den Analyzer ausschließlich um rückwirkend zu schauen.
z.B. ein Aktor löste nicht wie gewohnt aus Analyzer-WebUI aufrufen, gucken ob überhaupt ein Telegramm gesendet wurde.

Öfter schaue ich nach, wenn bei Geräten sporadisch eine "Komm.-Störung" erscheint, um rückwirkend nachzusehen, ob Telegramme regelmäßig kommen oder ausfallen, ob die Telegrammcounter passen oder die RSSI Werte schwanken.

Ich musste aber auch schon an Daten von vor 4 Wochen, was dank der CSV fix möglich war.

Niemals nutze ich den Analyzer, um Daten "ab jetzt" zu sehen.
Bei Basteln sehe ich die wichtigsten Infos (auch anderere Geräte) im seriellen Monitor. Oder im rfd-Log. Oder mit "hmsniff" auf der Mac-Konsole.

[Psi]

Spontane Idee zur Platine: Ein Neopixel was den RSSI-Noise Level visualisiert? Dann könnte man das Ding auch mal schnell an ne Powerbank hängen und durchs Haus laufen.

[jp112sdl]

Gute Idee.Ist die Frage, mit wie vielen Pixeln und in welcher Auflösung man einen Bereich von ~ -120...-20 dBm als LED-Band darstellen könnte.

[Psi]

Hast du damit Erfahrung? Kannst du sagen ab welchem Bereich das rauschen interessant wird? Vorher könnte man den Pixel (oder die?) ja auch komplett aus lassen

[jp112sdl]

Wenn ich einen Dauersender hab, brauch ich den gesamten Bereich recht detailliert, um zu sehen ob ich auf den Störer zugehe oder nicht.
Es ist ja nicht so, dass die RSSI Werte bei 5 Schritten vor oder zurück gleich riesen Sprünge machen.

[der-pw]

Was spricht gegen ein SPI OLED?
Könnte man den Wert tatsächlich drauf abbilden.
DIe 0.91" Variante ist auch schön klein.

[Psi]

Was spricht gegen ein SPI OLED?
Könnte man den Wert tatsächlich drauf abbilden.
DIe 0.91" Variante ist auch schön klein.

Kosten und vor allem doch recht groß für nen USB-Stick.
Ich vermute um nen Bösewicht zu finden reicht n Pixel der den problematischen Wertebereich darstellt. +-10dB ist hier wahrscheinlich egal.

[der-pw]

Meinte natürlich I2C.

Kosten = unter 2€
Das 0.91"er ist auch recht schlank.