Display für LaCrosseGateway

Begonnen von HCS, 02 Mai 2016, 09:20:29

Vorheriges Thema - Nächstes Thema

weini

So, jetzt wird es interessant:

Habe das LGW gerade wieder angesteckt. Wegen Wohnungsumbau liegt es aktuell im Schrank.
Ich bekomme tatsächlich keine Daten mehr vom DHT22, auch nicht als LC Device. Die letzte Meldung ist von gestern 20h, das war unmittelbar bevor ich von 1.19 auf 1.20 geflasht habe.

Habe gerade versucht, nochmal zu pairen, das hat aber nichts gebracht.

weini

Hier der Output von "v":
23:13:26: [LaCrosseITPlusReader.Gateway.1.20 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + DHT22 + OLED {IP=192.168.0.113}]

Er erkennt den DHT22 also zumindest...

HCS

Zitat von: weini am 24 Juli 2016, 23:09:13
Ich bekomme tatsächlich keine Daten mehr vom DHT22, auch nicht als LC Device.
Dachte ich es mir doch.

Das Problem habe ich auch und bin noch etwas ratlos.
Ich habe zwei LGW mit DHT22. Auf einem funktioniert er permanent problemlos, auf dem anderen geht er mal und mal geht er nicht.
Neu pairen, flashen usw. kann man sich alles sparen, hilft nicht.
Ich habe die DHT22 auch schon über kreuz getauscht, ohne dass das Problem auf das andere LGW gewandert wäre.
Total verrückt: kürzlich habe ich den Logic-Analyzer auf den DHT22 mit drauf gehängt, dann lief er problemlos.
Logic-Analyzer wieder ab, lief immer noch. Am nächsten Tag kamen dann wieder keine Werte mehr.
Einer sitzt direkt auf der PeMue Platine drauf, der Problemfall ist mit 10 cm Kabel von der PeMue Platine abgesetzt.
Allerdings lief das auf dem BreadBoard mit Jumperkabeln auch problemlos.

Ich muss da nochmal mit dem Analyzer drauf und hoffen, dass es dann trotzdem nicht geht, um irgend welche sachdienliche Hinweise zu bekommen. Aktuell bin ich reichlich ratlos.

Zitat von: weini am 24 Juli 2016, 23:14:45
Hier der Output von "v":
23:13:26: [LaCrosseITPlusReader.Gateway.1.20 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + DHT22 + OLED {IP=192.168.0.113}]

Er erkennt den DHT22 also zumindest...
Ja, das hatte ich auch schon. Wurde erkannt, und kurz drauf hat er keine Werte mehr geliefert.


weini

Hast du das Problem erst mit v1.20 bekommen?

Ich bin mir recht sicher, dass vor dem Upgrade mit der v1.19 das ganze zuverlässig funktioniert hat.
Wenn ich morgen ein wenig Luft habe, dann würde ich mal kurz auf die v1.19 zurückflashen und testen.

HCS

Zitat von: weini am 24 Juli 2016, 23:30:53
Hast du das Problem erst mit v1.20 bekommen?

Ich bin mir recht sicher, dass vor dem Upgrade mit der v1.19 das ganze zuverlässig funktioniert hat.
Wenn ich morgen ein wenig Luft habe, dann würde ich mal kurz auf die v1.19 zurückflashen und testen.
Die Probleme hatte ich auch schon mit der 1.19
Aber ich hatte sie mit der 1.19 mal zwei Wochen nicht, und dann wieder hartnäckig Probleme. Dann ging es wieder, ...
Wie gesagt, auf dem einen LGW läuft es problemlos, auf den anderen nur wenn es will. Und wann es will, ist völlig unvorhersehbar  :o

weini

Kann ich leider nachvollziehen, derzeit bekomme ich auch unter 1.19 keine Werte mehr vom DHT22.

Mir ist noch aufgefallen, dass ich nach einem Reboot auch keine Werte von meinem Funk-LC Sensor mehr bekommen habe.
Habe dann das LGW kurz stromlos gemacht und nach dem Reboot kamen die Werte wieder.

HCS

Es ist zum verzweifeln. Analyzer hängt auf dem DHT22 drauf und es läuft und läuft und läuft.
Ich lasse ihn jetzt drauf, bis es irgendwann nicht mehr geht  >:(

So wie im Anhang ist der Korrekt-Fall.

Eventuell sollten wir das Thema in den LGW-Thread verlegen, mit dem Display hat es ja nichts zu tun, wie wir inzwischen wissen.

weini

Sag mal, nur so eine Idee: Müsste Data vom DHT22 nicht mit 10k auf 3.3V gezogen werden? Ich habe an meinem Raspi auch direkt einen DHT22 an GPIO und die meisten Anleitungen im Netz empfehlen den Pull-Up, z. B. https://klenzel.de/1827

Ich kann das ggf. auch gerne testen, aber nicht mehr heute...

HCS

Das devkit hat einen pullup drauf

weini


amunra

Anbei meine Anmerkungen zu der bisher wirklich tollen Implementierung.
Vorab, es ist alles unkritisch und nice-to-have.

1) IP-Adresse und Anzeige der Version nach Boot/Reboot ist recht hektisch, 3-4 Sekunden mehr fände ich pers. entspannter ;).

