Entwicklung SIGNALDuino Empfänger Firm- und Hardware V4 für Maple Mini und ESP32

[Ralf9]

Seit ich bei der aktuellen Version beim compile der IDE das USB und die serielle deaktiviert habe, hatte ich keine Abstürze mehr.
Werde jetzt auch mal langzeit Tests machen.

Ein reset über USB funktioniert beim Maple Mini anscheinend nicht.

Dein angepasstes SIGNALduino Modul scheint mit den Readings noch ein Problem zu haben, da steht bei mir im Grunde kaum etwas Nachvollziehbares. Falsche Version, falsche Konfiguration.

Bei der Version im reading ist noch ein Fehler.
Das ccconf wird momentan nur in den Internals gespeichert. Die Ansicht der Internals wird nicht automaisch aktualisiert, es muss manuell ein Browser Refresh gemacht werden

Gruß Ralf

[Reinhard.M]

Wie gesagt, wenn ich beim Debuggen irgendwie unterstützen kann lass es mich wissen. Ich habe die Arduino 1.8.12 IDE und den MSC Bootloader von Telekatz im Einsatz.
Ganz nebenbei aber nicht unwichtig: Ihr alle die an diesem Projekt arbeitet macht einen echt geilen Job 

[juergs]

Hallo Reinhard.M,

danke für Dein Angebot. 

[juergs]

Hallo Zusammen,
nach dem ich nun Einiges  [ 2 ] zur Serial WLAN-Bridge probiert habe, musste ich nun doch die Gegebenheiten des Micropython- Socket-Ports zum W600 so erst mal  hinnehmen. 

Ich habe mehrere "Verfahren" ausprobiert die .recv()-Methode nicht zum Blockieren zu bewegen und hatte keinen Erfolg damit.
"select", "polling-select-in-python"  und "set_socket_settimeout()" um nur Einige davon zu nennen.
Hinzu kommt noch, dass die Funktion serial.readline() nicht auf das "CR/LF" des seriellen Empfangstrings wartet ... (/edit:timeout => nicht implementiert!)

Dazu habe ich mir folgende Vorgehsweise als Lösungsmöglichkeit überlegt:

1.) da Fhem mit der Antwort des Kommandos "V" erkennt, dass ein Signalduino angeschlossen ist, warte ich in einer ersten Schleife auf eine Connection eines TCP-Clients.
Hier wird das Kommando an den Signalduino weitergereicht und die Antwort an den Client 1:1 übertragen. (Die XQ+XE-Kommandos mal vernachlässigt).

2.) Dann wird in eine zweite Schleife eingetreten, die nur die Readings aus dem seriellen Port an den FHEM-Client zurückschickt.

Manko: in der zweiten Schleife kann ich keine Kommandos von FHEM verarbeiten, wie gesagt die Abfrage (recv) blockiert den gesamten Ablauf!
Selbst eine Timer-Tick Lösung wird blockiert....
Als Lösung dafür sehe ich nur, über eine zusätzliche Webseite (Port 80) oder einen Jumper wieder "manuell" zurück in den Kommando-Modus zu  schalten, um über WLAN auch von FHEM aus Parametrieren zu können.
Ggf. würde ein Client-Disconnect evtl. auch ausreichen um nach einem neuen Connect immer wieder in den Kommando-Modus zu gelagen .... 
Oder ggf. darauf zu verzichten und nur über USB/LAN zu parametrieren ....

Meiner Meinung nach, wird der Signalduino ja nur "einmal" (initial) eingestellt, dann läuft er eigenlich nur noch im Erfassungsmodus weiter und schickt fleißig seine Readings an FHEM.

Mit der Serial-Bridge-Variante wird nur der weitere serielle Port (RX1/TX1) des Maples beaufschlagt.
In der "loop"-Schleife würde ich nur ein Serial1Event() hinzufügen und die Ausgabe der Readins auch zusätzlich an Serial_1 senden.
Alle anderen Interfaces  werden ja nicht beeinträchtigt und bleiben weiterhin erhalten!

• Hat jemand eine bessere Idee?
• Habe ich bestimmte Konstellationen nicht beachtet?

(Aktives Umschalten der CC1101-Receiver?)
[/list]

Grüße,
Jürgen

Da der Code weitestgehend portabel ist, könnte man das auch mit dem ES8266/ESP32 betreiben.
Der W600 ist aber wegen seiner "Größe" schon attraktiver .. 

Anmerkung zu esp-link

The connections on port 23 and 2323 have a 5 minute inactivity timeout. This is standard with Espressif's SDK and esp-link does not change it. The reason is that due to memory limitations only a few connections can be open (4 per port) and it's easy for connections to get "lost" staying open forever, for example, due to wifi disconnects. That could easily make it impossible to connect to esp-link due to connection exhaustion. Something smarter is most likely possible...

/Edit: Frage: Wie ist eigentlich die Chip-Antenne korrekt zu verdrahten?

[juergs]

Beispiel:

Server Started on Port: 23
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> New Client: 192.168.178.23
XQ
V
V
XQ
> Client closed conection.
> New Client: 192.168.178.23
XQ
V
V
V
> Client closed conection.
> New Client: 192.168.178.23
XQ
V
V
V
> Client closed conection.
> New Client: 192.168.178.23
S: V 3.3.1 SIGNALduino cc1101 (chip CC1101) - compiled at Dec 3 2019 19:40:46
XQ
V
S: V 3.3.1 SIGNALduino cc1101 (chip CC1101) - compiled at Dec 3 2019 19:40:46
XE
P

