Alternative Firmware für das Raum-Sensormodul von Masifi

[mumpf]

Nee, paar Tage ist nicht nötig. Normalerweise kommen Werte innerhalb von 6 Stunden, spätestens wenn 100% Kalibriert ist.

Geht es denn um den BME680? Und wie ist er parametriert? Welche Firmware hast Du drauf? Du wärest zumindest der Erste, bei dem der BME680 nicht läuft.

Gruß, Waldemar

[sk73]

Ja sorry
mehr info = mehr Hilfreich zum helfen
Sag ich mien Kunden ja auch immer
Kalibrierstatus war aberr 100%
Na gut ich warte mal ein paar Tage

[mumpf]

sk73 Noch eine Bitte für die Zukunft: Bitte schreibe dazu, um welchen Sensor (Hardware) es sich handelt, was Du erwartest und was Du bekommst... Sonst ist qualifizierte Hilfe nicht wirklich möglich.

Gruß, Waldemar

[Masifi]

Hi
Bei allen wird die Luftqualität nicht ausgegeben alle anderen Werte sind vorhanden. Ich kann sie aber noch nicht beurteilen und habe auch noch kein logging.

Der VOC Sensor benötigt Zeit bis er Werte liefert, daher vielleicht noch etwas warten und dann noch einmal prüfen.

[sk73]

Hi
ich habe nun mal einige meiner Sensoren in Betrieb genommen. Bei allen wird die Luftqualität nicht ausgegeben alle anderen Werte sind vorhanden. Ich kann sie aber noch nicht beurteilen und habe auch noch kein logging.

[jgerhart]

Hallo mumpf,

ich habe gerade festgestellt, dass der CO2 Sensor mit der aktuellen Firmware wohl ab und zu einen unplausiblen Wert liefert:

Screenshot 2022-04-19 190445.jpg

Für C02 ist zyklisches Senden alle 300 s und P = 5 konfiguriert, das könnte bedeuteten, dass der Messwert 0 ist?

Viele Grüße
Jens

[doenke]

Hi Waldemar,

besten Dank für Deine Rückmeldung. Ich werde mir mal angewöhnen das Programmieren grundsätzlich mitzuschneiden. Vielleicht kommen wir der Sache ja auf den Grund.
Da es aber sehr unregelmäßig vorgekommen ist, sollten wir es auch nicht übertreiben.

Ich melde mich, wenn sich etwas Neues ergibt.
Bis dahin,
Sönke

[mumpf]

Hi Sönke,

ich kenne einen reproduzierbaren (und derzeit noch nicht reparierbaren) Fall: Wenn man partiell programmiert, und bei dieser Programmierung einige GA dazukommen (ich weiß nicht wie viele, ich hatte es schon bei nur einer neuen GA, ich hatte es aber auch bei 4 neuen GA und bei 3 nicht). Kann auch bei gleicher GA-Anzahl, aber geänderter KO-Zuweisung passieren. Dann gibt es "hänger", die leider einen Reset erfordern. Ich bin noch am feststellen der genauen Umstände...

Da Du aber sagst, dass es auch passiert ist, weil Du ein ODER in ein UND geändert hast. Das passt absolut nicht in mein bisher bekanntes Fehlerbild. Und das hatte ich bisher lokal auch nicht. Bei einer reinen Parameter-Änderung (also auch so, dass nicht die Meldung kommt, dass bei dieser Änderung jetzt GA entfernt werden) sollte es auf keinen Fall passieren. Hier würde ein Gruppenmonitor-Mitschnitt beim Programmieren zumindest einen Hinweis drauf liefern, bei welcher Operation es abbricht. Ist das immer erst kurz vor dem Ende der Programmierung? Dann hätte ich zumindest noch eine Idee...

Das erste (reproduzierbare) Problem ist nur mit einer Änderung im KNX-Stack zu lösen, das kann ich nicht "mal nebenbei" machen, das wird leider noch einige Zeit dauern, bis sich da was tut, sorry.

Derzeit sehe ich nur die Möglichkeit, immer ganze Applikation programmieren, dann sollte das nicht passieren (melde Dich, wenn doch). Nachteil ist hier eine lange Programmierzeit. Bis zu Deiner Meldung hätte ich auch gesagt, dass man bei einer reinen Parameteränderung auch getrost partiell programmieren kann und nur bei GA/KO-Änderungen die ganze Applikation programmieren sollte, aber da spricht das ODER->UND dagegen.

