Alternative Firmware für das Raum-Sensormodul von Masifi

[mumpf]

Eine Firmware muss immer passend zur Applikation sein (und umgekehrt). Du musst immer Applikation und Firmware aktualisieren.

Gruß, Waldemar

[st400]

• Hilft es vielleicht, das Modul komplett stromlos zu machen? Also vom USB und KNX komplett trennen?
  • leider nicht, das habe ich schon mehrfach versucht
• Bist Du sicher, dass die Adapterplatine (die mit dem Sensor) richtig rum draufgesteckt wurde?
  • Ja
• Hast Du bei meiner Anleitung ein Neu-Setup (knx-dev-setup) oder ein Update (knx-update-setup) verwendet?
  • Ich hatte ein Problem beim build und habe daher das alte Projekt gelöscht und nach Anleitung neu angelegt
• Bist Du vom Beta (also alte Version 3.x) oder vom Release (alte Version 2.6) auf die 3.8 gegangen?
  • Vorher habe ich eine ältere beta 3.x verwendet
• Hast Du in der ETS ein Update einer alten Applikation oder eine neue Applikation angelegt?
  • in der ETS habe ich die Applikation nicht geupdated. Ich verwende somit noch die ursprüngliche beta Applikation. Kann hier das Problem liegen?

Danke für deine Unterstützung 👍

[mumpf]

Hi,

bei mir wird der BME680 quasi standardmäßig getestet . Läuft derzeit auf 2 Instanzen. Ich denke, das bekommen wir hin. Erstmal ein paar Fragen:

• Hilft es vielleicht, das Modul komplett stromlos zu machen? Also vom USB und KNX komplett trennen?
• Bist Du sicher, dass die Adapterplatine (die mit dem Sensor) richtig rum draufgesteckt wurde?
• Hast Du bei meiner Anleitung ein Neu-Setup (knx-dev-setup) oder ein Update (knx-update-setup) verwendet?
• Bist Du vom Beta (also alte Version 3.x) oder vom Release (alte Version 2.6) auf die 3.8 gegangen?
• Hast Du in der ETS ein Update einer alten Applikation oder eine neue Applikation angelegt?

Das sind erstmal die Fragen, um das Problem besser lokalisieren zu können.

Gruß, Waldemar

[st400]

Hallo mumpf,
ich habe das neue Release auf zwei Modulen installiert. Seit dem liefern leider beide Module keine (sinnvollen) Werte mehr. Z.B. bei der Temperturabfrage erhalte ich den Wert 0°C. Die Abfrage von KO Sensorfehler liefert ebenfalls 00 00. Hast du einen Tip zur Fehlereingrenzung?

Ergänzung:

• als Sensor wird ein BME680 eingesetzt
• Source wurde frisch von deinem Repository gecloned
• build und upload wie in deiner Anleitung durchgeführt
• Physikalische Adresse und Applikation programmiert

[mumpf]

Release 3.8 steht ab sofort zur Verfügung!

Wie schon länger versprochen, ist jetzt endlich die Überführung fertig von Beta zu Release. Es gibt nur wenige Änderungen, da ich mich auf die Zusammenführung konzentriert habe. Jetzt gibt es wieder eine Basis für Weiterentwicklungen.

Ab sofort ist die Beta-Version nicht mehr weiter unterstützt. Zukünftige Erweiterungen und Korrekturen werden wieder in Release aufgehen.

Falls jemand noch auf der alten Release-Version sein sollte, kann die Änderungen in der Applikationsbeschreibung (Änderungshistorie) nachlesen. Hier beschreibe ich nur die wenigen Änderungen, die gegenüber der letzten Beta erfolgt sind.

• In der Sensormodul-Applikation gab es ein Paar Stellen, an den es zu einer "Division durch Null" kommen konnte, diese sind jetzt Korrigiert. Ein Symptom war, dass manchmal Messwerte negativ waren.
• In der 1-Wire-Applikation gab es keine Änderungen, allerdings hoffe ich, dass die Korrekturen zur "Division durch Null" auch hier ihre Wirkung zeigen. Beobachten konnte ich das bisher nicht, ich nutze 1-Wire bisher aber noch nicht im Produktivbetrieb.
• In der Logik-Applikation sind mehrere Korrekturen erfolgt:
  • Feature: Es wird nicht nur ausgegeben, ob "Heute" bzw. "Morgen" ein Feiertag ist (DPT1), sondern welcher Feiertag es ist (DPT5)
  • Wie das genau ausgegeben wird, ist in der Applikationsbeschreibung "Feiertage auf dem Bus verfügbar machen" beschrieben
  • Inkompatible Änderung KO 5 und KO 6 sind jetzt DPT5.010 statt DPT1.001. Vor einem Upgrade müssen alle mit diesen KO verknüpften GA entfernt werden.
  • Fix: Eingangskonverter "Differenzintervall" und "Differenzhysterese" für DPT9.x funktionierten nicht, ist jetzt korrigiert
  • Inkompatible Änderung Bei einem Update gehen die Parameter für Von-/Bis- bzw. Einschalt-/Ausschalt-Wert bei Eingangskonvertern "Differenzintervall" und "Differenzhysterese" für DPT9 (und nur für DPT9) verloren. Diese müssen nach einem Update manuell nachgetragen werden.

