Alternative Firmware für das Raum-Sensormodul von Masifi

[beatboxking]

Hallo zusammen,

ich hab jetzt mein erstes Raumsensormodul von Masifi (V3.1) fertiggestellt und wollte die Firmware aufspielen. Folgende Fehlermeldung bekomme ich beim Upload:

...
Configuring upload protocol...
AVAILABLE: atmel-ice, blackmagic, jlink, sam-ba
CURRENT: upload_protocol = sam-ba
Looking for upload port...
Error: Please specify `upload_port` for environment or use global `--upload-port` option.
For some development platforms it can be a USB flash drive (i.e. /media/<user>/<device name>)
*** [upload] Explicit exit, status 1
================================================== == [FAILED] Took 12.57 seconds ================================================== ==

Environment Status Duration
------------- -------- ------------
build IGNORED
debug IGNORED
uploadUSB FAILED 00:00:12.565
uploadJLINK IGNORED
uploadATMEL IGNORED
=============================================== 1 failed, 0 succeeded in 00:00:12.565 ===============================================
The terminal process "C:\WINDOWS\system32\cmd.exe /d /c C:\Users\Björn\.platformio\penv\Scripts\pio.exe run -e uploadUSB --target upload" terminated with exit code: 1.


Kann mir jemand verraten, wo man den Upload Port konfigurieren kann und was man da eintragen muss?

Danke und viele Grüße
Björn

[mumpf]

Hi,

Masifi hat bei V3.1 einen Pin geändert, und es ist ausgerechnet der Prog-Pin. Somit kann meine Firmware nicht laufen. Es gab da einen Wechsel von Pin 11 auf 12. Eine "Quick-and-Dirty" Anpassung, damit es erstmal läuft:

Im File knx-common/src/Hardware.h:

...
#ifdef BOARD_MASIFI_V3
#define PROG_LED_PIN 13
#define PROG_LED_PIN_ACTIVE_ON HIGH
#define PROG_BUTTON_PIN [COLOR=#e74c3c]12[/COLOR]
...

(die 11 in 12 ändern). Dann neu bauen und Firmware aufspielen.

Einge richtige Korrektur kommt noch, dann wird es ein BOARD_MASIFI_V31 geben.

Gruß, Waldemar

P.S.: Ah, Masifi hatte auch schon geantwortet...

[Masifi]

-DBOARD_MASIFI_V3 müsste
-DBOARD_MASIFI_V3.1 heißen
falls es Waldemar schon in die Firmware aufgenommen hat.

[Masifi]

Bei V3.1 muss der ProgButton von D11 auf D12 gelegt werden.

[mpl1337]

Hallo,

Habe heute mal die Hardware3.1 testen wollen und hab die Firmware eingespielt.

Jedoch leuchtet die LED beim betätigen der prog led nicht auf.

im Serial kommt auch kein Ton an...

Build Platform IO:

Building in release mode
Checking size .pio\build\build\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [== ] 21.4% (used 7008 bytes from 32768 bytes)
Flash: [====== ] 55.6% (used 145804 bytes from 262144 bytes)
================================================== =============================================== [SUCCESS] Took 22.80 seconds ================================================== ===============================================

Environment Status Duration
------------- -------- ------------
build SUCCESS 00:00:22.801
debug IGNORED
uploadUSB IGNORED
uploadJLINK IGNORED
uploadATMEL IGNORED
================================================== ================================================ 1 succeeded in 00:00:22.801 ================================================== ================================================

Upload USB knx-sensor:

[============================ ] 95% (2176/2279 pages)
[============================= ] 98% (2240/2279 pages)
[==============================] 100% (2279/2279 pages)
done in 0.953 seconds

Verify 145804 bytes of flash with checksum.
Verify successful
done in 0.082 seconds
CPU reset.
================================================== =============================================== [SUCCESS] Took 12.43 seconds ================================================== ===============================================

Environment Status Duration
------------- -------- ------------
build IGNORED
debug IGNORED
uploadUSB SUCCESS 00:00:12.426
uploadJLINK IGNORED
uploadATMEL IGNORED
================================================== ================================================ 1 succeeded in 00:00:12.426 ================================================== ================================================