2) Etwas nicht OLED spezifisches - Befehl "OLED show=Hallo,,,e"" auf der "Config"-page - Log - Command führt dazu, dass sich die WiFi Connection zum AP weghängt. Ich weiß, ziemlich ungeschickt sowas zu machen. ;)
Das LGW kann sich nach einem Reboot nicht mehr mit dem Router/AP verbinden.
FW drüber installieren hilft nicht. Was nur noch hilft ist, Wifi SSID und PW auf der "config-page" entfernen "save restart" und SSID und PW erneut eingeben.
Es ist nicht tragisch wenn man weiß, dass es so ist, und komplett sicher wird man das wohl nicht hinbekommen.

3) Den aktuellen OLED-Mode (t,h,p,show etc.) per KVP übertragen damit das nachfolgende Szenario (Beispiel) möglich ist:
1. OLED mode="thps"
2. Mode merken
3. "OLED show=Gewitter!!!,,,w"
4. Nach einem definierten Intervall den gemerkten Mode (siehe Punkt 2) wiederherstellen

Vermutlich würde aber auch ein "on-for-timer" ausreichen - Beispiel: "OLED show=55%,,,h,600" zeigt für 600 Sekuden den Text 55% mit Icon Humidity)

4) Gibt es einen Grund warum auf der "Config"-Page keine Mode Auswahlmöglichkeit für "thps" (Alternativ=all) gibt? Per raw geht ein "thps". Ich weiß, das ist wieder ein Fall - genau das nicht implementiert und ausgerechnet das möchte man haben ;)

Sonst alles Super... ich bin allerdings noch nicht durch mit allem was ich vorhabe ;)

P.S: 5) Dimmen kann man das OLED auch - Stichwort: "It has 256-step brightness control" ;)

HCS

Zitat von: amunra am 26 Juli 2016, 17:30:57
1) IP-Adresse und Anzeige der Version nach Boot/Reboot ist recht hektisch, 3-4 Sekunden mehr fände ich pers. entspannter ;)
Was dann dazu führen würde, dass das LGW 3-4 Sekunden später online ist

Zitat von: amunra am 26 Juli 2016, 17:30:57
2) Etwas nicht OLED spezifisches - Befehl "OLED show=Hallo,,,e"" auf der "Config"-page - Log - Command führt dazu, dass sich die WiFi Connection zum AP weghängt. Ich weiß, ziemlich ungeschickt sowas zu machen. ;)
Das LGW kann sich nach einem Reboot nicht mehr mit dem Router/AP verbinden.
FW drüber installieren hilft nicht. Was nur noch hilft ist, Wifi SSID und PW auf der "config-page" entfernen "save restart" und SSID und PW erneut eingeben.
Es ist nicht tragisch wenn man weiß, dass es so ist, und komplett sicher wird man das wohl nicht hinbekommen.
Also tatsächlich mit zwei Anführungszeichen am Ende?
Da muss ich mal ausprobieren, was da wie warum passiert.

Zitat von: amunra am 26 Juli 2016, 17:30:57
3) Den aktuellen OLED-Mode (t,h,p,show etc.) per KVP übertragen damit das nachfolgende Szenario (Beispiel) möglich ist:
1. OLED mode="thps"
2. Mode merken
3. "OLED show=Gewitter!!!,,,w"
4. Nach einem definierten Intervall den gemerkten Mode (siehe Punkt 2) wiederherstellen

Vermutlich würde aber auch ein "on-for-timer" ausreichen - Beispiel: "OLED show=55%,,,h,600" zeigt für 600 Sekuden den Text 55% mit Icon Humidity)
Kannst Du dir nicht in FHEM merken, was Du wann an das Display geschickt hast und wann Du das nicht mehr habe und was anderes haben willst?
Eigentlich ist doch der Vorteil der Ansteuerung von FHEM aus, dass man seine Logik dort programmiert und ich nicht ständig irgend welche Fälle ins LGW implementieren muss.
Wenn Du keine Direktverdrahtung im LGW definierst und alle Buttons über FHEM etwas auslösen, dann weiß man in FHEM, was das Display aktuell anzeigt.