Erreicht ein "V" keine Reaktion wird die Connection abgebrochen und 3 mal ein Wiederholungsversuch gestartet.
Der dritte Versuch hat geklappt und der State wechselt auf "opened".
Fhem sendet dann ein "P" als Ping.
Im schlimmsten Fall wird doch eine Antwort "OK" als isAlive erwartet ....   

Leider ja, bei einem nicht beantwortetem "P"
geht das Signalduino-Device in "STATE closed"... 

[Ralf9]

Meiner Meinung nach, wird der Signalduino ja nur "einmal" (initial) eingestellt, dann läuft er eigenlich nur noch im Erfassungsmodus weiter und schickt fleißig seine Readings an FHEM.

Die Senderichtung muss auch funktionieren
z.B. für den Ping Befehl
und der Sduino muß auch z.B. an Steckdosen einen Schaltbefehl senden können.

Hast Du wegen der blockierenden .recv()-Methode mal bei dem Entwickler nachgefragt.

Gibts für den W600 keinen C Compiler?

Gruß Ralf

[juergs]

Hallo Ralf9,

Sduino muß auch z.B. an Steckdosen einen Schaltbefehl senden können.
Hast Du wegen der blockierenden .recv()-Methode mal bei dem Entwickler nachgefragt.
Gibts für den W600 keinen C Compiler?

* An Steckdosen-Sendebefehle hatte ich nicht gedacht ... 

* Ich schaue mal im MP-Forum vorbei. Mit den bisher gefundenen Beispielen kam ich nicht zurecht oder funktionierten einfach nicht ...

* C-Compile: Ist ja ein M3-Core, sollte der gleiche wie der des STM2F103 sein ....

* Schaue mir das dann in der Arduino-IDE in C/C++ noch mal an ... , den Upload der IDE habe ich schon realisiert.
  Deine Implementierung mit der Arduino-Lib für den WIZ5500 schaue ich mir auch mal an.

Schade hätte gepasst ...

Jürgen

[juergs]

Hallo Ralf9,

welche Ethernet-Lib benutzt Du?

https://github.com/adafruit/Ethernet2
oder diese:
https://www.arduino.cc/en/Reference/Ethernet ?

[Ralf9]

Diese
https://www.arduino.cc/en/Reference/Ethernet

es müsste diese sein
https://github.com/arduino-libraries/Ethernet

[juergs]

Ah ok, hatte es gerade auch gefunden

Komischerweise ist die EthernetServer read()-Funktion nicht in der offiziellen Doku "erwähnt" :

https://forum.arduino.cc/index.php?topic=123756.msg930967#msg930967

Die scheint nicht blockierend zu sein ...


/edit: habe die Frage im MP-Forum eingestellt, muss aber noch "approoved" werden ...

[juergs]

Die W600- Implenmentierung des WiFi-Servers für Arduino:
https://github.com/juergs/divers_use/blob/master/Local_Arduino15_packages_w600_hardware_w600_0.2.6_libraries_WiFiServer.png
beinhaltet keine read-Funktion.

In den Samples zur Lib ist nur ein Client-beispiel aufgenommen, aber kein Server !

Library-Examples:

C:.
├───Client
├───LED-AP
├───NTP
├───NTPClient
├───Oneshot-Key
└───Sta

Uh!.

/edit: die Methoden sind im ClientContext versteckt. 

Ok, programmiere das mal in Arduino aus ....

[Ralf9]

Es gibt dafür schon was, einfach mal nach "WiFiTelnetToSerial" suchen.

[juergs]

Hallo Ralf),
ja, gut gemeint:

Code Auswählen Erweitern

#include <ESP8266WiFi.h>

aber evtl. doch zu gebrauchen:
https://github.com/esp8266/Arduino/blob/master/tests/host/common/ClientContextSocket.cpp

ESP8266:

Server Class

Methods documented for the Server Class in Arduino

    WiFiServer()
    begin()
    available()
    write()
    print()
    println()

Fällt da was auf?



Suche morgen erst mal ein Beispiel....

In den ESP-Samples: https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFi/examples/WiFiHTTPSServer/WiFiHTTPSServer.ino
Um das zu Portieren : https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFi/src/WiFiServer.cpp

Wenn ich Glück habe funktioniert es einfach im W600: WiFiTelnetToSerial 

[juergs]

Hallo,

die Anfrage im MP-Forum wurde quasi sofort kompetent beantwortet!

Respekt!

D.h. das Blocking-Thema ist ad acta zu legen, es funktoniert einfach. (Wenn man weiß, wie es geht...)!   

Grüße,
Jürgen

[juergs]

Kaum macht man es richtig, schon geht es !

Ist noch Feintuning angesagt, insbesondere ein close() une ein reconnect() handlen.
Geht jetzt aber vom Ablauf her schon im "Trockentest" direkt aus FHEM.

Als nächstes werde ich den Signalduino dranhängen und den Gegenpart implementieren, dann  weiter Testen....

W600_serial_tcp_bridge.py