build_flags = 
  -Wno-unknown-pragmas 
  -Wno-switch
  -DSMALL_GROUPOBJECT
  -DSENSORMODULE
  -L../knx-common/src/bsec/cortex-m0plus
  -lalgobsec
  -DBOARD_MASIFI_V3
  ;-DCRYSTALLESS
monitor_speed = 115200

beim betätigen der Reset Taste blinkt einmal die Status LED auf. Auf der Konsole kommt nichts an

woran kann das liegen?

[mumpf]

Hi,

ich wollte nur kurz Feedback zum Firmware-Release 2.0.0 geben (Zeitschaltuhr-Release). Mein Test hat relativ gut funktioniert, folgendes ist rausgekommen:

• Feiertage werden korrekt berechnet und auf dem Bus gemeldet
• Urlaub/Feiertage werden korrekt bei den Zeitschaltpunkten ausgewertet
• Zeit läuft mit geringen Abweichungen, ca. +-1 Sekunde pro Tag, es würde somit reichen, 1 mal/Woche die Zeit auf den Bus zu schicken.
• Schaltzeitpunkte werden korrekt ausgeführt
• Zeitschaltuhren funktionieren gut mit restlichen Logiken

Die Sachen, die nicht so gut laufen:

• Sonnenauf- und -untergang entsprachen vor 60 Tagen exakt den Internet-Werten (+- 5 Sekunden), inzwischen liegen sie ca. 5 Minuten daneben. Mein Algorithmus hier scheint nicht perfekt zu sein, da ich derzeit noch keinen besseren habe, wird der erstmal bleiben. Ich beobachte die Abweichungen weiter, in der Praxis ist es aber egal, ob die Schaltpunkte 5 Minuten früher oder später auslösen. Das ist nicht schön, aber für mich erstmal kein Grund, das Release aufzuhalten.
• Nachholen der Schaltzeit nach Neustart: Das ist leider der Killer. Es funktioniert gar nicht, weil ich nicht korrekt mit den Zeiten rechne. Und leider hab ich intern auf das falsche Pferd gesetzt und eigene Rechenverfahren für Zeit implementiert, die auch fehleranfällig sind. Der Grund war aber Speicherplatz zu sparen, denn 80 Kanäle * 8 Schaltpunkte * 8 Byte pro Schaltpunkt macht 5120 Byte, und die hab ich nicht mehr frei... Ich muss also neu implementieren und mir was einfallen lassen...

Langer Rede kurzer Sinn: Ich halte die Funktion für wichtig und sie ist fehlerhaft. Ich muss sie neu implementieren und das verzögert das Release um mindestens 4 Wochen.

Sorry für die schlechten Nachrichten,
Gruß, Waldemar

[Sisamiwe]

ich versuche seit Deiner Meldung, das nachzuvollziehen... bei mir ist das zyklische senden noch nicht hängen geblieben. Hast Du irgendeinen Tipp, über welchen Zeitraum wir reden? Stunden, Tage, Wochen? Im Coding hab ich nichts gefunden, was dafür sprechen könnte. Wenn, dann würde das zyklische senden für alle KO weg bleiben müssen, nicht nur für einen Wert...

Hi,

Bislang ist es auch nicht wieder vorgekommen.
Vielleicht hatte ich auch etwas falsch gemacht.

Beste Grüße
Michael

[mumpf]

Ich habe eine V1 mit einem BME280 in Betrieb. Hier habe ich beobachtet, dass das zyklische Senden (der Luftfeuchtigkeit) sporadisch hängen bleibt, sprich keine Werte mehr gesendet werden.

Hi,

ich versuche seit Deiner Meldung, das nachzuvollziehen... bei mir ist das zyklische senden noch nicht hängen geblieben. Hast Du irgendeinen Tipp, über welchen Zeitraum wir reden? Stunden, Tage, Wochen? Im Coding hab ich nichts gefunden, was dafür sprechen könnte. Wenn, dann würde das zyklische senden für alle KO weg bleiben müssen, nicht nur für einen Wert...

Zu 2.0 wird es hierfür wohl noch keine Korrektur geben...

Gruß, Waldemar

[Sisamiwe]

