Kontinuierliche Verbesserungen des Terkin-Datenloggers (600er)

habe die DS18B20-Kalibrierdiskussion mal verschoben - und zwar in jenes topic, das Ihr vor zwei Monaten dazu schon hattet:


Edit by @Andreas: Ein ensprechender Eintrag wurde auch oben im Backlog hinzugefügt.

1 Like

Neben dem Wartungsmodus für den Terkin-Datenlogger gibt es nun auch die

im head. Vielen Dank für Eure Rückmeldungen zu den fehlenden Funktionalitäten. Ping @MKO, @clemens und @waggi. Ich hoffe Ihr müsst nun nicht mehr so viel umstecken und habt dadurch weniger Schmerzen bei der sukzessiven halb-hybriden Inbetriebnahme, weil nun hoffentlich möglichst viel über IP geht und man so den Datenlogger verschraubt im Garten-Netzwerk unter der Beute liegenlassen kann – sofern das so gut in Euer Szenario passt.

IP-based sandbox operations

Das hatte ich bereits probiert, dort müsste noch eine Art Authentifizierung fehlen. Er bleibt auf alle fälle direkt nach der ersten Kontaktaufnahme noch vor Repl … stehen. ins Blaue getippt müsste sowas wie export MCU_SERIAL_PORT=micro:python@192.168.178.20 sein hab ich aber noch nicht getestet.

Vielen Dank für die Analyse. Daher hakte es wohl bei mir :P. Mit den aktuellsten Änderungen sollte es jetzt klappen.

$ export MCU_PORT=192.168.178.168
$ make console
Connecting via telnet to 192.168.178.168. Please enter User: micro, Password: python
expect -c 'spawn telnet 192.168.178.168; expect "*?ogin as:*"; sleep 0.2; send -- "micro\r"; expect "*?assword:*"; sleep 0.2; send -- "python\r"; interact;'
spawn telnet 192.168.178.168
Trying 192.168.178.168...
Connected to 192.168.178.168.
Escape character is '^]'.
MicroPython v1.9.4-0a38f88 on 2019-05-14; FiPy with ESP32
Login as: micro
Password:
Login succeeded!
Type "help()" for more information.

>>> from terkin import __appname__, __version__; print(__appname__, __version__)
terkin-datalogger 0.5.1

:warning: Hinweis: Die Umgebungsvariable heißt ab sofort MCU_PORT, die Abwärtskompatibilität zu MCU_SERIAL_PORT sollte jedoch erhalten geblieben sein.

Konfiguration

'ds18x20': {
    'bus': 'onewire:0',
    'devices': {
        '28ff641d8fdf18c1': {
            'enabled': False,
            'offset': 0.42,
        },
        '28ff641d8fc3944f': {
            'enabled': True,
            'offset': -0.42,
        },
    }
}

Die Konfiguration ist derzeit leider leicht redundant zur sensor_telemetry_map. Wir bitten um Verständnis.

Ausgabe

   32.3776 [terkin.datalogger        ] INFO   : Reading sensor port "DS18X20Sensor"
   32.3964 [hiveeyes.sensor_ds18x20  ] INFO   : Acquire readings from all DS18X20 sensors attached to bus onewire:0
   32.4157 [hiveeyes.sensor_ds18x20  ] INFO   : Skipping DS18X20 device 28ff641d8fdf18c1
   32.4348 [hiveeyes.sensor_ds18x20  ] INFO   : Reading DS18X20 device 28ff641d8fc3944f
   33.2526 [hiveeyes.sensor_ds18x20  ] INFO   : Adding offset -0.42 to value 21.875 from sensor 28ff641d8fc3944f

Ist nun auch mit dabei.

Hammer!
Ein entscheidender Meilenstein in Sachen Updates und Konfiguration im laufenden “Feld”- Einsatz.
Hab gestern Abend noch ein wenig ohne Erfolg Recherchiert wie es funktionieren könnte, und Du kommst schon mit der Lösung raus.
Bin Begeistert und enttäuscht zugleich, da ich die neue Funktionalität nicht gleich testen kann. Bin leider bis zum Wochenende unterwegs.

Genial! Danke

Super!

