Alternative Firmware für das Raum-Sensormodul von Masifi

[murloc]

Hallo Waldemar,

alles klar - nur keinen Stress.

Beste Grüße!

[mumpf]

Hi,

irgendwie ist in diesem Release der Wurm drin, sorry. Ich bin wohl mit den verschiedenen git branches bzw. den merges durcheinander gekommen. Ich konnte zwar heute Abend noch eine funktionierende Version zusammenstellen, aber das ist nicht die aller letzte Version (also die, die ich freigeben wollte). Ich werde noch etwas brauchen, um genau zu prüfen, was schief gelaufen ist und an welcher Stelle in git die Sachen verloren gegangen sind.

Sorry für die Verzögerung. Ich bin dran und melde mich, wenn es wieder läuft. Danke nochmal für die Rückmeldung.

Gruß, Waldemar

[jeff25]

Hi Waldemar,

weis nicht ob es hilft, der Fehler mit "Id-Uniqueness..." kam bei zwei Objekten schon bei der Version vom Wochenende, vielleicht hilft das ja beim Fehlersuchen...

Guß
RObert

[mumpf]

Danke für die Info, ich muss mal Schritt für Schritt zurückgehen und schauen, wann sich der Fehler eingeschlichen hat. Kann ich aber erst abends machen, ich muss ja auch noch nebenbei arbeiten .

Gruß, Waldemar

[jeff25]

na klar. wollt dir nur sagen das der Fehler schon teilweise in deiner Wochenende Version da war. Nicht das du an der falschen Stelle sucht :-)

[mumpf]

Weißt Du zufällig, ob es in der davor liegenden Version (also in der vor dem Wochenende) nicht drin war? Dann wüsste ich auch, wann es noch OK war...

Gruß, Waldemar

[jeff25]

bei der Wochenende Version kam zweimal der Id-Uniqueness... Fehler... nun kommt er ja 5 mal oder so. Daher war am Wochenende auch schon teilweise da....

[mumpf]

Hi allerseits,

in der Woche kam ich nicht wirklich dazu, aber jetzt suche ich intensiv nach dem "ID-Uniqueness"-Fehler. Bisher hab ich raus, dass Teile der 3.0 (1-Wire) Applikation irgendwie mit Teilen der 2.0 (Zeitschaltuhr) Applikation (also die xml-Files, auf den das basiert) zusammen "gemerged" wurden. Das darf nicht sein, da dann doppelte Keys vorkommen - ich wundere mich eher, dass es nicht viel mehr keys sind. Ich bekomme das sicher gelöst, aber ich will erst verstehen, was da passiert ist, damit es mir nicht wieder passiert.

Deswegen muss ich noch um Geduld bitten, ich bin mir nicht sicher, ob ich es morgen schaffe - und wie viel Zeit in der (Arbeits-) Woche bleibt, kann ich nicht sagen. Also wahrscheinlich erst kommendes Wochenende.

Gruß, Waldemar

[mumpf]

Hi,
ich bin so weit. Ich habe soeben die Reparatur freigegeben. Es gilt immer noch die Update-Anleitung für 2.0. Ich habe sowohl an MultiplyChannels.exe wie auch an allen knx-Projekten (knx-logik, knx-sensor, knx-common, knx) was reparieren müssen, idealerweise holt ihr euch alle Teile und baut das neu, wie in der Anleitung beschrieben.

Die aktuellen Versionen:

• MultiplyChannels.exe v2.1.0
• knxprod v2.0-2.3 (die Version ist geblieben)
• Firmware-Version 2.1.0 (bugfix-Version)

Für die, die es interessiert, einige Details:

• Ich hatte bisher 2 verschiedene Entwicklungszweige für 2.0 (Zeitschaltuhren) und 3.0 (1-Wire) verwendet.
• Der 3.0 Entwicklungszweig war schon so umgebaut, dass zukünftig die selbe Logik in beide Entwicklungszweige einfließt.
• Nach dem Release von 2.0 habe ich mit 3.0 weiter gemacht.
• Irgendeine der Korrekturen, die nach 2.0 gemacht hatte, habe ich wohl versehentlich im 3.0-Coding gemacht und das released.
• Seitdem gab es die duplicate keys.
• Ich hatte das nicht gemerkt, weil meine knxprod schon alle auf 3.0 waren.

Als Lösung gibt es jetzt:

• Die reparierten xml für die knxprod (v2.0-2.3), die aber schon genau so gebaut werden, wie die zukünftige 3.0 knxprod (deswegen braucht man jetzt das neueste MultiplyChannels 2.1.0 dafür).
• Eine neue Firmware 2.1, die alle bisher aufgefallenen Bugfixes enthält:
  • Ein GroupValueWrite auf einen Logik-Ausgang konnte zu Seiteneffekten führen, wenn man bei dem Ausgang das S-Flag gesetzt hat.
  • Die Implementierung von TOR (bzw. Sperre) im Logikmodul war unvollständig (ich hatte einige Fälle einfach vergessen), ist jetzt aber komplett implementiert und durchgetestet.
• Der knx-Stack enthält auch alle Korrekturen, die bezüglich der Kommunikation im Originalstack angefallen sind.

Für diejenigen, die bereits eine funktionierende knxprod v2.0-2.3 haben, müssen keine neue knxprod bauen und in die ETS importieren. An der knxprod hat sich nichts geändert, nur der Weg, wie diese erzeugt werden!