Ich muss mir dazu noch was überlegen, eventuell wird zu 2.0 (was ja eigentlich schon fertig ist und nur noch getestet wird) nur ein "entweder-oder" möglich sein.

Vorschlag: Wenn man auf der Parameterseite in der ETS ein Wert bei "lokaler Höher über NN" ein Wert steht wird dieser verwendet und damit der Wert umgerechnet auf NN gesendet. Steht kein Wert drin, wir der direkte Messwert gesendet. Damit geht beides mit sinnvollem "oder".

[mumpf]

Hi,

Es würde aber für V2.0 reichen.

das ist gut, dann kann ich das in Ruhe machen. Wenn die Tests über Pfingsten und in den Pfingstferien gut gehen, dann werde ich das danach auch freigeben.

Meinst Du es macht Sinn, beide Werte (also lokal und auf NN umgerechnet) zur Verfügung zu stellen?

Jein... Ich habe bei solchen Ausgaben immer ein Problem: Welcher Wert wird für die Sendebedingungen herangezogen (also für Senden bei absoluter oder relativer Abweichung). Um die Bedingungen für beide anzugeben, habe ich keinen Platz mehr (im Speicher) bzw. dann wäre das ein Riesenumbau, den ich derzeit nicht machen will.

Das gleiche Problem stellt sich bei https://knx-user-forum.de/forum/%C3%...26#post1507026 (Originalwerte der Sensoren senden bei Verrechnung mit externen Werten). Hier fällt allerdings eine Lösung über Formelfunktionen im Logikmodul aus.

Ich muss mir dazu noch was überlegen, eventuell wird zu 2.0 (was ja eigentlich schon fertig ist und nur noch getestet wird) nur ein "entweder-oder" möglich sein.

Gruß, Waldemar

[mumpf]

Die Möglichkeit, die Logik-Operation auf "keine" zu stellen, ist dazu gedacht, einen Logik Kanal zu deaktivieren, ohne dass alle Parameter verloren gehen. Ist praktisch bei der Fehlersuche, wenn man komplizierte Logiken macht.

Das werde ich aber in der Firmware 2.0 besser machen. Dann gibt es eine Checkbox zum deaktivieren des Kanals.

Freut mich, das es jetzt klappt.

Gruß, Waldemar

[Sisamiwe]

Hallo Waldemar mumpf,

nun noch meine Rückmeldung zum Thema "Luftdruck auf Meereshöhe".

So wie ich die Temperaturschätzung verstehe, bräuchte ich die Außentemperatur und nicht die Innentemperatur, oder?

Um korrekt zu sein, sollte man die Außentemperatur nutzen. Ich habe noch etwas recherchiert und als Näherung wird oft die Jahresdurchschnittstemp von 15°C verwendet. Du könntest das auch so machen.
Im SmellyOne von dreamy1 mit der SW-Unterstützung von WagoKlemme sollte die Umrechnung des lokal gemessenen Luftdruck auf den entsprechenden Luftdruck auf Meereshöhe auch inkludiert sein. Ggf. können die beiden auch einen Hinweis geben.

Die Höhe, auf der ich gerade messe, fließt die positiv oder negativ in die Formel mit ein? Ich hätte positiv erwartet, aber bei dem einen Rechner (vereinfachte Form) erschien mir der Wert plausibler, als ich den negativen Höhenwert genommen habe...

Die Seehöhe, auf der sich der Sensor befindet, fliesst positiv in die Rechnung ein. Warum? Mit zunehmender Höhe fällt der Luftdruck, also muss, wenn man den lokalen Luftdruck an einem Ort über Seehöhe auf Seehöhe umrechnet, höher sein. Ein Beispiel: Mein Wohn- bzw Messort liegt auf 435m. Ich messe einen lokalen Luftdruck von 960mBar. Umgerechnet auf Seehöhe mit 0m Höhe ergibt sich ein entsprechender Luftdruck (auf Meereshöhe) von 1010,55 mbar.

Ich sehe mal zu, dass ich das am Wochenende einbaue, ist ja nicht so schwer. Allerdings dann nur mit Innentemperatur. Und im ersten "Wurf" wird die Höhe nur im Coding einzugeben sein (schreib ich dann in die Anleitung), erst die v2.0.0 (Zeitschaltuhr-Version) hat in der ETS eine Parameter-Seite, wo solche Eingaben reinpassen.

