Alternative Firmware für das Raum-Sensormodul von Masifi

[jeff25]

Hi Waldemar,

glaube den -DNCN5120 hat es gebraucht ....

Logik-gNumChannels (in knxprod): 30
Aktuelle Zeit: Wed Jan 1 00:06:00 2020
Sensormodul: SAVE-Interrupt processing started after 4 ms
savePower: Switching off 5V rail...
writeAllInputsToEEPROM called repeatedly within 10 seconds, skipped!
Logic: SAVE-Interrupt processing duration 0 ms
Sensormodul: SAVE-Interrupt processing duration was 0 ms
restorePower: Switching on 5V rail...
Sensormodul: SAVE-Interrupt processing started after 2 ms
savePower: Switching off 5V rail...
writeAllInputsToEEPROM called repeatedly within 10 seconds, skipped!
Logic: SAVE-Interrupt processing duration 0 ms
Sensormodul: SAVE-Interrupt processing duration was 0 ms
restorePower: Switching on 5V rail...
Logik-LOG_ChannelsFirmware (in Firmware): 80
Logik-gNumChannels (in knxprod): 30
Aktuelle Zeit: Wed Jan 1 00:06:30 2020

nun sieht es doch ok aus oder?

update: habe nun noch den save pin verbunden, mann bin ich.....

Logik-LOG_ChannelsFirmware (in Firmware): 80
Logik-gNumChannels (in knxprod): 30
Aktuelle Zeit: Wed Jan 1 00:01:00 2020
Logik-LOG_ChannelsFirmware (in Firmware): 80
Logik-gNumChannels (in knxprod): 30
Aktuelle Zeit: Wed Jan 1 00:01:30 2020
Logik-LOG_ChannelsFirmware (in Firmware): 80
Logik-gNumChannels (in knxprod): 30
Aktuelle Zeit: Wed Jan 1 00:02:00 2020
Logik-LOG_ChannelsFirmware (in Firmware): 80
Logik-gNumChannels (in knxprod): 30
Aktuelle Zeit: Wed Jan 1 00:02:30 2020
Logik-LOG_ChannelsFirmware (in Firmware): 80
Logik-gNumChannels (in knxprod): 30

Gruß
Robert

[mumpf]

Hi Robert,

er geht dann auch in den power save mode mit dem ncn5130.

was meinst Du damit genau? Ich habe kein spezielles Coding für den NCN5130 drin, ich checke nur auf den "normal mode" (was das auch immer ist), weil es in meinen Tests nach einigen Abstürzen (im Rahmen den Entwicklung, sollte beim Nutzer nicht vorkommen) immer wieder mal dazu kam, dass der NCN nach einem Reset nicht geantwortet hat und ich dann das ganze Modul stromlos machen musste. Die Meldung sagt einfach nur, dass der NCN noch arbeitet. Das einzige spezielle, dass ich vom NCN (gegenüber einem "normalen" UART) nutze, ist der SAVE-Pin, der kann einen Interrupt auslösen, wenn die Busspannung ausfällt. Ich brauche dann bis zu 400 ms, um den aktuellen Zustand in das EEPROM zu schreiben. Ob der SAVE-Pin angeschlossen ist, kann man in der ETS in den allgemeinen Einstellungen setzen.

Es gibt noch dieses Coding im KNX-Stack (nicht von mir), das brauchte ich nicht und hab es nicht aktiviert. Evtl. ist es für den NCN5120 nötig. Falls ja, müsstest Du in der platformio.ini noch ein   -DNCN5120  einfügen.

Gruß, Waldemar

[jeff25]

Hallo mumpf ,

kurze Frage ich habe deine Software auf meinem Test Board ausprobiert und ich nutze das mit einem NCN5120.

Die Ausgabe auf der console sagt das hier:
Startup called...
I2C bus cleared successfully
Checking EEPROM existence... OK
Checking 1-Wire existence... FAIL
Checking LED driver existence... FAIL
Checking NCN5130 existence... OK
EEPROM does NOT contain valid data
ownaddr 1107

er geht dann auch in den power save mode mit dem ncn5130. Ist das so ok oder geht deien software mit dem NCN5120 nicht?

Gruß
RObert

[mumpf]

