@MKO machte uns darauf aufmerksam, dass es für die MQTT-Telemetrie noch keine Möglichkeit gibt, authentication credentials für die Verbindungsaufnahme zum Broker zu konfigurieren.
Wir sagen danke: Daran ist doch glatt noch etwas zu feilen.
Note to self: Dabei auch prüfen, ob der FiPy vielleicht auch schon gut MQTT über TLS/SSL realisieren kann – bei der HTTPS-Verbindung zu BEEP oder Kotori war dies problemlos möglich.
Please do not forget the light sleep mode.
There is also something to grind in the HTTP transmission. It recognizes that the transmission was unsuccessful. But then apparently does not build a new connection, but still tries to transfer over the lost connection to http.
I think on Prio 3. because we currently have nothing, which forces the awake state or light sleep.
If this option exists, it should also be work robust.
But I already have an idea for a future sensor that might need awake state.
Sure. Thanks for the reminder.
While the foundation is reasonable, the behavior implemented on top is totally silly right now. Sorry for that. Will also be improved.
The backlog is now a Wiki. Feel free to edit as you like. I’d suggest to append it to Prio 1.
Aktuell werden mit system.time und system.uptime im gleichen Datensatz beinahe identische Werte verschickt, time ohne Nachkommastellen und uptime mit zwei Nachkommastellen.
system.time, system.uptime
51736, 51736.41
52098, 52098.05
52459, 52459.96
52821, 52821.06
53182, 53182.06
53542, 53542.89
53904, 53904.61
54265, 54265.43
54626, 54626.19
54987, 54987.75
55349, 55349.25
55710, 55710.07
56071, 56071.6
56432, 56432.39
56792, 56793.02
57154, 57154.66
57887, 57887.43
58250, 58250.14
58613, 58613.27
58974, 58974.99
59335, 59335.8
59696, 59696.52
60058, 60058.08
60419, 60419.66
60780, 60780.37
61141, 61141.17
Da dies zu Verwirrung führt, und wir uns den doppelten Datentransfer sparen können, würde ich für uptime plädieren, das zukünftig alleine verschickt wird.
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.
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.
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
Hinweis: Die Umgebungsvariable heißt ab sofort
MCU_PORT, die Abwärtskompatibilität zuMCU_SERIAL_PORTsollte jedoch erhalten geblieben sein.
'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.
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
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 
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.
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.
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,
},
# ....
}
More convenience.
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.
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'}
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
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.
lte.deinit() abstürzt, auch ich habe das erst kürzlich ebenfalls einmal erlebt. Wir diskutieren die Details bei WIP: Merge Hiverize/FiPy and hiveeyes/hiveeyes-micropython-firmware by pinguin999 · Pull Request #11 · hiveeyes/hiveeyes-micropython-firmware · GitHub und planen, den Watchdog früher zu aktivieren, um diese Situation zu verbessern.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.