Ich freue mich schon, dass Du das mit einbauen willst. Es würde aber für V2.0 reichen. Meinst Du es macht Sinn, beide Werte (also lokal und auf NN umgerechnet) zur Verfügung zu stellen?

Beste Grüße
Michael

[Sisamiwe]

Hallo Waldemar mumpf,

Zu A) Sollte natürlich so nicht sein. Ein guter Hinweis ist, dass ein "Alle Werte anfordern" es wieder richtet. Welches Zeitintervall hast Du eingestellt? Und wie oft passiert es denn, dass es ausfällt? Alle paar Stunden? Tage? Wochen? Ich will nur wissen, was ich bei mir im Test einstellen muss und wie lange ich warten muss, bis es auftreten sollte. Könntest Du beim nächsten Vorkommen ein Lesetelegramm an die GA senden und schauen, ob der Wert anders ist als der zuletzt gesendete? Würde mir helfen herauszufinden, ob das Problem beim Messen oder beim Senden liegt. Wie lange die Korrektur dauert, kann ich nicht sagen, ich muss das erstmal irgendwie nachvollziehen können.

Als Workaround kannst Du Dir mit der Logik einen Watchdog bauen (nehmen wir mal an, Dein Sendeintervall ist 5 Minuten):

• Logik ODER, triggert bei jedem Eingangstelegramm
• Ein Eingang, DPT9, Wertintervall 0-100 (also immer true)
• Ausgang Treppenlicht, 15 Minuten, kann verlängert werden, kann nicht ausgeschaltet werden
• Ausgang sendet bei EIN: nichts
• Ausgang sendet bei AUS: Ein EIN-Signal
• An den Eingang legst Du die GA von der Luftfeuchte
• Der Ausgang bekommt die GA von "Alle Werte anfordern".

Wenn 15 Minuten lang keine Luftfeuchte gesendet wurde, fällt das Treppenlicht auf AUS und sendet ein "Alle Werte anfordern". Danach sollte es ja wieder gehen...

Ich habe diese Logik mal angelegt und werde das Verhalten beobachten. Dazu melde ich mich wieder, wenn ich etwas herausgefunden habe.

Danke Dir.

[Sisamiwe]

Hallo mumpf, Masifi

Hmmm, da bin ich ratlos. Ich schreib jetzt mal alle ETS-Schritte, die ich brauche, um ein Piep zu entlocken. Ich gehe von einem Logikkanal mit Standardeinstellungen aus:

• Logik
  • Beschreibung des Kanals: Test Piep
  • Logik-Operation: ODER
  • Eingang 1: normal aktiv
  • Logik sendet ihren Wert weiter: Bei jedem Eingangstelegramm
• Eingang
  • einfach so lassen
• Ausgang
  • Wert für EIN senden: Tonwiedergabe (Buzzer)
  • Wert für EIN senden als: Ton laut einschalten
  • Wert für AUS senden: Tonwiedergabe (Buzzer)
  • Wert für AUS senden als: Ton ausschalten
• Eingangs-KO bekommt dann noch eine GA zugewiesen

Ich habe meine Einstellung nochmal geprüft und festgestellt, dass ich die Logikoperation so nicht gesetzt habe.
Wenn man es genau so macht, wie hier von Dir beschrieben, geht es.
DANKE. Alles gut.

[mumpf]

Hi,

Masifi: Da ich natürlich davon ausgehe, dass meine Software funktioniert, dachte ich eher an eine Hardware-Überprüfung

Sisamiwe: Du kannst ja mal den kleinen Sketch von Masifi ausprobieren. Wenn es da nicht piept, bin ich raus...

Aber der Vollständigkeit halber: Du hast schon einen Buzzer auf der Zwischenplatine, oder? Sieht so aus wie auf dem Bild https://knx-user-forum.de/forum/%C3%...04#post1479204 in der Mitte, das runde schwarze Ding...

Sorry, falls Du die Frage zu blöd findest, aber ich bin durch meinen Job starkt Support geschädigt und hab da sehr viel erlebt... Ich will nur helfen.

Gruß, Waldemar