Das ist zumindest der Stand der Dinge. Eine kurzfristige Lösung ist nicht in Sicht, die Änderung am Stack aber auf dem Weg. Da das aber ein großer "Rework" ist (komplett neue Speicheraufteilung), dauert das noch einige Zeit.

Schreib doch mal, falls Du einen Gruppenmonitor-Mitschnitt von so einem Fall hast oder nähere Infos, wie man das reproduzieren könnte, wir können dann auch gerne eine Online-Session machen und ich schaue mal, ob ich direkt was erkenne (bei einem reproduzierbaren Fall).

Gruß, Waldemar

[doenke]

Guten Morgen Waldemar,

ich habe sporadisch das Problem, dass das Logikmodul kurz vor dem Programmieren abstürzt.
Das ganze ist bei meinen vielen Versuchen mit der Logik insgesamt vielleicht 4 mal aufgetreten, daher ist das nicht so richtig greifbar. Ich dachte, ich melde mich trotzdem mal...

Die bisherige Gemeinsamkeit aller Fälle:
Ich möchte ein Logikmodul mit der ETS neu programmieren, weil ich etwas an der Logik geändert habe. (beim letzten Mal habe ich ein ODER in ein UND geändert)
Die Meldung der ETS ist jeweils: Programmieren (Part.) fehlgeschlagen: Das Gerät antwortet nicht in angemessener Zeit.
Auf Read Requests antwortet das Logikmodul nicht mehr, zyklisches Senden geht auch nicht. Das Gerät scheint tot.


Ich sehe in meiner Temperatur-Datenbank, dass noch wenige Sekunden zuvor Temperaturdaten geschrieben wurden. Das Modul ist also nicht schon lange vorher abgestürzt.
Ein Druck auf den Resetknopf belebt das Gerät wieder und alles funktioniert wieder sauber, inklusive Programmieren.

Einen Mitschnitt des Busmonitors kann ich leider nicht anbieten. Werde mal daran denken, den Busmonitor anzuschalten, wenn ich neu Programmiere.


Ist das irgendein vertrautes Fehlerbild?
Hast Du eine Idee, wie ich den Fehler weiter eingrenzen kann?

Danke schonmal,
Sönke

[mumpf]

Hi mike,

danke für die Info mit multiply-channels. Eigentlich dachte ich auch, dass die master kompatibel ist. Da muss ich mal schauen. Bis dahin bitte nur release (also 2.1.2) verwenden.

Gruß, Waldemar

[mike]

Vielen Dank mumpf! Das hilft mir schon weiter. Der Fingerprint ist unterschiedlich! Bei mir steht 253E.

Edit: Mit neu erzeugter knxprod und identischem Fingerprint funktioniert es dann. Nochmals Danke.

Edit2: Falls die Fragen aufkommen:
Wie konnte eine falsche knxprod erzeugt werden? => Ich hatte nicht die Version 2.1.2 von multiply-channels sondern den aktuellen Master verwendet.

Warum die Master-Version von multiply-channels? => Ich hatte mir multiply-channels angesehen und wollte es erweitern. Daher hatte ich die Master-Version gebaut und noch in meinem bin-Verzeichnis. Ich ging davon aus, dass Master statt 2.1.2 auch OK sein würde.

D.h. typisches RTFM-Problem. Sorry!

[mumpf]

Hi mike ,

Danke für die Rückmeldung. Nur damit ich sicher sein kann, dass Du das Update richtig gemacht hast (was nicht an Dir liegt, das ist eben fehleranfällig):

Kannst Du mal bei dem Gerät->Eigenschaften->Informationen->Applikationsprogramm vergleichen, ob das drin steht:
Sensormodul-v3.8.jpg
Vor allem Gerätetyp und Programmversion sind wichtig.

Und dann noch die Geräteinfo auslesen und schauen, ob da

Firmware-Version: [3] 8.0 steht?

Dann sehen wir weiter, ok?

Gruß, Waldemar

[mike]

Ich habe ein Problem mit der aktuellen Release-Version. Bevor ich da tiefer reindebugge wollte ich fragen ob das irgendwie erklärlich ist.

Hardware ist eine Masifi-Aussenplatine V13 mit SHT31 Sensor.

knxprod wurde neu importiert, Gerät ins Projekt eingefügt und ein vorhandenes Gerät danach aktualisiert. Konfiguriert ist der SHT31 für Temperatur und Feuchtigkeit. Temp/Luftfeuchte soll alle 5 Sekunden gesendet werden.