Hi,

2 Sachen, die ich mir im Laufe der Zeit angewöhnt habe auszuprobieren, wenn USB nicht lief:

1. Das Micro-USB-Kabel kann einen "Wackler" haben. Auch wenn Matthias gute USB-Buchsen verwendet, viele Kabel zeigen einfach Abnutzungserscheinungen und konnektieren dann schlecht. Also mehrere ausprobieren, und wenn man ein zuverlässiges gefunden hat, das dann beschriften und dann fürs Programmieren nutzen. Ich hab 2 solcher Kabel und die Hüte ich wie mein Augapfel.
2. Wenn USB nicht erkannt wird (und man glaubt, dass es nicht am Kabel liegt), dann 2x die Reset-Taste drücken (wie ein Doppelclick), dann sollte die rote LED pulsieren. Jetzt ist der Prozessor im Notfall-Bootmodus und man bekommt eine alternative USB-Kennung (anderer COM-Port). Jetzt die Firmware neu laden.

Erst wenn Du das probiert hast, solltest Du an Hardwarefehler denken.

Gruß, Waldemar

[Masifi]

Ich kenne den Fehler, aber in der Regel war der Controller nicht defekt.
Du kannst mal versuchen ein anderes USB Kabel zu verwenden. Das Kabel sollte auch nicht über einen USB-Hub laufen. Oder es ist ein Gnd Problem. Man kann hier mal den USB Stecker mir tesa abkleben.
Wenn das nicht hilft habe ich es über JTAG versucht, das ging dann in der Regel wieder.
Wenn das alles nichts hilft, dann melde dich direkt bei mir und wir schauen zusammen mal drauf.

[mpl1337]

Ich glaub der Sensor hat nen Hardware defekt.

bekomme jetzt beim einstecken des USB Kabels ne Meldung von Windows dass das USB-Gerät nicht erkannt werden konnte

Unbenannt.png

hatte schonmal ein Problem mit einer der Spulen... die war gebrochen. Nach Austausch dieser lief er wieder.

[mpl1337]

habe das modul V3.1

Unbenannt.png

[mpl1337]

Hi

Ich hatte davor die Version in der die Luftqualität noch nicht funktionierte - ich schätze das war 1.x und habe auf 2.0.0 geupdatet. 2.0.1 habe ich noch nicht versucht.

[mumpf]

Hi,

