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

[TomMajor]

Kann man das FW/xml versionsnummer neutral machen

Ja, da muss nix geändert werden.
broadcastEvent aber nur für die Messages mit BCAST.
Die BIDI Messages müssen weiterhin mit sendPeerEvent (oder sendMasterEvent) erfolgen.

Mir ist gestern, nachdem das hier aufgefallen ist, auch noch eine Leiche unter die Finger gekommen ^^

ok, das klingt schon mal gut das man dafür das xml und die Versionierung nicht anfassen muss.
Frage, wir hatten früher mal so was in der Art, die Idee stammte glaub ich von dir:

Code: Alles auswählen

        uint8_t flags = BCAST;
        if ((msgcnt % 20) == 2) {
            flags = BIDI | WKMEUP;
        }

Jetzt setzt du die Flags immer auf BIDI | WKMEUP
https://github.com/jp112sdl/Beispiel_As ... 20.ino#L77

und später verzweigst du so

Code: Alles auswählen

if (msgcnt % 20 == 1) device().sendPeerEvent(msg, *this); else device().broadcastEvent(msg, *this);

D.h. broadcastEvent nimmt die Flags BIDI | WKMEUP wieder weg oder ist das jetzt egal?
Früher war es halt ein entweder oder bei den flags.

[jp112sdl]

D.h. broadcastEvent nimmt die Flags BIDI | WKMEUP wieder weg oder ist das jetzt egal?

Nimmt das BIDI Flag weg, wenn Empfänger die Broadcastadresse ist:
https://github.com/pa-pa/AskSinPP/blob/ ... age.h#L190

WKMEUP kann wohl bleiben, ist dann aber (auch bei mir) noch nicht straight eQ3 like
Wobei anstehende Konfigurationsdaten bei Verwendung von LAZY_CONFIG auch nur nach einem BIDI Telegramm von der CCU übertragen werden würden

Aber das "alle 20 Telegramme 1x BIDI senden" ist ja auch nicht "Originalgetreu".

[TomMajor]

D.h. broadcastEvent nimmt die Flags BIDI | WKMEUP wieder weg oder ist das jetzt egal?

Nimmt das BIDI Flag weg, wenn Empfänger die Broadcastadresse ist:
https://github.com/pa-pa/AskSinPP/blob/ ... age.h#L190

WKMEUP kann wohl bleiben, ist dann aber (auch bei mir) noch nicht straight eQ3 like
Wobei anstehende Konfigurationsdaten bei Verwendung von LAZY_CONFIG auch nur nach einem BIDI Telegramm von der CCU übertragen werden würden

Aber das "alle 20 Telegramme 1x BIDI senden" ist ja auch nicht "Originalgetreu".

ja schon klar, das "alle 20 Telegramme" ist ja ein homebrew Enhancment um nicht den config Taster drücken zu müssen an schlecht erreichbaren Stellen.
Das ist def. cooler als im Original.

ok, broadcastEvent nimmt BIDI weg.
Dann könnte ich es aber auch so machen, ich setzte ja die flags momentan in der msg.init:
https://github.com/TomMajor/SmartHome/b ... 1.ino#L169
das lasse ich so
und später vor dem Senden frage ich mit msg.flags() ab was "geplant ist" (BCAST oder BIDI | WKMEUP) und verzweige dann in broadcastEvent oder sendPeerEvent.
Das wäre dann straight eQ3 like (mal abgesehen vom "alle 20 Telegramme")

[jp112sdl]

Ja genau, das sollte so passen

[TomMajor]

ok, Danke.
habe es jetzt so gemacht

Code: Alles auswählen

        if (msg.flags() & Message::BCAST) {
            device().broadcastEvent(msg, *this);
        } else {
            device().sendPeerEvent(msg, *this);
        }

https://github.com/TomMajor/SmartHome/b ... #L323-L327

Vielleicht mag ja @rih das noch mal testen ob es jetzt mit dem Tooltip besser aussieht.

[rih]

Vielleicht mag ja @rih das noch mal testen ob es jetzt mit dem Tooltip besser aussieht.

Hm, ist ein bißchen heikel und aufwendig. Allenfalls beim Bewegungsmelder könnte ich es testen.
Ich verwende bisher die V1.12 des Unisensor-Sketches. Da hat sich ja einiges getan bei der aktuellen V1.18.

Fragen:
Warum wurde die Device-ID geändert? (alt: 0xA5, 0xA5, 0x03 , neu: 0xA5, 0xA5, 0x01). Welche Auswirkungen hat das in Verbindung mit FHEM? Soll / kann ich die Device-ID einfach in ...03 ändern?
Muss ich die HMConfig_UniSensor1.pm in FHEM auch austauschen? Wenn ja, funktionieren dann meine anderen Unisensor-Geräte mit V1.12 noch?
Wurde sonst zwischenzeitlich etwas geändert, was beim "Upgrade" unbedingt zu beachten ist? Kompilieren tut schon mal.

Ich möchte da ungern einen Rattenschwanz an Änderungen, Neuflashen und Neuanlernen von im Einsatz befindlichen Geräten auslösen.

[TomMajor]

ich habe da nichts geändert.
DeviceID und Serial sind vom Anwender festzulegen, durch das entsprechende include der cfg Datei.
https://github.com/TomMajor/SmartHome/b ... no#L32-L43

[demel42]

Gibt es hier Leute die einen NanoCul für den Analyzer im Langzeitbetrieb (>24h) im Einsatz haben? Falls ja, gibt es Probleme?

Nachdem ich meine Stick ausgetauscht hatte läuft er seit > 48h im Dauerbetrieb ohne Aussetze oder Unterbrechungen

demel

[demel42]

Ich habe den Analyser XS auf Raspbin 10 laufen in der dev-Version mit Commit-ID 9baae6b

In der GUID wurde angezeigt Update verfügbar auf 90c9fde und daher wollte ich ein Update der Dev-version machen

sudo npm i --unsafe -g https://github.com/psi-4ward/AskSinAnal ... ode.tar.gz
sudo systemctl restart analyzer

Obwohl das ohne Fehlermeldungen ablief, hat sich gemäß DGUI die Commit-ID nicht geändert, es wird weiterhin 9baae6b angezeigt

was mache ich falsch?

demel

[der-pw]

Ist bestimmt nicht die Lösung, aber hast du mal den letzte "stable" gezogen?
Der ist 15h alt.

Code: Alles auswählen

sudo npm i -g asksin-analyzer-xs
sudo systemctl restart analyzer