Gurtwickler GW60 mit ESP8266

[mar565]

Sodele, ich hatte jetzt endlich Zeit mir den Code und ein bisschen von der MQTT Docu anzuschauen.
Wenn ich richtig liege, muss bei QOS>0 eine MessageId mitgesendet werden, damit eine Rückmeldung erfolgen kann. Wird keine Id definiert, funktioniert es trotzedem, aber ohne Rückmeldung. Man kann in meinem Log beobachten, wie sich bei jedem Fehler die Id um 1 erhöht. Wahrscheinlich geht der Broker so mit den fehlenden Ids um.
Kann natürlich auch sein, dass ich komplett auf dem Holzweg bin 

PubSubClient hab ich in der Version 2.6.0 (mit 2.7.0 passiert aber genau das gleiche)

[Manu]

Nur ganz kurz, da ich grad auf dem Sprung bin:

Die MessageID wird vom PubSubClient erhöht, wenn die letzte Nachricht einen Acknowledge bekommen hat.

[Manu]

Tach zusammen,

ich hab gerade noch einen kleinen Bug im Programm beseitigt:
Wenn gerade eine Konfigurations-Änderung stattgefunden hat, wird der WEMOS neu gestartet. So wird sichergestellt, dass die neue Konfi auch übernommen wird. Dies ist besonders wichtig, wenn z.B. das MQTT Topic Prefix geändert wird. Vor dem nächsten Reboot liest das Programm sonst die neuen Werte nicht ein und arbeitet weiter "brav" mit dem alten Topic.

Wenn ich schon dabei bin: Wollt ihr auch die kompilierte Firmware zum direkten Download auf Gitlab haben? Dann hänge ich die mit ins git bei Änderungen. So ist dann immer die passende kompilierte Version zum Quellcode da vorhanden. Mit verschiedenen Releases da zu arbeiten finde ich etwas "too much" für sowas...

[lukasbastelpeter]

Hi zusammen,

halle Manu! Sieht hübsch aus was du das gebaut hast.
Meine Platine nimmt langsam in der 2. Revision Form an. Ich habe einen 3,3V Hallsensor verbaut. Somit entfallen zwei Kontaktstellen auf der Platine, der ESP12E (oder 7) kann direkt auf die Platine gelötet werden. Die Flash-Logik habe ich beim Node-MCU abgeschaut und soweit auf dem Board untergebracht, dass ein normaler FTDI Adapter aus China angeschlossen werden kann.
So langsam ist der Hardware-Part überstanden. Nun suche ich noch eine Softwarelösung. Hättest du Interesse das anzupassen? Ansonsten würde ich demnächst beginnen das nächste Süppchen zu kochen.