Ihr legt Mal wieder ein Wahnsinns Tempo vor, ich glaub ich werd zum Fan :rofl:

Das hatte bisher bei einigen schlimme Schmwerzen bereitet, ja. Vielen Dank für Eure Impulse. Ich hoffe nun klappt alles stromlinienförmiger bei der Inbetriebnahme.

Newsflash.

Update dependencies

Bei den aktuellen Inhalten im Repository hat sich gestern etwas an den Abhängigkeiten geändert. Um diese auf den aktuellen Stand zu bringen, hilft ein beherztes

git pull
make refresh-requirements

Das holt a) die aktuellen Abhängigkeiten aus dem Netz und füllt damit v.a. das lokale dist-packages-Verzeichnis im working tree und b) installiert sie korrekt auf dem per MCU_PORT adressierten Gerät. Das dist-packages-Verzeichnis auf dem Gerät wird dabei vorher platt gemacht, damit keine Divergenzen entstehen.

Changes to configuration settings

Auch ein Teil der Konfiguration hat sich geändert. Um Wartungsmodus für den Terkin-Datenlogger Rechnung zu tragen, kann man nun beide (Pseudo-)Intervalle konfigurieren – einmal das Meßintervall im Feld und einmal im Wartungsmodus.

Die Funktionalität ist aber abwärtskompatibel. Auch mit einer bisherigen settings.py sollte nichts schiefgehen. In diesem Fall wird für main.interval.maintenance 5.0 Sekunden angenommen.

# General settings.
main = {

    # Measurement intervals in seconds.
    # Todo: Please note this is not the _real thing_ yet at it will just use
    #       this value to apply to ``time.sleep()`` after each duty cycle.
    'interval': {
        
        # Use this interval if device is in field mode.
        'field': 5.0,
        
        # Apply this interval if device is in maintenance mode.
        # https://community.hiveeyes.org/t/wartungsmodus-fur-den-terkin-datenlogger/2274
        'maintenance': 2.0,
    },

    # ....
}
1 Like

More convenience.

MAC address formatting

Überblick

Die Ausgabe sollte möglichst immer im Format 80:7d:3a:c2:de:45 passieren, wie von ifconfig oder ip addr gewohnt. Die Eingabe sollte aus Komfortgründen beliebig sein können.

Firmware

Die MAC-Adressen des ESP32-WiFi Interfaces werden im Log folgendermaßen ausgegeben.

   15.9066 [terkin.network.wifi] INFO: 
           WiFi STA: Networking address (MAC): {'ap_mac': '80:7d:3a:c2:de:45', 'sta_mac': '80:7d:3a:c2:de:44'}

Tooling

Bei der Angabe eines bestimmten Geräts für den Wartungsmodus sind beliebige Formate möglich, z.B.

sudo python3 tools/terkin.py maintain 80-7D-3A-C2-DE-44
2019-07-12 16:12:41,207 [tools/terkin.py] INFO   : Waiting for any devices having MAC address prefixes of ['80:7d:3a:c2:de:44'] to appear on your local network
...
2019-07-12 16:12:59,259 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c2:de:44', 'ip': '192.168.178.44'}
2019-07-12 16:12:59,260 [tools/terkin.py] INFO   : Connecting to device mode server at 192.168.178.44:666
2019-07-12 16:12:59,260 [tools/terkin.py] INFO   : Pulling 192.168.178.44 into maintenance mode

Referenzen

1 Like

Unabhängig von [Backlog] Terkin-Datenlogger für BOB haben wir einige neue Themen auf den Tisch bekommen. Dieser Eintrag ist ein Wiki und kann gerne ggf. um weitere Details ergänzt werden.

SD/MMC Faktensammlung

Verbesserungen am HX711-Treiber

Cycling faster aka. Radeln mit Rückenwind

  • Auf Basis des MicroTerkin Agent wollen wir eine effizientere Übertragung der Quelltextdateien im Entwicklungsmodus per FTP ermöglichen.

Weitere Details

2 posts were merged into an existing topic: Strom sparen beim Einsatz der MicroPython-Firmware im Batteriebetrieb

