$ mosquitto_sub -h swarm.hiveeyes.org -p 1883 -t 'hiveeyes/testdrive/#' -v
hiveeyes/testdrive/area-005/fipy-cg-01/data.json {"memfree": 2432320, "weight": 0.0}
See also: Dashboard hiveeyes-testdrive-area-005-fipy-cg-01.
@clemens: Thanks for your patience and good luck for connecting the sensor hardware.
… und was ist mit dem hier?
Alles was hier steht ist relevant für Verbesserungen auf dem Weg zum 0.3.0 Release. Der Stand vom master lief zuletzt auf den Gerätschaften @tonke mit ziemlich viel Hardware dran, während @clemens gerade auf einem nackten FiPy unterwegs war.
Die Robustheit zeigt sich bereits jetzt, dass die Firmware in diesem Fall nicht zwingend abstürzt. Das war ein wesentliches Ziel meinerseits. So können wir zukünftig auch Hardwarefehler über die Telemetrie fernmelden.
Es ist jedoch durchaus möglich, dass just dieser falsche Buszugriff im Kontext von “direkt nach dem Kaltstart” doch zum core dump führt – “Unhandled Exception” deutet irgendwie darauf hin. Schau ich mir an!
This works, sometimes even on LinuxOnWindows. However, it’s still flakey and has rough edges, especially on the documentation side.
# Find serial port
make list-serials
# Configure serial port
export MCU_SERIAL_PORT=/dev/ttyS16
# Pre-flight checks
make list-boards
# Bootstrap dependencies once.
# Usage: After updating the list of dependencies, e.g. through "git pull".
make setup
# Upload user-space firmware and trigger a cold start.
# Usage: Each time you modify code.
make recycle
Instead of the serial port, you might want to run this over the network by configuring the IP address like
export MCU_SERIAL_PORT=192.168.178.42
However, this obviously only works when the device has joined your local WiFi successfully.
nun, ich weiß ja garnicht , ob da tatsächlich ein BME280 dran ist (und wenn, ob auch an den definierten pins), insofern kann ich nicht einschätzen, ob das “nur” ein bus timeout war, weil an der gewünschen I²C-Adresse kein Gerät nach $zeit geantwortett hat, welches der Proz da erwartet hat.
Man könnte sowas zu Laufzeit quasi enumerieren, indem man á la i2cscan nicht alle, aber alle irgendwo definierten I²C-Adressen anfragt und, da die Fehler “vom System” abgefangen werden™, weitere Abfragen irgendwelcher I²C-Sensoren vom Ergebnis dieses ersten scans abhängig macht… aber muß man auch nicht, ist eher bei 1wire üblich. Zukunftsmusik.
Wenn ich die REPL-Ausgabe richtig interpretiere werden nur die Daten des BME übertragen. Wo kann ich sehen, was tatsächlich übertragen wird?
Warum werden die DS18B20- und Waage-Daten nicht übertragen? Angeschlossen sind 5 DS18B20 und eine Wägezelle.
Muss ich die Sachen ab 'bme280_1': löschen oder können die da stehen bleiben?
"make recycle" freezesWeiter habe ich immer noch Probleme mit make recycle, manchmal funktionierts, manchmal bleibt es ganz am Anfang hängen. Wenn es durchläuft kommt manchmal die Ausgabe eines core dump …
settings.pyDas ist meine aktuelle Konfiguration.
"""Datalogger configuration"""
# General settings.
main = {
# Measurement interval.
'interval': 1.0,
}
# Networking configuration.
networking = {
'wifi': {
# WiFi stations to connect to in STA mode.
'stations': [
# Variant 1: Using DHCP.
{'ssid': 'xxxx', 'password': 'yyy'},
# Variant 2: Using static IP address.
#{
# 'ssid': 'FooBar',
# 'password': 'SECRET',
# # Use static network configuration (ip, subnet_mask, gateway, DNS_server).
# 'ifconfig': ('192.168.42.42', '255.255.255.0', '192.168.42.1', '192.168.42.1'),
#},
],
# The maximum time in milliseconds to wait for the connection to succeed.
'timeout': 15000,
},
'lora': {
'otaa': {
'frequency': 868100000,
'region': 'LoRa.EU868',
'datarate': 0,
'device_eui': '<GENERATED_FROM_LORA_MAC>',
'application_eui': '<REGISTRATION NEEDED>',
'application_key': '<REGISTRATION NEEDED>',
},
'antenna_attached': False,
}
}
# Telemetry configuration.
telemetry = {
'targets': [
# JSON over MQTT
{
# Enable/disable this telemetry target.
'enabled': True,
# Define telemetry endpoint and address information.
'endpoint': 'mqtt://swarm.hiveeyes.org',
'address': {
"realm": "hiveeyes",
"network": "testdrive",
"gateway": "area-005",
"node": "fipy-cg-01",
},
},
# JSON over HTTP
{
# Enable/disable this telemetry target.
'enabled': False,
# Define telemetry endpoint and address information.
'endpoint': 'https://daq.example.org/api',
'address': {
"realm": "workbench",
"network": "testdrive",
"gateway": "area-42",
"node": "node-01-http-json",
},
# Use alternative, non-HTTPS endpoint.
# 'endpoint': 'http://daq.example.org/api-notls',
},
# CayenneLPP over MQTT, Base64 encoded
{
# Enable/disable this telemetry target.
'enabled': False,
# Define telemetry endpoint and address information.
'endpoint': 'mqtt://daq.example.org',
'address': {
"realm": "workbench",
"network": "testdrive",
"gateway": "area-42",
"node": "node-01-mqtt-lpp",
},
'format': 'lpp',
'encode': 'base64',
}
],
}
# Sensor configuration.
sensors = {
'registry': {
'hx711': {
'pin_dout': 'P22',
'pin_pdsck': 'P21',
'scale': 11.026667,
'offset': 130800.0,
},
'ds18x20': {
'bus': 'onewire:0',
},
'bme280': {
'bus': 'i2c:0',
# TODO: make sensor be initialized with address
# 'address': 0x77,
},
'bme280_1': {
'bus': 'i2c:1',
},
'pytrack': {
'bus': 'i2c:1',
},
'moisture': {
'pin_adc_in': 'P15',
'scaling': 4.096,
},
'waterlevel': {
'pin_adc_in': 'P18'
},
},
'busses': [
{
"family": "i2c",
"number": 0,
"enabled": True,
"pin_sda": "P9",
"pin_scl": "P10",
},
{
"family": "i2c",
"number": 1,
"enabled": False,
"pin_sda": "P22",
"pin_scl": "P21",
},
{
"family": "onewire",
"number": 0,
"enabled": True,
"pin_data": "P11",
},
]
}
Das war ein nackter FiPy, so werde ich es auch gleich bei mir nochmal nachstellen. Der aktuelle Stand im master plus settings ist einer, der aus einer voll ausgestatteten Hardwarekonfiguration von @tonke stammt.
Wir sind da dank @einsiedlerkrebs und gemeinsamen Anstrengungen des Backdoor Collectives durchaus schon in diese Richtung unterwegs. Wäre saucool, wenn wir diese Details wie Du sie ansprichst dann gemeinsam mit Dir festnageln könnten (i2cscan-sattelfest bin ich ja leider auch nicht so, mir ist aber klar, dass wir da konzeptionell viel ableiten könnten). Aber auch Vincent hat hier per GitHub - vkuhlen/bob-webserver-demo und GitHub - vkuhlen/bob-frontend-demo bereits funktionierende Softwarestücke, gerade für die Enumerierung bzw. Zuordnung der 1wire Sensoren.
"make recycle" freezesDas tut mir sehr leid. Versuche dazu doch einmal, etwas Dampf rauszunehmen, indem Du im Makefile beim Target recycle die Zeile
$(rshell) $(rshell_options) --file tools/upload-requirements.rshell
auskommentierst.
Die Firmware soll robust genug sein/werden, dass theoretisch alles stehenbleiben kann, ggf. auch falsche Konfigurationen.
Lösche in Deiner persönlichen settings.py aber bitte trotzdem einfach alle Dinge wie
'bme280_1': {
'bus': 'i2c:1',
},
'pytrack': {
'bus': 'i2c:1',
},
'moisture': {
'pin_adc_in': 'P15',
'scaling': 4.096,
},
'waterlevel': {
'pin_adc_in': 'P18'
},
Und passe auch den Abschnitt busses entsprechend an, so dass er Deiner Hardwarekonfiguration entspricht.
[*] Note to self: Verschiedene settings.example.py bereitstellen, z.B. settings.example-basic.py vs. settings.example-pytrack.py, usw.
# Setup
apt install mosquitto-clients
# Listen to your data channel group
mosquitto_sub -h swarm.hiveeyes.org -p 1883 -t 'hiveeyes/testdrive/area-005/#' -v
Note to self: https://swarm.hiveeyes.org/transmissions geht gerade nicht. Dafür vorgesehener Sensor im Icinga2 scheint wohl gerade nicht zu funktionieren, sonst müsste der rot sein.
Das war Deine letzte erfolgreiche Übertragung:
hiveeyes/testdrive/area-005/fipy-cg-01/data.json {"temperature.i2c:0.0x76": 23.01, "temperature_28ff641d8fd8778b": 22.875, "pressure.i2c:0.0x76": 1019.86, "weight": -136755.5, "temperature_28ff641d8fd833ac": 23.1875, "temperature_28ff641d8fd4d5d5": 23.4375, "temperature_28ff641d8fd922ab": 22.8125, "temperature_28ff641d8fd18ab0": 23.25, "humidity.i2c:0.0x76": 33.22, "memfree": 2429744}
{
"temperature.i2c:0.0x76": 23.01,
"temperature_28ff641d8fd8778b": 22.875,
"pressure.i2c:0.0x76": 1019.86,
"weight": -136755.5,
"temperature_28ff641d8fd833ac": 23.1875,
"temperature_28ff641d8fd4d5d5": 23.4375,
"temperature_28ff641d8fd922ab": 22.8125,
"temperature_28ff641d8fd18ab0": 23.25,
"humidity.i2c:0.0x76": 33.22,
"memfree": 2429744
}
Im imkerlichen Instant-Dashboard Dashboard hiveeyes-testdrive-area-005-fipy-cg-01 tauchen die neuen Feldnamen noch nicht auf, weil dort die Heuristik zur Feldnamenerkennung natürlich noch nicht auf die neuen Gegebenheiten vorbereitet wurde.
Im technischen Instant-Dashboard Panel hiveeyes-testdrive, device=fipy-cg-01, site=area-005 sieht man die aktuellen Telemetrienamen bereits als 1:1 Feldnamen, Du erlebst also gerade - trotz einiger Hürden auf dem Weg dorthin - das gleiche Erfolgserlebnis wie wir neulich bereits gemeinsam mit @tonke und @einsiedlerkrebs bei Developing Terkin for MicroPython - #4 by Andreas.
Gratuliere!
Note to self: Warum hat das technische Dashboard nicht “to=now” voreingestellt? Grafana-Upgrade INCOMPAT? Panic!? Hinweis: Ohne den Parameter explizit in die URL zu schreiben, klappts nicht, weil to scheinbar auf begin + paardaquetschte gesetzt wird, konkret 2018-06-08 20:19:16 to 2018-06-08 23:59:59. WTF!?
Hier der Grund warum ich überhaupt darauf gekommen bin, dass diese nicht übertragen werden: Der debug-output sagt nur:
886.8849 [terkin.datalogger ] INFO : --- loop ---
886.8952 [terkin.datalogger ] INFO : Terkin loop
896.7816 [hiveeyes.sensor_bme280 ] INFO : I2C data: {'humidity.i2c:0.0x76': 32.17, 'temperature.i2c:0.0x76': 22.34, 'pressure.i2c:0.0x76': 1019.54}
896.9094 [terkin.datalogger ] INFO : Telemetry transmission: SUCCESS
Hier taucht Waage und die DS18B20-Sensoren nicht auf, daher bin ich davon ausgegangen, dass die nicht übertragen werden. Grund wißt ihr sicher, entweder es ist kein “terkin-Objekt”, allerdings hätte ich gedacht, dass zuindest die DS18B20, da dynamisch mit terkin verwurstelt werden, vielleicht fehlt aber einfach auch nur die Ausgabe der Werte bei der debug-Ausgabe.
Wieder DAU-Gedanken, die dann zu falschen Schlussfolgerungen führen! ;-)
Beim Linux unter Windows 10 bekomme ich eine Liste mit über 200 (!) Einträgen in der Form
Serial Device: /dev/ttyS0
Serial Device: /dev/ttyS1
Serial Device: /dev/ttyS10
Serial Device: /dev/ttyS100
Serial Device: /dev/ttyS101
Serial Device: /dev/ttyS102
Serial Device: /dev/ttyS103
Serial Device: /dev/ttyS104
Serial Device: /dev/ttyS105
Serial Device: /dev/ttyS106
[... ca. 200 (!) weitere ... ]
Ich weiß darüber wie der Syntax für eine Serielle Schnitstelle ausschaut, ich weiß aber damit nicht welche in Benutzung ist oder gar wo das board angeschlossen ist!
Ja, die 0.3.0 ist noch nicht released. Das was Du auf dem Tisch hast, sind die brandneuesten Errungenschaften einiger gemeinsamer Sessions zusammen mit @einsiedlerkrebs und @tonke während der letzten vier Wochen, die es noch nicht in ein Release geschafft haben.
Wir müssen hier noch ein wenig weiterarbeiten, damit alles ein wenig abgerundeter daherkommt. Vielen Dank für Deine Berichterstattung!
a) Was gibt denn das bei Dir aus?
b) Würde denn bei Dir auch rshell --port COM4 boards unter WSL klappen, indem Du die Schnitte per export MCU_SERIAL_PORT=COM4 konfigurierst? Vermutlich geht das so nur nativ unter Windows, was Ihr gerne erforschen könnt. Dafür hatte ich Running rshell natively on Windows vorgesehen.
Wenn die Integration von pycom-fwtool-cli in den Findungsprozess sinnvoll ist, übernehme ich das gerne, so dass es ggf. via make list-serials angesteuert wird, wenn man unter Windows unterwegs ist (RUNNING_IN_HELL).
Momentan kann man nur in der REPL per CTRL+D einen soft reboot auslösen und bekommt dann die Log Ausgabe des Datenloggers.
Wir würden gern auch an einen laufenden Datenlogger attachen können, um die gleiche Ausgabe zu bekommen.
Man kommt nun per make console an einen laufenden FiPy ran und kann über make reset-device per Software einen Hard Reset auslösen.
This is bad.
It looks like we only get sparse metadata about the system runtime when running on older firmware releases like 1.18.2.r4.
================================
BOB MicroPython Datalogger 0.2.1
================================
CPU freq 160.0 MHz
Device id 807d3ac262bc
Python : 3.4.0
lorawan : 1.0.2
machine : FiPy with ESP32
nodename: FiPy
release : 1.20.0.rc8
sigfox : 1.0.1
sysname : FiPy
version : v1.9.4-7b83c6d on 2019-03-06
When running on a more recent firmware version, the metadata contains valuable information about the system runtime.
We would appreciate if you could upgrade your firmware.
I have updated the firmware yesterday and now again and the last stable version is 1.18.2.r4 .