Das Verhalten ist dann so, dass zum Start "In Betrieb" gesendet, Datum und Uhrzeit vom Bus gelesen wird und dann die Feuchtigkeit mit einem plausiblen Wert gesendet wird. Danach kommt nur noch "In Betrieb" (alle 300s).

Auf "Alle Werte senden"-Anforderung wird die gleiche wie zuerst gesendete Luftfeuchtigkeit gesendet (Also nicht die aktuelle, sondern immer die gleiche). Keine Temperatur.

Auf ein Read-Request auf das Temperatur-Objekt wird mit 0°C geantwortet. Bei Luftfeuchte wird immer mit dem gleichen zuerst gesendeten Wert geantwortet.

Ich habe eine Debug-Ausgabe in SensorSHT3x::getTempHum eingebaut, die rund alle 2 Sekunden eine plausible, sich ändernde Temperatur und Luftfeuchtigkeit ausschreibt.

Änderung der Konfiguration auf "alle 0 Sekunden senden" (also nicht zeitgesteuert sondern bei Änderung) zeigt exakt das gleiche Verhalten.

[Amenophis]

Tausend Dank an Waldemar, der mir in einer persönlichen Session bei den Problemen geholfen hat. Sämtliche Lösungen werden von ihm in die Anleitung eingepflegt. Bei mir war es ein Zusammenspiel aus verschiedenen Dingen aber folgender Hinweis an dieser Stelle. Wer den Projekt Ordner von VSC synchonrisiert mit einer NAS oder so, der kann in Probleme laufen. Diese Synch sollte man besser ausstellen

[Amenophis]

Ich habe jetzt alles in C:\Users\Etien\Documents\PlatformIO\Projects nochmal gelöscht und die Anleitung https://github.com/mumpf/knx-sensor/...x-dev-setup.md von vorne gestartet. Jetzt stimmen die obigen Daten aber ich laufe in einen neuen Fehler. Zum Verrückt werden

> Executing task in folder knx-sensor: C:\Users\Etien\.platformio\penv\Scripts\pio.exe run -e build <

Processing build (platform: atmelsam; board: zeroUSB; framework: arduino)
------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelsam/zeroUSB.html
PLATFORM: Atmel SAM (7.1.0) > Arduino Zero (USB Native Port)
HARDWARE: SAMD21G18A 48MHz, 32KB RAM, 256KB Flash
DEBUG: Current (jlink) External (atmel-ice, blackmagic, jlink)
PACKAGES:
- framework-arduino-samd 1.8.11
- framework-cmsis 1.40500.0 (4.5.0)
- framework-cmsis-atmel 1.2.2
- toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ deep+, Compatibility ~ soft
Found 31 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <SPI> 1.0
|-- <Wire> 1.0
|-- <Adafruit SleepyDog Library> 1.4.0
|-- <Adafruit BME280 Library> 2.1.2
| |-- <Adafruit Unified Sensor> 1.1.4
| |-- <SPI> 1.0
| |-- <Wire> 1.0
|-- <SparkFun SCD30 Arduino Library> 1.0.14
| |-- <Wire> 1.0
|-- <Sensirion I2C SCD4x> 0.3.1
| |-- <Wire> 1.0
| |-- <Sensirion Core> 0.5.2
| | |-- <Wire> 1.0
|-- <VL53L1X> 1.2.1
| |-- <Wire> 1.0
|-- <knx-wire> 3.0.0
| |-- <knx> 1.1.2
| |-- <knx-logic> 3.8.0
| | |-- <knx-sensor> 3.8.0
| | | |-- <knx> 1.1.2
| | | |-- <Wire> 1.0
| | |-- <knx> 1.1.2
| | |-- <Wire> 1.0
| | |-- <Adafruit SleepyDog Library> 1.4.0
| |-- <knx-sensor> 3.8.0
| | |-- <knx> 1.1.2
| | |-- <Wire> 1.0
|-- <knx> 1.1.2
|-- <knx-logic> 3.8.0
| |-- <knx-sensor> 3.8.0
| | |-- <knx> 1.1.2
| | |-- <Wire> 1.0
| |-- <knx> 1.1.2
| |-- <Wire> 1.0
| |-- <Adafruit SleepyDog Library> 1.4.0
|-- <knx-sensor> 3.8.0
| |-- <knx> 1.1.2
| |-- <Wire> 1.0
Building in release mode
Compiling .pio\build\build\src\Sensormodul.cpp.o
Compiling .pio\build\build\src\main.cpp.o
Compiling .pio\build\build\libf78\SPI\SPI.cpp.o
src\Sensormodul.cpp:1:10: fatal error: Helper.h: No such file or directory