Wie gesagt es würde viel ermöglichen. Man könnte z.B. Wetterdaten seperat an eine andere offentlicheres Ziele übertragen oder sogar die Balkon Imker variante mit 2 Beuten und nur einem Node nach Beep oder anderen zielen ermöglichen.
Auch werden Aktuell viele unnötige Daten, was System und Gewicht usw. angeht, übertragen was bei geringer Datenbandbreite Probleme und/oder höhere Betriebskosten verursachen würde.

1 Like

9 posts were merged into an existing topic: Troubleshooting the Sequans Modem on Pycom devices

On WSL I get, so in your instruction is an install command for lftp missing

root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# make install-ftp
lftp -u micro,python 192.168.178.26 < tools/upload-all.lftprc
/bin/sh: 1: lftp: not found
Makefile:57: recipe for target 'install-ftp' failed
make: *** [install-ftp] Error 127

So you should add
sudo apt-get install lftp

in the doc

1 Like

Watchdog updates

The watchdog subsystem has been improved through Improve Watchdog subsystem by adjusting to edge cases · hiveeyes/hiveeyes-micropython-firmware@1c7abf9 · GitHub so the watchdog timer is now adjusted for things like LTE modem deinit as well as the infamous maintenance mode. In practice, it looks like that.

Compensate for six seconds of LTE spinup/teardown

To be safe here, we propose a watchdog timeout of 15 seconds for covering the extended time the LTE modem needs to rest and mumble and crumble. When the configured watchdog timeout is lower than anticipated, the firmware takes account of that by bumping the value temporarily.

10.1499 [terkin.device            ] INFO   : Reset cause and wakeup reason: {'reset_cause': {'code': 0, 'message': 'PWRON'}, 'wakeup_reason': {'code': 0, 'message': 'PWRON'}}
10.1682 [terkin.watchdog          ] INFO   : Starting the watchdog timer (WDT) with timeout 10000ms
10.2253 [terkin.watchdog          ] INFO   : Reconfiguring watchdog timeout to 15000 milliseconds
10.2363 [terkin.device            ] INFO   : Turning off LTE modem
10.2470 [terkin.device            ] INFO   : Turning off LTE modem on boot
10.2577 [terkin.device            ] INFO   : Invoking LTE.deinit()
16.8252 [terkin.device            ] INFO   : Turning off Bluetooth
17.3399 [terkin.watchdog          ] INFO   : Resuming watchdog
17.3567 [terkin.watchdog          ] INFO   : Reconfiguring watchdog timeout to 10000 milliseconds
17.3713 [terkin.datalogger        ] INFO   : Starting BOB MicroPython Datalogger 0.5.1

Adjust watchdog timeout when lower than or near sleep time

When running without deep sleep, the watchdog timeout has to be adjusted to the measurement interval / duty cycle appropriately.

28.0322 [terkin.device            ] INFO   : Entering light sleep for 15.0 seconds
28.0489 [terkin.watchdog          ] WARNING: Reconfiguring original watchdog timeout 10.0 as it is smaller or near the configured sleep time 15.0
28.0650 [terkin.watchdog          ] INFO   : Reconfiguring watchdog timeout to 35000 milliseconds

Suspend watchdog when running in maintenance mode

The watchdog can’t be stopped once it’s started. So we “suspend” it by configuring the timeout to a reasonable large value when running in maintenance mode.

26.3070 [terkin.network.core      ] INFO   : Enabling maintenance mode
26.3223 [terkin.watchdog          ] INFO   : Suspending watchdog
26.3401 [terkin.watchdog          ] INFO   : Reconfiguring watchdog timeout to 999999999 milliseconds

Thanks

@pinguin was the first one who brought this to our attention and gave us an idea about how to care about that detail. Taking care of that is crucial for piece of mind to protect against eventual crashes in production.

Thanks a bunch!

1 Like

More updates.

Device discovery

@clemens makes Windows users happy with Change timeout value for ARP-Ping when pulling device into maintenance mode by ClemensGruber · Pull Request #14 · hiveeyes/hiveeyes-micropython-firmware · GitHub. Thanks!

Device provisioning

We closed some gaps by adding another helper

make connect-wifi ssid=<YourNetwork> password=<YourPassword>

to bring a device into the local network which has just been unboxed, see also Speed up provisioning and Makefile.

Sandbox improvements