Zitat von: amunra am 26 Juli 2016, 17:30:57
4) Gibt es einen Grund warum auf der "Config"-Page keine Mode Auswahlmöglichkeit für "thps" (Alternativ=all) gibt? Per raw geht ein "thps".
s, t, th, thp
Eigentlich müsste es dann s, t, h, p, st, sh, sp, th, tp, hp, sth, stp, ... (also alles ausmultipliziert) geben.
Aber thps kann ich mal noch hinzufügen.

Zitat von: amunra am 26 Juli 2016, 17:30:575) Dimmen kann man das OLED auch - Stichwort: "It has 256-step brightness control" ;)
Kannst auch einen handelsüblichen Dimmer vor das Steckernetzteil vom LGW machen, das dimmt dann auch gleich die blaue LED vom devkit mit runter  ;D ;D ;D
Habe es mal auf der Wunschliste ganz unten (oben ist gut, unten ist schlecht) reingeschrieben

amunra

zu 1) Ja, das ist der Preis ;) Aber immer noch besser als drei mal rebooten um voll konzentriet die Info zu erhaschen. Ist natürlich etwas übertrieben, aber es ist mir tatsächlich schon ein paar mal passiert... "ähm was stand da gerade drauf..?" Ja, ich kann auch auf dem Router schauen und eigentlich vergibt man eine feste IP etc. ;)

zu 2) Ja.

zu 3) Ja, man kann sich etwas mit einem Dummy (oder was auch immer) bauen und ja, ich weiß das in die FW zu paken, ist sicher auch nicht optimal. Dazu gibt es auch so viele Konstellationen und man kann sich bei zwei Hände voll Aktionen sehr schnell verzetteln. Das das OLED ein Modus-Status schickt fände ich denoch gut, zumal nicht sicher gestellt ist, dass das Display die Message erhalten hat. Ich möchte das jetzt aber auch nicht bis ins kleinste durchdiskutieren. Ich schaue, ob ich irgendwo an die Grenzen stosse und melde mich dann...

zu 4) Ja, ein "thps" fehlt irgendwie. ;) "Ich" verspreche auch, nicht mit den anderen Varianten anzukommen ;)

zu 5) Danke.

...und wie bereits geschrieben alles Kosmetik nichts Weltbewegendes...

Wallmeier

Hallo,

ich möchte mich vorab erstmal ganz herzlich für die tolle Umsetzung der Displayunterstützung bedanken!

Weiterhin wollte ich mal fragen, ob die beiden Punkte umsetzbar wären:

1. Neben den Messwerten auch einen Mode c (clock) zu implementieren. Das LGW kennt die aktuelle Uhrzeit gemäß der Logseite bereits...

2. Kann man die I/Os des SC16IS750 ähnlich konfigurierbar machen wie beim MCP23008. Oder kollidiert dies mit den teils fest vorgegebenen Belegungen (z.B IO7 Buzzer)?

Noch einen schönen Abend,
Nico

HCS

Zitat von: Wallmeier am 26 Juli 2016, 22:58:23
1. Neben den Messwerten auch einen Mode c (clock) zu implementieren. Das LGW kennt die aktuelle Uhrzeit gemäß der Logseite bereits...
Das LGW kennt die Urzeit leider nicht, die wird per JS lokal im Log bei der Ausgabe im Browser hinzugefügt.
-> Bedeutet: nicht machbar (oder genauer, um machbar zu sein müsste sich das LGW die Uhrzeit bei einem NTP-Server besorgen)

Zitat von: Wallmeier am 26 Juli 2016, 22:58:23
2. Kann man die I/Os des SC16IS750 ähnlich konfigurierbar machen wie beim MCP23008. Oder kollidiert dies mit den teils fest vorgegebenen Belegungen (z.B IO7 Buzzer)?
Für die bisherigen Ports, die eine konkrete Vewendung haben, definitiv nicht.
Das sind z.B. die zwei ChipSelects für Radio 4 und 5, der Buzzer, Reset für die AddOn-CPU
Ich wollte eigentlich die SC16IS750 IOs nicht für allgemeines freigeben sondern mir für Dinge, die evtl. noch kommen und nicht konfigurierbar sondern autoerkennbar sein sollen, aufheben.
Ich glaube, dass noch vier Stück ungenutzt sind. Müsste mal mit mir ringen, ob ich zwei davon dafür abgebe, aber das ist dann halt wieder recht wenig und man kommt nicht weit damit.

Zumal ich eine klare Trennung besser finde.
SC16IS750: Erweiterung mit fest vorgegebenen Komponenten
MCP23008: Taster und Lämpchen komplett vom Anwender konfigurierbar