WiFi-Konnektivität bei der Inbetriebnahme des FiPy hakelt

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:
image

Vielleicht geht es so:
image

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.

Ich habe das ja zuerst nicht glauben können, aber es ist durchaus möglich.

Allerdings gab es da auch ein anderes Ding.


Ob die entsprechenden Dinge bereits downstream innerhalb der Pycom-Firmware behoben wurden, kann ich nicht sagen. Ich wollte es nur gschwind mit Euch teilen.

@Diren hat einen fix eingespielt und nun kommt zumindest der OverflowError oben nicht mehr.

Moin,

hier im Home-Office habe ich nun auch Probleme den FiPy ins WLAN zu kriegen.

Meine Vermutung ist, das es ein Vodafone-Bug unserer Station für spezielle Netzwerkkarten ist, aber ich kann natürlich auch irgendwas anderes übersehen haben. Die Log Meldungen des Routers sehen so aus wie die, die hier beschrieben werden:

Hatte jemand schonmal ähnliche Probleme?

Hast Du nicht einen extra Accesspoint für BOB?

Ich habe eine alte Fritzbox WlanBOB1 mit einem Repeater WlanBOB2, den ich z.B. auf der Terrasse in eine Steckdose stecke. WlanBOB1 wird mit kurzen Kabel an den Hausnetzrouter gesteckt.

Vorteil: Im separaten WlanBOB1 tummeln sich nur ausgewählte Recher und man kann an der Fritzbox herumfummeln, ohne dass man die anderen Rechner, Drucker und Handys im Hausnetz lahmlegen kann.
Nächster Vorteil: aus dem Hausnetz kann man nicht in WlanBOB1 wegen der Firewall in der Fritzbox.
Die Übersicht ist auch viel besser. Ausserdem kann man die IP-Adressen besser verwalten.
Seit Juni 2019 habe ich folgendes:
WlanBOB1 192.168.10.1
WlanBOB2 192.168.10.2
PCWin10 192.168.10.11
RaspberryPi1 192.168.10.21 … 29
FiPy1 192.168.10.31 … 39

Drucker, Tablets, Handys usw sind in WlanTest1 und 2 mit 192.168.1.x und .2.x
NASx und alte Messrechner in WlanMess3 und 4 mit 192.168.3.x und .4.x
Zwischen WlanTestx und WlanMessx ist ein Funkschalter, so dass ich die Netze auch per Hardware trennen kann.