Ich hatte etwas via MQTT (Set position/endposition up/down/tiltposition // get (analog value, von meinem ADC Eingang), position) im Kopf.

[Manu]

[...]
Nun suche ich noch eine Softwarelösung. Hättest du Interesse das anzupassen? Ansonsten würde ich demnächst beginnen das nächste Süppchen zu kochen.

Ich hatte etwas via MQTT (Set position/endposition up/down/tiltposition // get (analog value, von meinem ADC Eingang), position) im Kopf.

MQTT macht das jetzige Programm ja auch 
Gib mal ein paar mehr Details wie, wo, was angeschlossen ist bzw. welche Funktion welcher IO hat. Auch beim ADC. Was willst Du da für Werte abfragen?

[lukasbastelpeter]

Hi,

im wesentlichen habe ich nur das Design von paparomeo für einen esp12e geändert.
GPIO 05: Sensor Hallsensor
GPIO 16: Sensor Motor A
GPIO 14: Sensor Motor B
GPIO 13: Actor Direction A
GPIO 12: Actor Direction B
GPIO 04: optionaler Taster
ADC.     : beliebiger Wert (geplant war eine Fotodiode)

Ich hätte gerne in FHEM später ein MQTT2_DEVICE mit den nötigen Möglichkeiten. Vorgestellt habe ich mir per MQTT einstellbar etwas wie:
subscription von Topics wie:

• devicename/cmd/newUpStop XXX
• devicename/cmd/newDownStop XXX
• devicename/cmd/targetPos XXX
• devicename/cmd/driveUp
• devicename/cmd/driveDown
• devicename/cmd/lock TRUE/FALSE

und publish Topics:

• devicename/RSSI XXX
• devicename/ADC/ XXX
• devicename/pos-percentage XX.X%
• devicename/uptime XXX

Sehr sehr Edel wäre dann in einer späteren Variante ein Timer inkl. einer Verbindung zu einem NTP. Der Timer/Kalender dann via FHEM manipulierbar.
Wie gesagt, die Hardware habe ich jetzt so langsam so weit, dass ich die Software angehen kann. Eigentlich müsste ich "nur" Papa-Romeos Sketch so umbauen, dass die Topics in meine vorhandene Nomenklatur passen. Aber beim Überfliegen des Sketches scheint es mir so komplex, dass ich es nochmal selber neu machen müsste um es absolut zu verstehen

[Papa Romeo]

Aber beim Überfliegen des Sketches scheint es mir so komplex...

...das war mein erster Sketch den ich gemacht habe....aber Danke für die Blumen
und ich denke er scheint nur daher "komplex" zu wirken, da er, wenn´s wahrscheinlich ein Profi betrachtet, eventuell etwas umständlich geschrieben ist.

[Manu]

• devicename/cmd/newUpStop XXX
• devicename/cmd/newDownStop XXX
• devicename/cmd/targetPos XXX
• devicename/cmd/driveUp
• devicename/cmd/driveDown
• devicename/cmd/lock TRUE/FALSE

Dein "cmd" ist vom Prinzip her das "Action" in meinem Sketch. "targetPos", "driveUp", "driveDown" und "lock" verstehe ich. Auch wenn es deutlich einfacher zu programmieren ist, nur ein Topic (devicename/cmd) zu haben und die dort ankommenden Nachrichten auszuwerten.
Aber was bezweckst Du bitte mit "newUpStop" und "newDownStop"? Ich sag dem "Ding" das soll auf z.B. 45 (%) fahren und dann macht der das.

• devicename/RSSI XXX
• devicename/ADC/ XXX
• devicename/pos-percentage XX.X%
• devicename/uptime XXX

"uptime"? Na, Du hast ja richtig was vor 

Sehr sehr Edel wäre dann in einer späteren Variante ein Timer inkl. einer Verbindung zu einem NTP. Der Timer/Kalender dann via FHEM manipulierbar.

Du hast FHEM. Wieso da noch einzelne Timer in die Geräte einbauen? Ich habe hier keinen einzigen Timer irgendwo (auch wenn vorhanden) aktiv. Hier gibt es 2 Systeme, die "befehlen" was, wann zu tun ist. Die Homematic selbst, bei Sachen wie Steuerung der Rollladen bei Sonne oder wenn abends die besagten im Schlafzimmer runterfahren (Kombi aus Uhrzeit und Sonnenstand). Und NodeRed (auch wenn ich hier im FHEM-Forum bin, ist hab's nicht  ).

[lukasbastelpeter]

Naja. Das ist alles Luxus. Mit ,,newstop" ist eigentlich nur gemeint dem Gerät sagen zu können, dass der aktuelle Wert die oberste, bzw unterste Position ist. Verstehe es als Kalibrierung.

[Papa Romeo]

...auf meinen Sketch bezogen dann 0 und maxPos, da es eigentlich Sinn macht, eine Position, egal ob jetzt oben oder unten, nach jeder abgeschlossen Fahrt in die entsprechende Endlage auf 0 zu setzen. Ein definierter Wert der dann bekannt ist und schon mal nicht gespeichert werden muss.

Wobei wieder beachtet werden muss, dass der Wert vom maxPos nicht durch den Sketch, sondern durch die Endlagenspeicherung des GW60 bestimmt wird.
Der Sketch kalibriert sich im Endeffekt durch das Speichern der aktuellen Endlagen selber.

[lukasbastelpeter]

Ja, das macht Sinn, allerdings muss erkannt werden, dass der GW60 auch am Ende angekommen ist, und nicht eine Taste am Gerät gedrückt wurde.

[Manu]

Ja, das macht Sinn, allerdings muss erkannt werden, dass der GW60 auch am Ende angekommen ist, und nicht eine Taste am Gerät gedrückt wurde.

Dafür müsstest Du aber die Tasten auch abfragen. Das ist ja in der bisherigen Schaltung nicht der Fall. Das wäre dann auch ein etwas größerer Umbau des GW. Also Tasten "abfangen", auf den Wemos leiten und vom Wemos dann per Optokoppler die Kontakte der Tasten ansteuern (auch dann, wenn die Tasten lokal gedrückt werden).

[lukasbastelpeter]

Korrekt. Daher meine Überlegung vor dem Kalibrieren die interne ,,soll-Position" zu checken. Wenn die
+/-  X am Anschlag sind kann die Position zurück gesetzt werden.

[lukasbastelpeter]

So, nachdem ich nun die zweite Platinenvariante mit einem direkt aufgelötetem EP12E habe und ihn nicht programmiert bekomme werde ich meine Platine für ein NodeMCU designen. Auch finanziell und aufwandsmäßig ist das deutlich effizienter als alle Teile einzeln zu bestellen und dann händisch aufzubringen. Den Komfort beim Programmieren mal außen vor gelassen.

[Papa Romeo]

...warum willst du jetzt von einem Wemos (...lässt sich hervorragend Programmieren) oder Solo-ESP weg auf einen NodeMCU....ist dir das bisherige Design zu klein ?