Ihr findet das Sensormodul wie üblich auf github: https://github.com/mumpf/knx-sensor.

Installationsanleitung: https://github.com/mumpf/knx-sensor/...x-dev-setup.md

Update-Anleitung: https://github.com/mumpf/knx-sensor/...pdate-setup.md

Applikationsbeschreibung Sensor: https://github.com/mumpf/knx-sensor/...bung-Sensor.md
Applikationsbeschreibung 1-Wire: https://github.com/mumpf/knx-wire/bl...eibung-Wire.md
Applikationsbeschreibung Logik: https://github.com/mumpf/knx-logic/b...ibung-Logik.md

Ergänzung: Die Sensormodul-Applikation ist sowohl mit der ETS 5 wie auch mit der ETS 6 getestet, sowohl zum Anlegen von neuen Geräten wie auch beim Update einer alten Version. Zum Bauen der knxprod braucht mal allerdings eine installierte ETS 5 auf dem Rechner. Es reicht auch die Demo-Version.

Diese Version (in ähnlichen Testkonfigurationen) ist bisher ca. 3 Monate bei mir im Produktiv-Betrieb gewesen, in der finalen Konstellation ca. 1 Woche.

Viel Spaß mit dem neuen Release,
Gruß, Waldemar

[mumpf]

Ob die 24h Rückwirkend gehen brauche ich nicht mehr testen und der Usecase ist glaube auch eher unwahrscheinlich

Ich ging auch davon aus, dass man sich in relativer Nähe um die Sunrise- und Sunset-Zeitpunkte bewegt (man hat ja mehrere Stunden), aber wenn es in den vorherigen/nächsten Tag geht, kann man das ja auch mit den Sunrise/Sunset des jeweiligen Tages ausdrücken. Deswegen hab ich da nichts besonderes implementiert (und würde es nicht machen, solange mir keiner einen einleuchtenden Usecase nennen kann ).

warum es damals die zwei Tage nicht geklappt hat kann ich nicht mehr sagen.

Ich würde vermuten, dass das Datum nicht bekannt war - warum auch immer. Diagnose "t" hilft da weiter, die gibt die interne Uhrzeit/Datum auf das Diagnoseobjekt raus. Wobei - wenn "r" schon die Sunrise-/Sunset-Zeiten geliefert hat, dann war das Datum bekannt, da dann erst die Sunrise-/Sunset-Zeiten berechnet werden.

sorry für die Umstände

Kein Ding, war ja einfach...

Gruß, Waldemar

[Amenophis]

Also heute haben alle Schaltzeitpunkte geklappt, warum es damals die zwei Tage nicht geklappt hat kann ich nicht mehr sagen. Ob die 24h Rückwirkend gehen brauche ich nicht mehr testen und der Usecase ist glaube auch eher unwahrscheinlich. Daher Danke für die Hilfe und sorry für die Umstände

[Amenophis]

Bomben Tipp, das hätte es mir einfacher gemacht, daher vielen Dank.

Die ersten beiden Schaltzeiten wurden wohl auch eingehalten, wie es aussieht saß der Fehler wohl mal wieder vor dem PC melde mich, wenn alle Schaltzeiten durchgelaufen sind.

[mumpf]

Hi Etienne,

hier noch ein paar Tipps, wie man so was schnell testen kann, ohne das gesamte Haus zu "stören" aber auch ohne lange warten zu müssen, ob das Ereignis eintrifft. Das Zauberwort sind hörende Adressen!

HörendeAdresseTimeDate.jpg
Nach dem Neustart kannst Du dann neben der "offiziellen" Datum/Zeit GA (bei mir 2/4/1 und 2/4/0) über die 2/7/9 eine neue Zeit schicken, die dann ja nur das Modul empfängt (also keine neue Zeit auf dem Bus) und so direkt testen. Ich hab zu Sonnenuntergang - 15 Minuten die Sunset-Zeit abgefragt (bei mir 16:37), dann 15 Minuten abgezogen (16:22) und per ETS einfach 16:21:30 auf die 2/7/9 geschickt. Nach 30 Sekunden habe ich das Schaltsignal auf dem Bus gesehen.

