Nein in der settings.beispiel-bob.py fehlt noch eine zeile.
dann klappt es
2 Likes
Danke @MKO! Das war es!
25.4462 [terkin.telemetry ] INFO : Connecting to MQTT broker at swarm.hiveeyes.org
25.5976 [terkin.telemetry ] INFO : Connecting to MQTT broker at ('46.4.251.66', 1883) succeeded
I filed a bug report (nächstes mal wirds gleich ein pull request) add topology mqttkit to all settings.example files · Issue #7 · hiveeyes/hiveeyes-micropython-firmware · GitHub
@MKO funktioniert bei dir deep sleep in Verbindung mit einem geänderten intervall in der settings.py?
Noch was komisches, im debug kommt jetzt
'weight.0': -0.003,
was richtig ist, auf hiveeyes landet aber mit
nichts
2019-06-15T10:24:30.279309Z,
2019-06-15T10:25:01.648215Z,
2019-06-15T10:25:32.965187Z,
2019-06-15T10:26:04.339107Z,
Export-Problem, weil neue Variablen dazu gekommen sind?
Auch bei BOB / Beep scheint nichts anzukommen vom Gewicht
Erledigt, mapping ist jetzt anders statt weight ist es jetzt weight.0
Hab Deep Sleep noch gar nicht getestet. Hab ich aber heute Abend vor.
Hier nochmal mein Setup für die Programmierung und Überwachung im zusammengebauten Zustand. Die 4 Leitungen habe ich einfach unten an die Pin gelötet und mit Heißkleber fixiert.
10 posts were merged into an existing topic: [Pycom MPY] Verbesserung des “SystemBatteryLevel” Systemsensors / Energiehaushalt
@Andreas hat gerade den deep sleep bug gefixed. Danach hatte ich mit git pull meine sandbox auf den aktuellen Stand gebracht und mit make sketch-and-run auf den WiPy gebracht, das hat aber nicht gereicht, schwinbar war make install noch notwendig.
Mir ist ab und an nicht klar wann was verwendet werden muss. Welche files werden mit make sketch-and-run welche mit make install geändert?
Das ist auch wichtig, wenn updates reinkommen und user selbst updaten sollen. Standardempfehlung immer make install vorher?
See documentation hiveeyes-micropython-firmware/getting-started.rst at master · hiveeyes/hiveeyes-micropython-firmware · GitHub : “Upload framework and datalogger” vs. “Upload program sketch”
Für VSC (Visual Studio Code) von Microsoft gibt es auch ein plugin von pymakr. Das funktioniert ganz gut. Eingebaute REPL und ein-klick Synchronisation des Projektlaufwerks (damit kann man dann auch gut Dateien übertragen).
Fand ich ein wenig gewöhnungsbedürftig, aber eigentlich ganz gut (Intellisense, linting, etc…)
1 Like
Das funktioniert schon auch ganz gut, habe das mit der Software von @vinz auch erfolgreich und reliabel nutzen können.
Mit der GitHub - hiveeyes/terkin-datalogger: Datalogger for MicroPython and CPython. firmware können wir atom und Pymakr allerdings noch nicht nutzen, da die Developer Sandbox sich den code während make install “zusammenbaut”, wir können noch nicht den code per git pull von github herunterladen und auf den WiPy packen, da die Sandbox noch etwas “magic” macht, die Atom / Pymakr nicht kann.
@Andreas hat das aber auf dem Schirm und wir haben auch geplant das zu implementieren. d.h. es gibt dann neben der aktuellen Version auch ein release oder Verzeichnis oder was auch immer, das dem Dateisystem auf dem FiPy entspricht. Das könnte man dann auf den FiPy einfach per Atom kopieren.
Muß leider über noch einen Bug im Hiveeyes MicroPython Dataloggers 0.3.0 berichen.
Die Datenverbindung zu bee-observer.org bricht bei mir auf allen 3 Nodes alle paar Stunden in unregelmäßigen Abständen ab.
Dabei wird aber fleißig zu swarm.hiveeyes weiter übertragen, ist also auf den Zweig ‘beep-bob’ begrenzt. Habe leider den Ausfall nicht weiter eingrenzen oder provozieren können.
Werde jetzt mal bei einen auf 0.4.0 ungraden und die anderen weiter laufen lassen.
49815.0587 [terkin.telemetry ] WARNING: Adapter is offline, skipping telemetry to https://bee-observer.org/api/sensors
49843.5640 [terkin.datalogger ] WARNING: Telemetry status: FAILURE. 1 out of 2 targets failed. Status: {'https://bee-observer.org/api/sensors': False, 'mqtt://swarm.hiveeyes.org/hiveeyes/testdrive/MKO-micropython-firmware/FiPy-mqtt-json': True}
1 Like
Vielen Dank für Eure Eingaben und dass Ihr Euch bei manchen Dingen bereits selbst weiterhelfen konntet. Wir werden versuchen, möglichst viele Eurer Meldungen für das kommende Release 0.4.0 zu berücksichtigen.
1 Like
Könnte theoretisch auch am beep / bee-observer.org-Server liegen. Bei mir ist das Frontend / die Website ab und an auch langsam und hängt. Man kann natürlich die Übertagung auch x-mal versuchen, wenn ein Server nicht reagiert. Irgendwann geht das aufs Energiebudget, weshalb ich das sehr moderat machen würde, wenn wir an der Schraube drehen wollen / müssen.
@Andreas hat das nicht nur auf dem Schrim, sondern, tataa! schon umgesetzt! Lieben Dank! Du findest unter “releases” Releases · hiveeyes/terkin-datalogger · GitHub jetzt eine Datei, z.B.
hiveeyes-micropython-firmware-0.4.0.zip
die du in ein lokales Verzeichnis entpacken kannst und dann per Atom auf den FiPy schiebst! Falls andere Software vorher drauf war, bitte alte Dateien löschen!
… ab sofort jetzt auch bei uns in der Infrastrukturüberwachung.
2 Likes
Egal was hierfür die Ursache sein mag: Im Deep-Sleep Modus sollte es kein Problem darstellen, weil der Datenlogger quasi bei jedem Meßzyklus ohnehin neu anläuft.
Für den nicht- deep sleep Modus müssen wir die Resilienz der Routinen noch ein wenig verbessern, einstweilen ist man diesbzgl. also mit deep sleep besser dran - gerade für Langzeittests.
1 Like
@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.