So, ich hoffe, das jetzt alles gut geht.
Viel Spaß mit dem Release,
Gruß, Waldemar

[murloc]

Hallo Waldemar,

der *.knxprod Build läuft nun einwandfrei durch.
Besten Dank!

Grüße

[mumpf]

Danke fürs Feedback!

Gruß, Waldemar

[jeff25]

Hallo Waldemar,

danke schön. läuft ohne Probleme. Cool dass du den DDEBUG_DELAY Parameter eingeführt hattest da mein USB zu langsam war und debug nie ging ausser ich habe die "100" erhöht. So kann man es nun in der Plattform.ini setzen wie man es braucht.

Gruß
Robert

[mumpf]

Hi,

So kann man es nun in der Plattform.ini setzen wie man es braucht.

ja, auch das ist ein "Abfallprodukt" der Vereinheitlichung meiner 2.0 und 3.0 Entwicklungsschiene. Ich werde versuchen, zu 3.0 über passende PlatformIO-Environments direkt release/debug/deploy usw. zu unterstützen und so (hoffentlich) nicht mehr im Coding "rumpfuschen" müssen. Sonst ist das vor einem Release zu viel Arbeit und zu Fehleranfällig.

Gruß, Waldemar

[ReinerDaniel]

Hallo Waldemar,

ich traume es fast mich es zu schreiben, aber vielleicht schaust Du Dir Folgendes noch mal an. Ich habe die Firmware neu konstruiert und auch knxprod.

Bei der Firmware ist mir aufgefallen, dass default jetzt V3 ist nicht V31. Macht nichts, wenn man es weiß, widerspricht aber der Doku.

In der ETS wird mit das Sensormodul-v2.1-20 angezeigt, obwohl ich die -80 importiert habe und auch die 80 Logikkanäle habe ( oder zu haben scheine).
Bei Applikationsversion zeigt die ETS die Version 2.3 an.
Ist das so gewünscht??

Liebe Grüße
Matthias

P.S.: Absolut tolle Arbeit. Macht Spaß

[mumpf]

Hallo Matthias,

keine Rückmeldung ist überflüssig. Nur das, was gemeldet wird, kann ich auch berücksichtigen bzw. kommentieren. Insofern bitte immer was sagen, wenn was auffällt. Ich versuch schon, die Sachen sorgfältig zu machen, aber es rutscht eben manchmal was durch.

Bei der Firmware ist mir aufgefallen, dass default jetzt V3 ist nicht V31. Macht nichts, wenn man es weiß, widerspricht aber der Doku.

Das ist einfach erklärt: Meine Platinen sind fast alle v3.0, ich hab auch noch eine V2.0 da. Deswegen ist bei mir immer V3 eingestellt, und wenn ich ausliefere und nicht daran denke, das auf V31 zu ändern, steht da V3. Da werde ich wahrscheinlich die Doku ändern. Ich habe auch schon überlegt, für mich eine andere platformio.ini zu machen als die, die ich ausliefere, aber dann besteht die Gefahr, dass meine Entwicklungsumgebung immer mehr von der abweicht, die ihr habt. Das finde ich auch nicht so toll. Grundsätzlich bleibt für die Zukunft wichtig, dass jeder beim Update schaut, dass die eigene Version der Platine da eingetragen ist. Ich werde das nochmal deutlicher in der Anleitung hervorheben.

In der ETS wird mit das Sensormodul-v2.1-20 angezeigt, obwohl ich die -80 importiert habe und auch die 80 Logikkanäle habe ( oder zu haben scheine).

Hier gibt es mehrere Punkte, die ich nicht verstehe... aber erstmal die Fakten:

• Wenn die ETS die Applikationsversion 2.3 anzeigt, dann hast Du auch die 2.3, das ist die mit 80 Kanälen. Das siehst Du auch auf dem ersten Parameter-Bild "Allgemeine Parameter" beim Eintrag "Anzahl verfügbarer Kanäle", da sollte 80 stehen.
• Die Firmware hat IMMER 80 Kanäle, die kleineren Produktdatenbanken habe ich nur dazu gemacht, damit das Programmieren mit der ETS nicht so lange dauert. Du kannst also getrost die 80 Kanäle nutzen.

Jetzt zu dem, was ich nicht verstehe:

• Du hast die v2.3 importiert, auch die v2.3 bekommen, nur der Text des Moduls ist v2.1? Das wäre zwar nicht schlimm, aber ich kann nicht sagen, warum das so ist. Ich kann den Import der ETS nicht beeinflussen. Steht der falsche Text im Katalog? Kannst Du ein screenshot machen?
• Hattest Du vorher schon eine andere Version, z.B. die v2.1 importiert? Vielleicht ist da noch irgendwo ein Bug in der ETS, wenn die Versionen so ähnlich sind?
• Ich werde mal schauen, ob ich ähnliches hier sehe, aber ich hab jetzt so oft importiert (wirklich hunderte Testversionen) und so was bisher noch nicht beobachten können...
• Ist das Problem nachvollziehbar? Sprich: Kannst Du mir Schritte benennen wie
  • ETS starten
  • x importieren
  • y importieren
  • dann x löschen
  • z importieren -> hier ist was falsch? Dann könnte ich selber eher was finden (vielleicht)

Wenn es nur der Text ist, den kannst Du natürlich in den Eigenschaften anpassen. Ausschlaggebend ist immer die Applikationsversion.

Gruß, Waldemar