wie gesagt bei mir hat es wunderbar geholfen, ob jetzt 10s der Wahrheit letzter Schluss sind mal dahingestellt, vielleicht klappt es auch mit 5s.
Mir ist es nicht wichtig, ob er jetzt vor dem Watchdog 10 Sec. hängt, bevor er es nochmal versucht (Neustartet), sondern, dass es überhaupt klappt.
1 Like
Danke für den Tipp, mit der firmware von Vinzent und den default-Einstellungen läuft es bei mir auch. Manchmal hate ich beim upload der Dateien über Atom Probleme, da sagt Atom ganz gut bescheid, dass der upload nicht funktioniert hat. Nach einem Reset des FiPys oder an-/abstöpseln läuft es dann meist.
Ab und an komme ich auch nicht auf den FiPy, dann hilft die Tastenkombi save boot-Knopf auf dem expansion board plus reset auf dem FiPy.
Was ab und an auch nciht ging, das Komplette Löschen der Dateien über den PyCom-Firmware-Flasher, da nutze ich dann das command line tool von Andreas mit make format-flash.
Bei mir am FiPy brennt mit Vinzents Firmware die LED dauerhaft gelb, dachte nur beim Betrieb als AP? Das Gerät liefert aber Daten.
Bin jetzt auch wieder zurück auf Vincent´s Version. Meine LED Leuchtet beim ersten Boot für ein paar Sec. und dann weder im AP Noch im Feldmodus.
Allerdings habe ich wieder das Problem, wenn Wlan aktiviert und verbunden ist, das der AP Mode ständig für jede Messung unterbrochen wird, und man so praktisch keine Einstellungen mehr vornehmen kann.
Benutze allerdings nur noch Visual Studio Code mit Pymakr Plugin und zusätzlich noch Remote -WSL. Leider funktioniert bei mir da das Pymakr plugin leider nicht. Ist aber trotzdem genial da in VS dann auch gleich das bash ist und pymakr daher gar nicht gebraucht wird.
@clemens bei mir funktioniert es jetzt übrigens auch mit der Standarteinstellung von 1000ms
Hab es nochmal überprüft, wenn der FiPy einmal bei der Fritzbox eingetragen ist geht es auch mit 1000ms beim ersten mal anmelden dauert es anscheinend länger.
Ist wahrscheinlich auch der Grund, warum es bei dir auch erst nicht ging und dann auf einmal problemlos.
1 Like
Wir sind bei den Versuchen, Fehler aus der Ferne aufzuspüren, nicht ganz alleine.
Hi. Ich wollte heute eigentlich meine zweite Einheit in Betrieb nehmen, aber der Fipy will nach dem Start einfach keinen AP aufmachen um die Konfig Daten zu editieren.
Die LED leuchtet gelb
Neu flashen?
Oder was kann helfen?
Hatte so eine Situation vor ein paar Wochen auch, das Ding wollte sich einfach nicht connecten. Nach ein paar Tagen ging es dann, was es am Ende war konnte ich nicht herausfinden.
Letzte Woche konnten wir ein ähnliches Phänomen beobachten: Wir hatten einen FiPy eingerichtet (der allerdings Probleme mit dem lokalen WLAN hatte) und nach ein paar Konfigurationsversuchen hat der Rechner das WLAN des FiPy nicht mehr mehr gefunden. Mit dem Handy gings dann komischerweise. D.h. vielleicht noch mal versuchen mit dem Handy oder einen anderen Rechner den AB zu finden.
Generell läuft der Hiveeyes MicroPython Datalogger deutlich stabiler, sowohl was das WLAN betrifft als auch sonst.
Leider hat er noch keine webbasierte Konfigurationsseite aka. “captive portal”. Bei HTTP- und webbasierte Konfiguration des Terkin-Datenloggers zur Implementierung eines Captive Portal wird daran gearbeitet.
Ok ich probiere es nachher noch einmal. Was kann ich machen, wenn gar nichts mehr geht?
Haben evtl. die ganzen WLANs in der Nähe eine Auswirkung?
Sprich es werden erst alle versucht zu connecten?
Ggf. Könnte man zwangsweise bei nicht gesetzten Daten / nicht Erreichbarkeit des konfigurierten WLAN der AP aufmachen- also forced mode
hat nichts gebracht … der FiPy will partout nicht mehr.
Schade, was du versuchen könntest: Mit Atom die ursprüngliche Software nochmals aufzuspielen und dann schauen, ob es wieder funktioniert. Ist denn LittleFS als filesystem schon ausgewählt? Bei den FiPys, die wir vor einigen Monaten verteilt haben war das noch nicht der Fall, wenn du den FiPy erst im August von uns bekommen hast, sollte LittleFS bereits aktiviert sein.
Habe nun mal mit ATOM den FiPy in Betrieb genommen und erhalte beim call des AP :
>>> Called. Pin Pin('P2', mode=Pin.IN, pull=Pin.PULL_UP, alt=-1).
Unhandled exception in callback handler
Traceback (most recent call last):
File "main.py", line 97, in enable_ap
File "main.py", line 88, in log
NameError: name '_csv' is not defined
Also, dass das FS gecrashed wäre glaube ich jetzt nicht, da ich LittleFS im LOG beim BOOTen sehe:
rst:0x1 (POWERON_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8028,len:8
load:0x3fff8030,len:2156
ho 0 tail 12 room 4
load:0x4009fa00,len:19208
entry 0x400a05f4
Initializing filesystem as LittleFS!
Starting boot process...
4 SSIDS found
Boot finished.
No DS1820 found. Is it connected properly?
Gain & initial value set
BME280 initialization failed. Is it connected properly?
CSV Logger failed. Is a SD card inserted?
Traceback (most recent call last):
File "main.py", line 114, in <module>
OverflowError: overflow converting long int to machine word
Pycom MicroPython 1.20.0.rc12 [v1.9.4-81167ed] on 2019-07-15; FiPy with ESP32
Type "help()" for more information.
Vielmehr macht die main.py wohl Ärger
Ich kann beim Firmware-Aufspielen das Filesystem nicht auswählen:
Vielleicht geht es so:
1 Like
hast Du denn beim ATOM gesehen welches FS auf dem PY ist?
in ATOM das ADD on Pakte pymakr installiert?
dann siehst do beim drücken des RESET Buttons welches FS beim BOOTEN genutzt wird
Update mit 1.20.0.rc13 hat funktioniert. -> LittleFS ok
Firmware 0.6.0 läuft
settings.example-bob.py nach settings.py kopiert
BME280 ok
5 DS18B20 ok
Waage zeigt noch 40366 kg an
Wo finde ich die Werte für Tara und Scale und wo trage ich sie ein?
1 Like
in der settings.py/settings.example-bob.py
Zeile: 197 bzw. environment: id scale-1
dort ist die Pin-Konfiguration und unter anderem
'scale': 4.424242,
'offset': -73000,
Bei Offset kommt dein Tara rein also das Raw Gewicht bei nichtbelastung.
und bei Scale der Faktor also der (RawWert - Offset) / Prüfgewicht in Kg.
(hoffe ich hab das noch so richtig im kopf)
unten in der Sensor-telemetrie-Map müssen dann noch für BOB die DS1820 den jeweiligen Feldnahmen zugewiesen werden.
"temperature.1111111111111111.onewire:0": "t_i_1",
bei 1111111111111111 muß dann die eindeutige SensorID rein
bei den Nachfolgenden dann auch die entsprechenden anderen ID´s
gruß Michael
1 Like
Hmm, pin2 ist der Taster für den AP-Button
"general": {
"general": {
"button_ap_enabled": false,
"button_ap_pin": "P2",
"initial_time": 1556805688,
"measurement_interval": 10
}
Keine Ahnung was da schief laufen kann, du hast doch die grüne Platine (nicht die weise)?
_csv hört sich nach SD-Logging an,
Magst du nochmal kurz schreiben, wie dein erstes Hardware-Setup ausschaut, das funktioniert? Grüne Platine, Expansion board mit verbunden? Mit oder ohne SD-Karte? Gibt es da Unterschiede zwischen dem jetzigen setup und dem “alten”?
Also das erste Hardware SETUP ist absolut baugleich (physisch)
grüne Platine - Expansion Board, HX711, BME/DS18B20/LOADCELL KEINE SD … läuft
ich habe einfach mal eine SD Karte eingeschoben und dann ist der LOGGING Fehler _csv beim BOOT weg. Nicht so wenn ich den AP aktivieren will.
BOOT:
Initialised CSV logger in directory /sd/hiverizelog
FLASH BUTTON
Called. Pin Pin(‘P2’, mode=Pin.IN, pull=Pin.PULL_UP, alt=-1).
Unhandled exception in callback handler
Traceback (most recent call last):
File “main.py”, line 97, in enable_ap
File “main.py”, line 88, in log
NameError: name ‘_csv’ is not defined
Wie gesagt, ich hatte erst die DS18B20 Konfig gemacht OHNE HX711 abgleich, und jetzt alles zusammengabut wird der AP nicht mehr geöffnet.
1 Like
88 if _csv is not None:
97 log(“enabled ap”)
113 rtc = RTC()
114 rtc.init(time.gmtime(_config.get_value(‘general’, ‘general’, ‘initial_time’)))
115
116 _csv = logger.csv
Es scheint sich alles rund um das CSV Logging zu drehen, was die EXCEPTIONS wirft
Ist bei dir der extra Button in der Config aktiviert? Da sind auf alle Fälle in der FiPy Firmware ein paar Bugs drin. Hab es bei mir lokal schon im Griff. Hab nur leider kein Internet meher, sodass ich kein Pull request machen kann.
Wenn ich mich richtig entsinne fehlt hinter
def log(message):
noch
global _csv
da sonnst die Variable nicht in der Prozedur genutzt werden kann.
Aber ohne Gewähr, da ich unterwegs bin und nicht schauen kann was ich da bei mir korrigiert habe.
1 Like
ich werde morgen dem mal nachgehen
87 def log(message):
88 if _csv is not None:
89 _csv.log(message)
90 else:
91 print(message)
Tatsächlich.
Das bedeutet, wenn man das Logging aktiviert (bewußt oder unbewußt) dann wird der CODE IMMER auf einen Fehler laufen.
Vielleicht liegt hier schon der Fehler der vorliegenden Hiverize Firmware Probleme …
@IngoP ich bekomme auch mit der aktuellen Firmware (von Ende Oktober) diese Fehlermeldung, ähnlich wie bei dir oben
Traceback (most recent call last):
File “main.py”, line 205, in
OverflowError: overflow converting long int to machine word
Habt ihr da eine Lösung, damit wir das Problem auch in GitHub - Hiverize/FiPy fixen können.