Probleme mit Programm und Geräte Firmware-Update

[GMH007]

Moin Männers,

bin neu hier im Forum und würde gerne von euren Erfahrung zehren wenn ich darf.
Schieße direkt mit meinem ersten Problem los.

Habe eine Türklingel, die als Taster über einen Klingeldraht in meine Unterverteilung geht. Dort hatte ich zuerst einen Eingang einer
HMW-IO-12-Sw14-DR belegt und dann ein Programm ausgeführt, welches mir auf dem MP3 Funk Gong (HM-OU-CFM-TW) mein gewünschtes File abspielen sollte.
Da dies nicht zuverlässig funktionierte (mal zeitverzögert ausgelöst, mal überhaupt nicht reagiert, dachte ich es liegt an der wired komponente, also beschaffte ich mir einen Funk Taster Empfänger

HM-PBI-4-FM

Es wurde besser als ich es frisch getestet hatte, aber danach gleiches Fehlerbild. Sporadische und verzögerte Funktion. Das Programm welches ausgeführt werden soll lautet:

Bedingung: Wenn...
HM-PBI-4-FM OEQ0614000:1 bei Tastendruck kurz

ODER
HM-PBI-4-FM OEQ0614000:1 bei Tastendruck lang


Aktivität: Dann...Vor dem Ausführen alle laufenden Verzögerungen für diese Aktivitäten beenden (z.B. Retriggern).
HM-OU-CFM-TW NEQ0401752:2 sofort kanalaktion 1,1,1080000,1
HM-OU-CFM-TW NEQ0401752:2 verzögert um 8 Sekunden Aus

Aktivität: Vor dem Ausführen alle laufenden Verzögerungen für diese Aktivitäten beenden (z.B. Retriggern).


Das wählt mir den Kanal aus und die Lautstärke. Nach 8 Sekunden soll es wieder ausgeschaltet werden, weil das File sonst nachhallt und ich will auch mehrfach klingeln zulassen können.

habe ich hier einen generellen Denkfehler im Programm, oder liegt das an der Reihenfolge wie die Programme abgearbeitet werden, dass dieses Event dazwischen rutscht und nicht ausgeführt wird?

Habe nen RPI3 mit der neuesten Firmware 2.35.16.20180715 (Seit gestern, hat aber nicht geholfen das Update)





Nun zu meinem zweiten Fehler. Ich habe auf der Startseite einige Meldungen, dass neue Geräte Firmware zur Verfügung steht. Hab gesehen, dass es nun eine neue Übersicht gibt, die passenderweise heißt "Geräte Firmware - Übersicht"

Dort das erste Gerät angeklickt, alles super
HMW-IO-12-Sw14-DR mit einer Seriennumer NEQxxx von Version 0.5 auf 1.0 geupdatet
Das nächste Gerät ist etwas Älter und hat die Seriennummer: MEQxxxx
Update erfolgreich durchgeführt, jedoch steht in der Liste nicht mehr die Teilenummer, sondern HMW-Generic
Version 0.5, updateversuche schlagen fehl, is klar.

Was geholfen hat war ablernen und wieder anlernen. Sogar die Firmware Version war dann korrekt auf 1.0 gesetzt. Jedoch nutze ich das Gerät um die Fußbodenheizung zu steuern. Dadurch sind mir in sämtlichen Programme die Kanäle rausgelöscht worden, wo es benutzt wurde.
Also hab ich gedacht, ok das Gerät hat die richtige Firmware, jetzt noch das Backup wieder einspielen und meine Programme sollten korrekt sein.

Dem ist auch so, jedoch wird mir in der Geräte Firmware - Übersicht wieder die alte Version 0.5 angezeigt. Genauso wie bei allen anderen Geräten die ich in der zwischenzeit geupdatet habe (Rollladenaktor auf version 2.11). D.h. das Backup aufspielen hat die Firmware in den Geräten zurückgesetzt? Das konnte ich mir nicht vorstellen. Hab die Browserdaten zurückgesetzt, RPI neu gestartet usw. Ne, es wird mir die alte Firmware für das Gerät angezeigt. Also das Prozedere des Updates der Geräte wiederholt.
bei neueren HMW Geräten klappt es, bei den "älteren wieder das gleiche Bild. backup aufspielen, Firmware bleibt auf 0.5

Woran kann das liegen?

[NickHM]

hallo

Punkt 2
bekanntes Problem.
Die FW Version der Geräte wird beim Anlernen fest gestellt und in der CCU gespeichert. Du macht ein Update. Die Textdatei in der CCU wird aktualisiert.
Du spielst ein backup zurück und hast wieder die alte Textdatei mit den alten FW Ständen.
Mir ist keine Funktion bekannt, die sagt "aktualisiere die Datei mit dem FW Stand aller Geräte".

Vermutlich hilft es nur das Gerät ab / anzulernen

Punkt 1
es wäre schön, Programme her als Screenshot rein zu stellen, nicht als nacherzählten Text.
Ist es nicht so, dass nach der Zeile mit der Kanalaktion noch ein "Einschalten" folgen muss? Oder spielt das Teil sofort los.

Wie auch immer. Man muss den Gong auf jeden Fall nicht aus schalten, denn in den Kanalaktionen kann man einstellen, wie lange das Audio abgespielt werden soll.

[GMH007]

Mag ja sein mit dem einschalten, asuschalten wie auch immer. Habe damals bei der Einrichtung rumexperimentiert und kam auf keine vernünftigere Lösung als das so zu machen nach einer bestimmten Zeit wieder auszuschalten. Es wird ja auch vorher eingeschaltet, funktioniert ja, nur eben sporadisch. Beantwortet leider nicht meine Frage warum dies nicht zuverlässig getriggert wird.
Habe gestern Abend mal kurz eine direkte Verknüpfung zwischen Tastereingang und dem Gong ausprobiert, aber weil beide Kinder schliefen und egal was ich an Lautstärke eingestellt habe es immer gleich laut war und nicht der Gong von der Karte den ich haben will, hab ich diese Experimente erstmal sein gelassen. Muss das am Wochenende mit der direkten Verknüpfung ausprobieren.

Gibt es sonst keine Vorschläge woran das noch liegen könnte?


zu der Firmware: Ich hätte erwartet, wenn ich unter "Geräte" das Gerät auswähle, dass ich dann auch die Tatsächliche Konfiguration vom Gerät sehe und nicht irgendwelche Informationen, die die Zentrale der Meinung ist, dass sie richtig sind. Ist doch Quatsch sowas.

Gibt es alternativen wie man den Soll/Ist Status abgleichen kann?
Und warum funktioniert das Update bei einem HMW-IO-12-Sw14-DR und bei den anderen beiden nicht?

[GMH007]

Bezüglich der Firmware version hab ich gelesen, dass man das umgehen können soll durch erneutes Anlernen ohne Ablernen. Dadurch würden die Programme erhalten bleiben und die Firmware version neu ausgelesen. Allerdings geht das anscheinend mit ner wired Komponente nicht. Weiß zumindest nicht wie.

Bei den jalousie-Aktoren hats auch nicht funktioniert mit anlernen über Seriennummer

[NickHM]

Guten Abend

bei der Kanalaktion kann man die Zeit angeben, die das Audio abgespielt wird

Warum das nicht zuverlässig funktioniert ist nur mit Diagnose, Logging, Test raus zu bekommen
- Gong auf protokolliert stellen
- Zeitstempel der Programmausführung ansehen. Wurde das Programm überhaupt getriggert
- LED zusätzlich anschalten - funktioniert diese immer?
- andere Speicherkarte mit mp3
- Format der mp3 ändern - Samplingfrequenz, Bitrate ...
- funktionieren andere mp3 von der karte zuverlässig, di für andere Zwecke genutzt werden?
- Kommunikationsstörungen mit dem Gong?
...

[GMH007]

Das würde ja explizieren, dass der Gong nicht richtig arbeitet. Ich hätte eher vermutet, dass das Programm nicht richtig bzw garnicht erst ausgeführt wird weil es in einer Warteschleife hängt oder so ähnlich.

Hat der Gong mal ausgelöst, kann ich den auch mehrfach hintereinander auslösen. Jedoch auch nicht immer. Auch da kann ein Trigger mal aussetzen.

Schlimmer ist es ja im Regelfall, der Postbote kommt und es klingelt nicht.
Ich bräuchte quasi nen log drüber, wann ist die Taste gedrückt worden und wann ist das Programm aufgerufen worden (evtl. auch ist der Gong ausgelöst worden?)

Ansonsten, mal abgesehen von abspieldauer und meiner quick and dirty Methode mit dem ausschalten, sonst alles richtig eingegeben? Habe das nie so richtig verstanden die unterschiede: Bei Änderung auslösen usw

[NickHM]

Guten Morgen

die beiden Bedingungen "Tastendruck kurz" "Tastendruck lang" könnten auch mit einem Oder in die obersten Zeile. Rein von der Logik her sollte das keinen Unterschied machen, bei der WEbUi sind aber manchmal Dinge etwas "eigenartig"

- Du kannst den Taster auf "protokolliert" stellen
- Du kannst den Gong auf "protokolliert" stellen
Dann kannst Du im Logfile sehen, ob jeder Tastendruck den Gong auslöst

Beim Programm selbst, siehst Du nur die letzte Laufzeit. Allerdings kann man zusätzlich im Programm eine Sysvar setzen und löschen oder ein kleines Script nehmen um auch das zu protokollieren indem die SysVar ebenfalls auf protokolliert gesetzt wird.

Du musst Dir wie oben bereits geschrieben Möglichkeiten schaffen um heraus zu bekommen, ob es am Programm oder am Gong liegt.

[GMH007]

Ja ok, das hilft mir schon mal weiter, danke dafür. Dann probiere ich das mal aus. Irgendwie muss man dem ja auf den Grund gehen

[GMH007]

Leider hilft mir das Protokollieren auch nichts. was soll ich in der log nun rauslesen? Sind für mich bömische Dörfer die vielen Zeilen

[Familienvater]

Hi,

ich gehe davon aus, das Du das Syslog aktiviert hast? Da kommen für den Laien ggf. unverständliche Dinge bei raus.

Sinnvoller wäre es, die "Kanäle" in WebUI auf "Protokolliert" zu stellen, dann kann man die Events für die protokollierten Kanäle auch in der WebUI "lesbar" anschauen.

Ich vermute aber auch Verkabelungsdefizite. Aus Deiner Beschreibung heraus klingt es für mich so, das Du den PBI4 in die UV gesetzt hast, direkt an die Kabel, die Ursprünglich an das Wired-Modul gingen. Da der Postbote wahrscheinlich nicht in Deiner UV klingelt, sondern 5-10 Kabel-Meter weiter draußen, sind die max. Kabellängen für das Funkinterface weit Überschritten, und fehlende Events oder schnell leergesaugte Batterien könnten dann daran liegen.

War die Klingel ursprünglich an einem 12/14er Multi-IO mit Schließerkontakten oder an einem 12/7er mit Tastereingängen?

Der Familienvater