ich habe jetzt auch eine komplette Neuprogrammierung gemacht. Hat funktioniert, es liegt also nicht am Fix.
Wir müssen jetzt gemeinsam rausfinden, was bei Dir passiert ist. Das wichtigste: Hast Du in der platformio.ini das richtige Board ausgewählt (die Version
   -DBOARD_MASIFI_Vx ?

Gruß, Waldemar

P.S.: An alle anderen: Bevor das hier nicht geklärt ist, solltet ihr vielleicht nicht auf die 2.0.1 updaten.

[mumpf]

Hi,

was könnte hier passiert sein?

das weiß ich nicht, ich hoffe, dass wir das gemeinsam rausbekommen. Zuerst: Hast Du von 1.x auf 2.0.1 aktualisiert oder von 2.0.0 auf 2.0.1, also nur meinen Fix zu den ACK auf dem Bus einspielen wollen?

Ich muss gestehen, ich habe den Fix auf einem laufenden Modul getestet und nicht komplett neu programmiert. Das werde ich gleich nochmal versuchen. Wenn Du aber von 1.x aktualisieren willst, wird es wahrscheinlich was anderes sein.

Gruß, Waldemar

[mpl1337]

Hi,

Wollte heute mal das Sensormodul Updaten - jetzt geht nichts mehr :/

Als ich nach dem Software update in der ETS die Physikalische Adresse vergeben wollte bekam ich die Meldung dass das gerät nicht in angemessener zeit antwortet daraufhin hab ich nen Minimalaufbau errichtet (Sensormodul, USB Schnittstelle und Spannungsversorgung) und hier bekomme ich jetzt als Fehler dass mehr als ein Gerät im prog. Modus ist. - Jetzt geht nichts mehr

Wenn ich mir in der ETS die Geräte im prog Modus anzeigen lasse erscheint 1-4 mal die 15.15.255 wenn ich den Sensor abziehe erscheint kein gerät mehr

was könnte hier passiert sein?

[mumpf]

Hi allerseits,

ich habe soeben eine Korrektur im knx-Stack hochgeladen. Wie immer findet man natürlich kurz nach dem Release auch noch Fehler. Hier handelt es sich um einen langzeit-Fehler, dem ich endlich auf die Schliche gekommen bin. Das Modul schickte bei GroupValueWrite, also beim Empfang von Daten, keinen ACK. Das hat dazu geführt, dass die Telegramme immer 3 mal wiederholt wurden. Wer das Modul rein als Sensormodul betreibt, dass ja immer nur sendet, hat das Problem nicht. Aber sobald man z.B. auch Mittelwerte aus mehreren Temperaturen oder so verrechnen lässt (also sobald man Daten an das Modul sendet), ist das Problem da.

Bei der Verwendung von Logiken macht sich das Problem stärker bemerkbar, da dann auch alle Wiederholungen verarbeitet werden. Wenn man z.B. bei einem Signaleingang es 1 mal piepen lassen will, dann piept es 4 mal.

Die gute Nachricht: Nach Außen (also für die restlichen KNX-Geräte) hat das keine Auswirkungen, Wiederholungen gehören zum Protokoll. Außer erhöhter Buslast (4 statt 1 Telegramm) passiert nichts. Aber mich hat das "gewurmt" und ich hab immer wieder nach der Lösung gesucht und jetzt endlich das Problem gefunden und gefixt.

Ich würde das Update empfehlen. Folgendes Vorgehen:

• Ihr geht nach dem update-Dokument vor: https://github.com/mumpf/knx-sensor/...date-setup.pdf
• den "Pull" braucht man nur für knx-sensor und knx, die anderen beiden (knx-common und knx-logic) sind unverändert (ein pull schadet auch nicht).
• Jetzt nur noch die Firmware bauen und auf das Sensormodul hochladen
• ihr braucht KEINE NEUE knxprod zu bauen, da hat sich nichts geändert. Also gibt es auch keine Änderungen in der ETS.

Wenn ihr prüfen wollt, ob alles richtig ist, könnt ihr in der ETS zu dem Gerät die Geräteinfo lesen (Rechtsklick auf Gerät, dann Strg-I). In der Geräteinfo gibt es dann einen Eintrag

Firmware-Version: [2] 0.1

Wenn da [2] 0.0 steht, dann ist das die Version vor dem Fix, dann ist die neue Firmware nicht auf dem Gerät angekommen.

Gruß, Waldemar

[mumpf]

Hi Mattias,

Ansonsten hoffe ich mal das die SW bald fertig ist,

das ist Software - die ist nie fertig. Man kann höchstens definieren, dass sie fertig ist oder einfach nichts mehr dran machen... .

Dem Endnutzer steht natürlich auch frei zu entscheiden, dass man neue Features nicht brauch und so die Software auf dem Stand lassen. Immerhin gibt es hier kein "security risk", wenn man nicht aktualisiert.

Gruß, Waldemar

[Masifi]

Etwas umständlich ist, dass man bei V3ff USB und KNX braucht.

Ja das ist leider so. Wenn jemand etwas löten kann, dann kann er den LDO dafür auch selber nachbestücken.
Ansonsten hoffe ich mal das die SW bald fertig ist, dann muss man gar nichts mehr machen

[mumpf]

Hi,

Etwas umständlich ist, dass man bei V3ff USB und KNX braucht.

Das ist Hardware, dafür kann ich nichts .

Ja, die GAs gehen verloren. ... Parameter bleiben erhalten, bis auf die Diagnose (J/N).

Genau. Das hatte ich beschrieben und ich hoffe, das hast Du auch so erwartet.

Screenshot vorher hilft bei der Wiederherstellung.

Genau, oder eine Kopie des Gerätes und dann einfach vom alten Gerät aufs neue ziehen.

Ich höre daraus, dass nichts unerwartetes passiert ist, das freut mich.
Ich hoffe, in Zukunft bleiben auch die GA erhalten, zumindest hab ich dafür in der knxprod alles getan, was mir möglich war.

Gruß, Waldemar