************************************************** **************
* Looking for Helper.h dependency? Check our library registry!
*
* CLI > platformio lib search "header:Helper.h"
* Web > https://platformio.org/lib/search?query=header:Helper.h
*
************************************************** **************

#include "Helper.h"
^~~~~~~~~~
compilation terminated.
Compiling .pio\build\build\libe9c\Wire\Wire.cpp.o
Compiling .pio\build\build\lib0b7\Adafruit SleepyDog Library@1.4.0\Adafruit_SleepyDog.cpp.o
Compiling .pio\build\build\lib0b7\Adafruit SleepyDog Library@1.4.0\utility\WatchdogAVR.cpp.o
Compiling .pio\build\build\lib0b7\Adafruit SleepyDog Library@1.4.0\utility\WatchdogKinetisK.cpp.o
*** [.pio\build\build\src\Sensormodul.cpp.o] Error 1
Compiling .pio\build\build\lib0b7\Adafruit SleepyDog Library@1.4.0\utility\WatchdogKinetisL.cpp.o
In file included from C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/SafeRingBuffer.h:24:0,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/Uart.h:23,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\variants\arduino_zero/variant.h:43,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/Arduino.h:48,
from C:\Users\Etien\Documents\PlatformIO\Projects\knx\s rc/knx/bits.h:36,
from C:\Users\Etien\Documents\PlatformIO\Projects\knx\s rc/knx_facade.h:3,
from C:\Users\Etien\Documents\PlatformIO\Projects\knx\s rc/knx.h:86,
from src\main.cpp:1:
C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/api/RingBuffer.h:33:0: warning: "SERIAL_BUFFER_SIZE" redefined
#define SERIAL_BUFFER_SIZE 64

<command-line>:0:0: note: this is the location of the previous definition
src\main.cpp:3:10: fatal error: Hardware.h: No such file or directory

************************************************** ****************
* Looking for Hardware.h dependency? Check our library registry!
*
* CLI > platformio lib search "header:Hardware.h"
* Web > https://platformio.org/lib/search?query=header:Hardware.h
*
************************************************** ****************

#include "Hardware.h"
^~~~~~~~~~~~
compilation terminated.
In file included from C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/SafeRingBuffer.h:24:0,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/Uart.h:23,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\variants\arduino_zero/variant.h:43,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/Arduino.h:48,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\libraries\SPI\SPI.h:23,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\libraries\SPI\SPI.cpp:20:
C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/api/RingBuffer.h:33:0: warning: "SERIAL_BUFFER_SIZE" redefined
#define SERIAL_BUFFER_SIZE 64

<command-line>:0:0: note: this is the location of the previous definition
*** [.pio\build\build\src\main.cpp.o] Error 1
In file included from C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/SafeRingBuffer.h:24:0,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/Uart.h:23,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\variants\arduino_zero/variant.h:43,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/Arduino.h:48,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\libraries\Wire\Wire.cpp:24:
C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/api/RingBuffer.h:33:0: warning: "SERIAL_BUFFER_SIZE" redefined
#define SERIAL_BUFFER_SIZE 64

<command-line>:0:0: note: this is the location of the previous definition
In file included from C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/SafeRingBuffer.h:24:0,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/Uart.h:23,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\variants\arduino_zero/variant.h:43,
from C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/Arduino.h:48,
from C:\tmp\libdeps\build\Adafruit SleepyDog Library@1.4.0\utility/WatchdogSAMD.h:4,
from C:\tmp\libdeps\build\Adafruit SleepyDog Library@1.4.0\Adafruit_SleepyDog.h:17,
from C:\tmp\libdeps\build\Adafruit SleepyDog Library@1.4.0\Adafruit_SleepyDog.cpp:27:
C:\Users\Etien\.platformio\packages\framework-arduino-samd\cores\arduino/api/RingBuffer.h:33:0: warning: "SERIAL_BUFFER_SIZE" redefined
#define SERIAL_BUFFER_SIZE 64

<command-line>:0:0: note: this is the location of the previous definition
================================================== == [FAILED] Took 7.84 seconds ================================================== ==
Environment Status Duration
------------- -------- ------------
build FAILED 00:00:07.836
============================================== 1 failed, 0 succeeded in 00:00:07.836 ==============================================
Der Terminalprozess "C:\WINDOWS\System32\WindowsPowerShell\v1.0\powers hell.exe -Command C:\Users\Etien\.platformio\penv\Scripts\pio.exe run -e build" wurde mit folgendem Exitcode beendet: 1.