@roh asked for some entry-level guide in form of a self-documenting Makefile and had strong opinions about a colored output. Et voilà.

All the details of "make help"
$ make
Available rules:

setup                         Prepare sandbox environment and download requirements
terkin-agent                  Run the MicroTerkin Agent, e.g. "make terkin-agent action=maintain"
connect-wifi                  Load the MiniNet module to the device and start a WiFi STA connection.
ip-address                    Load the MiniNet module to the device and get IP address.
install                       Install all files to the device, using rshell
install-ftp                   Install all files to the device, using FTP
install-ng                    Install all files to the device, using best method
install-pycom-firmware        Install Pycom firmware on device
format-flash                  Format flash filesystem with LittleFS
erase-fs                      Erase flash filesystem
list-serials                  List all serial interfaces
list-boards                   List all MicroPython boards
device-info                   Inquire device information
console                       Open console over serial or telnet
rshell                        Run interactive rshell on the device
repl                          Run interactive REPL on the device
reset-device                  Send reset command to device
reset-device-attached         Send reset command to device and keep the REPL shell attached

Bits and pieces

As always, a number of other improvements and bugfixes have been made. Thanks to all who contributed to that and enjoy the changelog.

2 Likes

Mit diesen Änderungen wurde gerade die Struktur des sensors-Abschnitt in der Konfigurationsdatei settings.example-bob.py geändert. Den Bereich "sensors.registry" gibt es nicht mehr, die Struktur auf Detailebene der Sensoreinträge ist zwar die gleiche geblieben, die Einträge wurden aber erweitert und auf die Anforderungen aus HTTP- und webbasierte Konfiguration für Terkin-Datenlogger (captive portal) vorbereitet.

Am besten man übernimmt die Änderungen 1:1 aus dem neuen Bereich "sensors.environment" der Blaupause, schaut dann nochmal über die selbst getätigten Einstellungen im Bereich "sensors.registry" drüber, übernimmt ggf. abweichende Einstellungen und löscht letzteren dann.

Falls die Rückwärtskompatibiliät (untested!) funktioniert, könnte es auch mit der alten Konfiguration funktionieren. Davon raten wir jedoch ab, weil neue Endpunkte der HTTP API die neue Konfigurationsstruktur voraussetzen werden.

Versuche gerade 2 BME280 an bus : i2c:0 zu betreiben.
allerdings habe ich probleme mit der in Settings.example.py vorgeschlagenen config.
wenn ich

 'bme280_1': {
        'enabled': True,
        'bus': 'i2c:0',
        'address': 0x76,
    },
 'bme280_2': {
        'enabled': True,
        'bus': 'i2c:0',
        'address': 0x77,
    },

Versuche wird gar kein Sensor erkannt.
wenn ich einen der beiden wie in der settings.example-bob.py

bme280': {

wird nur dieser Sensor erkannt. wenn ich beide so nenne wird der erste Sensor von dem 2. überschrieben.

werde gleich nochmal

'bme280': {{
        'enabled': True,
        'bus': 'i2c:0',
        'address': 0x76,
    },
    {
        'enabled': True,
        'bus': 'i2c:0',
        'address': 0x77,
    }},

testen. Befürchte aber, das das auch fehl schlägt.
jemand einen Tip?
Ich habe bisher noch nicht die stelle im code gefunden wo die einzelnen BME280 im Code erkannt werden.
wenn ich nach der datalogger.py zeile 114 gehe dürfte nur ‘BME280’ erkannt werden
bin jetzt noch nicht in Python so firm, da ein ‘BME280**’ draus zu machen.

Jeder Sensor am i2c-Bus muss eine eigene Adresse haben, sonst kann man sie nicht auslesen. Die BME280-Boards der Uni Bremen haben fest 0x77, kleinere von AZ-Delivery 0x76. Die Adresse ist nur durch Löten änderbar. Vielleicht gibt es ja andere breakout-Boards, bei denen die Adresse per Jumper einstellbar ist, wie z.B. beim AD-Wandler ADS1115, der mit einem AdressPin auf 4 Adressen einstellbar ist.
Fazit: wenn man mit mehreren BME280 an einem I2C-Bus messen will, müssen sie verschiedene Adressen haben.