Nur so als Tipp, ich verwende hörende Adressen an vielen Stellen, um einfach mal Logiken zu testen und mal Zustände durchzuspielen, die eigentlich selten auftreten. Die Werte schicke ich dann über die ETS und kann sicher sein, dass es nicht von anderen KO empfangen wird, da die Hörende GA nur an genau dem zu testenden KO steht.

Gruß, Waldemar

[Amenophis]

Guten Morgen, Waldemar

Was ich wollte war nur eine Lampe 30min vor sunset zu schalten. Das hatte zweimal nicht geklappt, dann habe ich den Fehler gesucht. Zum testen hatte ich immer zurück gerechnet, um aktuell testen zu können. Mit einem Puffer, dass die Uhrzeit gezogen werden kann etc. Allerdings habe ich mich gestern bei dem Test wohl verrechnet, was du richtig bemerkt hast. Ob der Rückwärts Überschlag (vor 0uhr) geht, weiß ich nicht, hatte ich aber als Option für einen Fehler in meinen tests gesehen.

Ich habe für heute nochmal ganz normal 6 Schaltpunkte mit sunset minus (4 - 30min vorher) gesetzt, die ich auch logge. Mal sehen was da passiert. Dann melde ich mich nochmal. Danke für deine Rückmeldung, dass es bei dir geht. Vielleicht liegt der Fehler, wie so oft vor dem PC. Und deine Anleitung ist verständlich

[mumpf]

Hi Etienne,

ich verstehe einfach nicht, wie Du rechnest.

Ich habe nochmal in die Doku geschaut, ich finde das verständlich beschrieben, aber das mag daran liegen, dass ich es geschrieben habe .

Sonnenuntergang: minus Zeitversatz

Der Schaltzeitpunkt ist der Sonnenuntergang, von dem die Zeitangabe, die in den Spalten Stunde und Minute steht, abgezogen wird. Es wird somit um die angegebenen Stunden und Minuten vor Sonnenuntergang geschaltet.

Somit würde hier:

Diagnose zeigt mir an Sunset um 16:35Uhr
Ich setze jetzt eine Zeitschaltuhr auf 19h und 20min, dann müsste diese ja um 20:40 Uhr auslösen, korrekt? D

Nein! Mich würde interessieren, wie Du auf 20:40 Uhr kommst...

So wird gerechnet:
16:35 Uhr - 19 Stunden = 21:35 Uhr (Vortag)
21:35 Uhr - 20 Minuten = 21:15 Uhr (Vortag)

Willst Du das wirklich (19 Stunden VOR Sonnenuntergang) schalten? Das hab ich nicht getestet und bin mir auch nicht sicher, was beim Über- bzw. Unterlauf der Tagesgrenze passiert.

Falls Du das wirklich brauchst, müsste ich nochmal testen. Ein Problem, dass ich aber sofort sehe: Ich berechne immer nur Sunrise und Sunset für den aktuellen Tag, wenn ich das auch noch für die beiden benachbarten Tage machen muss, wird es eine größere Änderung.

Deswegen hier nochmal die Frage, was Du eigentlich bewirken willst? Wenn Du eine Schaltzeit um 20:52 Uhr haben willst, wäre das Sunset (16:35 Uhr) plus Zeitversatz (4 Std; 17 Min). Sunset minus Zeitversatz schaltet auf jeden Fall vor dem Sonnenuntergang.

Gruß, Waldemar

[Amenophis]

Also um 16:35 Uhr wird Sunset angezeigt. Damit hätte folgende Einstellung um 20:52, 20:53, 20:54 und 20:55 schalten sollen. Passiert ist allerdings nichts. Hier ein paar Bilder der Einstellung:

[Amenophis]

Ich habe es befürchtet. Werde es jetzt nochmal selbst testen. Da ich aber nicht bis morgen warten möchte, müsste folgendes ja auch gehen, oder?

Diagnose zeigt mir an Sunset um 16:35Uhr
Ich setze jetzt eine Zeitschaltuhr auf 19h und 20min, dann müsste diese ja um 20:40 Uhr auslösen, korrekt? Damit werde ich jetzt nochmal testen und wenn nix geschaltet wird, dann poste ich hier die Daten. Die Einstellung von damals habe ich nicht mehr, da ich die Logik deswegen vorerst verworfen hatte.

[mumpf]

Hi Amenophis (Etienne),

ich hab es heute endlich ausprobiert. Sonnenuntergang - 15 Minuten hat problemlos ausgelöst. Mit zurückstellen der Uhr hat es auch mehrmals hintereinander geklappt. Somit die Rückfrage: Wie sieht Deine Parametrisierung konkret aus?

Gruß, Waldemar

[mumpf]

Sonnenuntergang minus Zeitversatz will einfach nicht auslösen.

Ist nicht vergessen, aber testen kann ich erst, wenn ich wieder zu Hause bin - das ist frühestens am 6.1.

Gruß, Waldemar