Idee'n gesucht: Schalten zweier 64A Schütze nebst Rückmeldung

Begonnen von M_I_B, 27 Oktober 2016, 16:00:18

Vorheriges Thema - Nächstes Thema

M_I_B

Hallo liebe Leute,

ich möchte zwei Schütze schalten. Das ist ja erst mal kein Problem. Allerdings brauche ich eine Rückmeldung (via Hilfskontakt NC oder NO) an FHEM, ob die Schütze auch wirklich offen resp. geschlossen sind. Irgendwie bietet da ELV/eQ3 nichts an, was genau passen würde.
Schalten könnte ich notfalls per InterTechno, da ich hier noch eine Tüte 4CH- China- Platinen rumliegen habe. Wichtig ist aber, gerade bei IT, die Rückmeldung an FHEM...

Hat da vielleicht wer eine Idee zu, was man dazu missbrauchen könnte?


In dem Zusammenhang, falls es wer braucht:
24V~ Schütze kann man auch mit Gleichspannung ansteuern. Aber bitte nicht mit 24V= ! Dann fangen die nach kurzer Zeit an zu brennen! Da is dann nix mit Blindwiderstand... (siehe Wechselstrom- Lehre...)
I.d.R. ziehen 24v~ Schütze mit 12V= heftig durch, werden aber auch bei 12V= noch ordentlich warm. je nach Schütz halten die aber noch perfekt bei 5V, wenn sie erst einmal angezogen haben. Was liegt also näher, als sie mit 12V= anziehen zu lassen und dann die Spannung auf die 5V Haltespannung abzuregeln? Nix...
Einfache Variante: 78S05 Regler Eingang mit Ausgang per Elko 4700µ/16V (oder größer, je nach Ri des Schütz) überbrücken (+ Eingang, - Ausgang), parallel zum Elko Schutzdiode, Kathode an Eingang
Etwas aufwändiger: 78S05- Reglers, ZD6V8, kleiner Elko, Kleinsignal- FET oder Transistor, zwei Widerständen (Sense des 7805 per ZD hochlegen, R1 Ausgang-Sense, N-FET über ZD, Gate über Elko an Masse, R2 Gate-Ausgang)
In beiden Fällen natürlich Freilaufdiode parallel zum Schütz nicht vergessen...
Beide Varianten funktionieren perfekt an zwei 24V~ Testschützen mir Ri = 7 Ohm

Muschelpuster

ich denke mal die Schütze schalten 230/360V. Was liegt da also näher, etwas von dem geschalteten Saft auf ein Steckernetzteil zu führen und die Ausgangspannung von diesem einen HM-Klingelsensor (klick) zuzuführen? Schon steht die Rückmeldung und der Verbrauch des Steckernetzteiles sollte bei den zu schaltenden Lasten ja zu vernachlässigen sein  ;)
Etwas eleganter wäre die Option mit einem RC-Glied die Ausgangspannung des Schützes auf die LED eines Optokopplers zu bringen (klick). Der Ausgang des Optokopplers kann dann sicher den Kontakt eines HM-Türkontaktes ersetzen.
Da die Schütze ja sicher in einer E-Verteilung hängen, würde ich zum Schalten einen HM-4-fach-Aktor nehmen (klick). Das Teil hat potentialfrei Kontakte und kann auch 24V~ von einem Netzteil schalten. Und wenn Dir das dann doch als Rückmeldung reicht, brauchst Du nicht einmal das oben beschriebene Gebastel.

potentialfreie Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

M_I_B

Erstmal Dank für die Idee'n!

Klingelsensor/Netzteil funktioniert nicht, da auch bei offenem Schütz teilweise beidseitig Phasen anliegen. Aber wie gesagt: Hilfskontakte... Die sind ja vorhanden und ebenso 12V vom Hutschinennetzteil für die Schütze. Das könnte gehen.
Zum Thema Optokoppler und vor allem "LED an 230V" gleich ne Warnung! Die verlinkte Schaltung bezgl. LED an 230V ist Mist. Dazu habe ich auch mal was geschrieben (click).

Aber mit den Fensterkontakten hast du mich auf eine Idee gebracht! Gibt es die vielleicht sogar zweifach?

Mir geht es hauptsächlich darum, nicht unnötig viele Transceiver dicht an dicht zu verbauen. Optimal wäre ein 2CH Aktor (Platine) mit 2CH Sensor, welche als ein Device angesprochen werden können. Mit zu vielen Transceivern so dicht beieinander habe ich schon schlechte Erfahrungen sammeln können, vor allem, wenn die sich gegenseitig über FHEM triggern. Die stören sich dann gewaltig gegenseitig. So bald einer sendet, sind die anderen Taub...
Dahin gehend zielte auch meine Frage, ob es nicht zufällig ein HM- Gerät gibt, was eben quasi zwei Aktoren und zwei Sensoren beherbergt, welches man dann zweckentfremden könnte

Pf@nne

Moin,

wie wäre ein ESP8266 der die Rückmeldungen über 2 GPIOs einkoppelt und dann per WLAN/MQTT bereitstellt?
Minimaler Hardwareaufwand und kostengünstig....

Es wären sogar noch zwei GPIOs zum Schalten frei... 8)

Gruß
Pf@nne
FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

... hmmm ... Kann ich das? Hardware? Klar! Software? Nö, zu doof zu ^^
Fällt daher leider aus, auch wenn die Idee natürlich optimal wäre. Alles in ein kleines Hutschienengehäuse geklebt, mit den sowieso vorhandenen 12V versorgen ud alles ist... ähhh... wäre schön...

Pf@nne

Die Software für den ESP8266 könnte ich dir machen, dass ist nicht wirklich aufwendig.
Du müsstest dann aber noch einen MQTT-Broker z.B. auf einem Raspberry laufen lassen.
Hast du einen Raspberry im Dauereinsatz?
FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

... das wäre natürlich voll super und nett!

Die Hauptinstanz läuft auf einem XEON und dort läuft Moskitto bereits, um blockadefreie Kommunikation mit den anderen (FHEM-) Systemen bereit zu stellen. Das wäre also bereits erledigt.

Was brauche ich woher an Hardware? Oder hast du noch was an Hardware auf Tasche, was du mir fettisch programmiert gegen Taler überlassen würdest?

Pf@nne

Bis wohin kommst du denn selber weiter?
Reicht es 4 GPIOs eines ESP8266 zu programmieren?


  • 2 x GPIO->OUT von MQTT ON/OFF
  • 2 x GPIO->IN auf MQTT ON/OFF

FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

.... ja, das würde vollkommen ausreichen, wenn ich dazu noch gesagt bekomme, wie aus FHEM die beiden Ausgänge anzusprechen resp. die Eingänge abzufragen sind. Die Hardware dahinter ist, zumindest für mich, ein Klacks ...

Pf@nne

OK, schaue ich am WE mal, sollte nicht so wild sein....

Gruß
Pf@nne
FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

... suppie!  8) Mein Dank wird dir ewig hinterher schleimen  ;D ;D

kleinerDrache

Wenn das Schütz Hilfkontakte hat warum dann nicht ein HM-8-Kanal-Sendemodul für die Rückmeldung nutzen ? Und zum Schalten den Komplettbausatz 8-Kanal-Empfangsmodul. Sind zwar wieder 2 Module dicht an dicht aber man könnte noch weitere Schütze schalten und überwachen. Die Ankopplung zum schalten natürlich auf das Schütz und den Empfänger angepasst.
Raspi 2 - Hmusb2 , 2xJeeLink , EnOcean pi: Serie14 Geräte , 6xHM-Sec-Rhs , 6xHM-CC-RT-DN, verschiedene MySensor Nodes, ein bischen MQTT

Pf@nne

Zitat von: M_I_B am 27 Oktober 2016, 20:08:14
... suppie!  8) Mein Dank wird dir ewig hinterher schleimen  ;D ;D

Naja, noch ist ja nix fertig, ist ja erstmal nur heiße Luft und tote Fliegen..... ::)
FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

... ja, daran hatte ich auch schon gedacht, vor allem deshalb, weil ich davon noch ein paar rumliegen habe. Aber wie du schon sagtest; wieder zwei Transceiver dicht an dicht... Außerdem hasse ich Verwendung von (hier)12 Kanälen ;) Weitere Schütze werden da nicht rein kommen. Die Kiste wird autark mit eigener UPS (BleiGel) und Notabwurf...

@ Pf@nne : Zum Thema "tote Fliegen" hätte ich noch was: http://steamradio.de/thread/42-fliegenpatschen-power-mod/  ;D ;D ;D

Muschelpuster

#14
Nun, Du bist Schaltungstechnisch doch fit! Man könnte doch auch die nicht benötigten Schaltkanäle für die Rückmeldung nutzen! Dazu braucht es nur ein klein wenig Logik. Die Schaltmodule können ja auch lokal am Taster geschaltet werden.
Wenn man nun den Ausgang vom Schaltkanal 3 mit dem Schaltzustand vom Schütz 1 vergleicht, dann könnte man dem Tastereingang ja einen Impuls geben, wenn die ungleich sind. Also eigentlich nur auf ein XOR-Gatter. Und wenn man lokal umschaltet wird dies an FHEM gemeldet. Und fertig ist die Laube 8)
Wenn man es jetzt ganz fein machen will, kommt hinter den XOR-Ausgang noch ein astabiler Multivibrator, der irgendwo mit 0,5Hz läuft, um ein Hängen der Mimik zu verhindern, wenn das Schaltmodul die Ein-Flanke ignoriert. Dann wird eben so lange getastet, bis das Modul es kapiert hat!

verdrehte Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

kleinerDrache

Ansonsten gibet da noch MySensors mit passendem Node (würde Door und Relay Node kombinieren) allerdings würde ich da dann eher die RFM69 Variante von Bauen wegen der Reichweite.
Raspi 2 - Hmusb2 , 2xJeeLink , EnOcean pi: Serie14 Geräte , 6xHM-Sec-Rhs , 6xHM-CC-RT-DN, verschiedene MySensor Nodes, ein bischen MQTT

M_I_B

@ Muschelpuster: Coole Idee; wieso komme ich nicht auf so etwas :o
@ kleinerDrache: Auch interessant; kannte ich noch gar nicht. Da werde ich mich auch mal durchhangeln.

Allgemein finde ich diesen Fred mit jedem Beitrag besser. Das wächst sich so langsam zu einer Sammlung verschiedener Möglichkeiten und Optionen aus; sollte man sich in die Fav's legen ;) Vielleicht kommen ja noch ein paar Versionen einer Lösung dazu. Sicherlich je nach Aufgabenstellung für jeden Frickler interessant zu lesen ...

Also für die Schütz- Sache bleibe ich erst mal bei der Idee von Pf@nne. Das scheint mir für den Anwendungsfall das derzeitige Optimum, da zum einen per (W)LAN angebunden und somit quasi unabhängig von der Reichweite der Transceiver, zudem per MQTT o.ä. auch aus anderer Richtung ansprechbar. Jedoch werde ich mir die anderen Optionen auch mal ganz genau anschauen und im Falle der 8ch- Platine auch mal ein bisschen probieren, da bereits vorhanden. Die Schütz- Aktion ist bei weitem noch nicht die letzte Aufgabe hier im Haus und für die meisten Dinge braucht es halt nicht nur einen Aktor, sondern oft einen entsprechenden Rückkanal, um den tatsächlichen Zustand und Fehler erfassen zu können.


kleinerDrache

ok ;) viel spaß beim rumbasteln.

Langsam müssen mich hier einige für verrückt halten weil ich immer wieder auf MySensors verweise *lach* aber ich finde mit dem zeug lässt sich halt so ziemlich alles erschlagen und das für wenig Geld.
Übrigens kann MySensors auch MQTT ;)
Raspi 2 - Hmusb2 , 2xJeeLink , EnOcean pi: Serie14 Geräte , 6xHM-Sec-Rhs , 6xHM-CC-RT-DN, verschiedene MySensor Nodes, ein bischen MQTT

LuckyDay

@M_I_B
Villeicht hab ichs überlesen
Schalten zweier 64A Schütze, was schaltest du den , Anwendung Spannung,
reine Neugier mal wieder :)

Wuppi68

[ironic]
bei 64A dürfte auch der Blitzdetektor schon sicher funktionieren
[/iromic]
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

thosch

Die 64A Schütze machen den Thread interessant.
Erinnert mich an meine Ausbildung.
Ich tippe mal auf Tor-Steuerung.
Gruß Thorsten

M_I_B

... die Schütze trennen bei Netzausfall das ganze Haus und die PV vom Versorger, so das der Notstrom nicht die ganze Nachbarschaft mit versorgen muss, was ihm nun doch mit seinen schlappen 5kW recht schwer fallen würde ;)
Haken dabei ist, das nach Trennung erst der Generator anlaufen muss (so lange übernehmen für wichtige Dinge UPS), bevor ich den und dann die WR der PV (bei Sonne versteht sich) zuschalten kann, nachdem sich das Niveau und Frequenz stabilisiert hat.
Am frickeln bin ist noch bei der Synchronisation bei Netzwiederkehr, da ich möglichst unterbrechungsfrei zurückschalten will. So'n simplen Benziner zu syncen hat seine Tücken... Derzeit experimentiere ich mit OPV's, die den Vergleich der Phasensync machen, steuere damit einen RC-Servo, der wiederum die rein mechanische Regelung der Gen-Drehzahl +/- 5% übersteuern kann... Da aber die Last ordentlich Einfluss auf die Drehzahl und somit Frequenz hat und die Last kaum zu kalkulieren ist (anspringende oder abschaltende Kühlschränke, Thermostate u.s.w.), funktioniert das noch nicht wirklich gut. Der ist nicht träge genug, die Regelung zu träge und rennt mir zu schnell wieder aus der Phase...

Vielleicht sollte ich die Sache noch mal überdenken, an Stelle des Gen eine 5-10kW APC einsetzen und die dann mit dem Gen befeuern... Nur dann muss die UPS immer mitlaufen, was eigentlich auch nicht wirklich effektiv ist... Naja... hat Zeit.. Winter kommt... Bastelzeit ;)

Pf@nne

Zitat von: M_I_B am 28 Oktober 2016, 08:04:50
... die Schütze trennen bei Netzausfall das ganze Haus und die PV vom Versorger, so das der Notstrom nicht die ganze Nachbarschaft mit versorgen muss, was ihm nun doch mit seinen schlappen 5kW recht schwer fallen würde ;)
Haken dabei ist, das nach Trennung erst der Generator anlaufen muss (so lange übernehmen für wichtige Dinge UPS), bevor ich den und dann die WR der PV (bei Sonne versteht sich) zuschalten kann, nachdem sich das Niveau und Frequenz stabilisiert hat.
Am frickeln bin ist noch bei der Synchronisation bei Netzwiederkehr, da ich möglichst unterbrechungsfrei zurückschalten will. So'n simplen Benziner zu syncen hat seine Tücken... Derzeit experimentiere ich mit OPV's, die den Vergleich der Phasensync machen, steuere damit einen RC-Servo, der wiederum die rein mechanische Regelung der Gen-Drehzahl +/- 5% übersteuern kann... Da aber die Last ordentlich Einfluss auf die Drehzahl und somit Frequenz hat und die Last kaum zu kalkulieren ist (anspringende oder abschaltende Kühlschränke, Thermostate u.s.w.), funktioniert das noch nicht wirklich gut. Der ist nicht träge genug, die Regelung zu träge und rennt mir zu schnell wieder aus der Phase...

Vielleicht sollte ich die Sache noch mal überdenken, an Stelle des Gen eine 5-10kW APC einsetzen und die dann mit dem Gen befeuern... Nur dann muss die UPS immer mitlaufen, was eigentlich auch nicht wirklich effektiv ist... Naja... hat Zeit.. Winter kommt... Bastelzeit ;)

Mein lieber Herr Gesangverein.....und ich mache mir Sorgen, das ich es mit meiner Haustechnik zu weit treibe....... :o ;D
Hast du die Drehzalverstellung mit einem Zweipunktregler aufgebaut oder hast du da einen "echten" Regelkreis aufgebaut?

Gruß
Pf@nne
FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

... tja, ich bin halt etwas anders gestrickt ;)

Naja, Regelkreis trifft es annähernd ... Ich vergleiche ja über die OPV's die Phasenunterschiede Netz / GEN. Je nachdem, ob der Phasenwinkel des GEN vor- oder nacheilt, versuche ich via Servo sanft die Drehzahl etwas zu erhöhen oder zu verringern. Der Servo zupft dabei an zwei Federn, welche die mechanische Regelung via Stauflügel zusätzlich be- oder entlastet. Das funktioniert bei konstanter Last auch ziemlich gut. Aber wie gesagt ist der GEN nicht träge genug; dem fehlt einfach Schwungmasse, so das er bei Hinzukommen oder Wegfall einer Last kurz in die Knie geht resp. überdreht... und schwups bin ich wieder asynchron... So schnell lässt sich ein Verbrenner halt nicht nachregeln.
Was ich auch noch nicht probiert habe ist, was denn passiert, wenn ich ihn halbwegs synchron habe und auf's Netz lege. Je nach Spannungsniveau wird der GEN dann ja be- oder entlastet, was in erneut aus dem Tritt bringt. Da er dann aber bereits mit dem Netz verbunden ist und Dieses ganz sicher nicht nachgibt, stellt sich die Frage, ob der GEN sich dann selbst mitziehen lässt und synchron bleibt oder ob dann die Sicherungen stiften gehen... Sollte ich vielleicht einfach mal mit entsprechendem Sicherheitsabstand und Feuerlöscher bei Fuß antesten...  8)

Es gibt von Honda eine Generatorfamilie, die das anders macht. Die erzeugen irgendwie eine Spannung, die nichts mit der Netzspannung zu tun hat, nehmen diese Spannung und erzeugen via Halbleiter- Wandler eine resp. drei Phasen. Die sind echt super konstant in Frequenz und Spannung, auch bei wechselnder Last. Zudem lassen sich diese Generatoren über einen Anschluss synchronisieren, so das man tatsächlich mehrere parallel schalten könnte. In meinem Fall würde die Sync dann natürlich mit dem Netz erfolgen... Nur... Die Dinger sind sowas von übel teuer...  :'(

BTW: Gibt es Schütze mit zwei Wicklungen und 3P- Umschalter? Also im Grunde zwei klassische 3p- Schütze, deren Anker derart miteinander verriegelt sind, das immer nur eine Seite geschlossen sein kann und die andere Seite dann zwangsweise offen sein muss? Wenn die schnell genug wären und sich innerhalb einer Halbwelle umschalten ließen, wäre das eine Option...

KölnSolar

Zitatdie WR der PV (bei Sonne versteht sich) zuschalten
und das klappt ? weigern sich da nicht ENS/NA-Schutz der Wechselrichter ?
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

M_I_B

... auch in Unkenntnis dessen, was ein "ENS/NA-Schutz" ist ... Ja, bei den bisherigen, manuell eingeleiteten Versuchen hat das funktioniert. Es muss nur bereits eine halbwegs stabile Spannung anstehen und dann schalten die sich selber auf. Ohne vorhandene Spannung machen die WR nix...
Versuchsaufbau: Generator warm gelaufen und stabil > ein paar Heizlüfter. Dann die WR vom "echten" Netz genommen und stumpf auf dieses Konstrukt geklemmt... Nach ca. 10 Sekunden sind die WR eingestiegen...
Was ich allerdings nicht weiß resp. probiert habe ist, was bei sinkender Last passiert. Laufen die WR dann mit ihrer Ausgangsspannung hoch, schalten die sich ab oder wie? Kommt mir jetzt erst...

kleinerDrache

Raspi 2 - Hmusb2 , 2xJeeLink , EnOcean pi: Serie14 Geräte , 6xHM-Sec-Rhs , 6xHM-CC-RT-DN, verschiedene MySensor Nodes, ein bischen MQTT

M_I_B

... ah, ok ... Dann wird das damit zu tun haben, das meine WR bei Netztrennung sofort die Produktion einstellen; machen die auch, ich wusste nur nicht den Fachausdruck ...

pc1246

Hallo Micha
Du treibst ja ganz schoen Aufwand fuer einen Stromausfall! Wie oft und lange kommt das denn bei Dir vor? Bei mir waren im letzten Monat mal zwei drops, ansonsten ewig nichts!
Gruss Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

KölnSolar

ZitatUnkenntnis dessen, was ein "ENS/NA-Schutz"
einfach: kein netz  --> Wr aus
komplizierter: der wr schaltet nur zu oder wieder ab, wenn enge Spannungs- u. Frequenzbereiche eingehalten werden. Und das dürfte schwierig werden mit dem Generator
ganz kompliziert: Stichwörter SysStabV und VDE-AR-N 4105
was bei Deinen Wr's vorliegt, siehst Du auf dem Typenschild: alt:VDE 0126 neu: VDE-AR-N 4105 und bei alt > 10 kWp war dann unsereiner da und hat je nach wr-Hersteller indiv. Anpassungen gem. SysStabV vorgenommen.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

M_I_B

... ah, ok ...
Dann werde ich heute Abend mal schauen, was da auf meinen WR's steht. Zumindest mit konstanter Last hat das funktioniert. Wie sich das bei wechselnder Last und somit Frequenzschwankungen verhält, kann ich nicht sagen, da in Unkenntnis nicht überprüft.
Das werde ich aber nachholen, sobald die WR vom Dachboden neben den Zählerschrank verlegt wurden; die produzieren mir da oben zu viel QRM...

M_I_B

... ich bin noch nicht zum Schauen gekommen; zu viele andere Baustellen. Aber einen Hinweis auf die Schütz-mit-Gleichspannung-Nummer aus dem Initial:
Trotz 12V Eingang und Kühlkörper werden die Regler doch ordentlich warm... Geht, aber ist nicht schön... Daher ein Update...
Ich habe heute aus ChinaLand eine Tüte voll kleiner 2A Schaltregler bekommen, die sich per Poti einstellen oder per Lötbrücke auf bestimmte Spannungen "programmieren" lassen. Das hat mich dann gejuckt, ob man die nicht für diesen Trick verwenden kann... Man kann, und das richtig gut ;)
Benötigt wird ein BC848, ein 10µ/6V (beides SMD) und der Einfachheit halber einen klassischen 680k Widerstand. der BC wird mit C an den Programmieranschluss 9V, mit E an die dazu gehörende Sammelschiene gelötet. Die Basis dann hochbiegen, den 10µ (+ zur Basis) dran und andere Seite auf die Massefläche löten (vorher freikratzen und verzinnen). Von der Basis dann noch den Widerstand an den Ausgang des Reglers... fertig is dat.... Mit dem Poti kann man dann von ca. 9V herunter auf bis zu 1V Haltespannung einstellen; perfekt.
Wird auch bei Dauerbetrieb nicht warm, passt mit seinem 2.54 Raster direkt und hat zudem einen EN- Eingang, der sich direkt per µC OC schalten lässt. Somit entfällt auch eine Treiberstufe oder Relais zum Schalten des Schütz.


Pf@nne

#32
Moin Micha,

ich mal was zusammenkopiert.....schicke mir mal deine Adresse per Mail oder PN.
Ich habe es auf einen WEMOS mini geflasht. Der ist schon mit USB-versorgung, also Plug&Play. 8)
https://www.wemos.cc/product/d1-mini.html

Die beiden Rückmeldungen der Hilfskontakte werden auf:

  • Relais_01 -> D5 -> MQTT-publish ESP8266_1033320/Switch/Status/Relais_01 "on" / "off"
  • Relais_02 -> D6 -> MQTT-publish ESP8266_1033320/Switch/Status/Relais_02 "on" / "off"
HIGH-Aktiv eingekoppelt (Pull-Up nicht vergessen).

Die Schütze steuerst du auf:

  • Relais_01 -> D7 -> MQTT-subscribe ESP8266_1033320/Switch/CMD/Relais_01 "on" / "off
  • Relais_01 -> D8 -> MQTT-subscribe ESP8266_1033320/Switch/CMD/Relais_02 "on" / "off

Beim ersten Start spannt der ESP8266 einen Accesspoint auf, das WebIF für die konfiguration deines WLANs und des MQTT-Brokers findest du dann auf der IP 192.168.4.1.

  • SSID: ESP8266_1033320
  • Pass: ESP8266config

Sonst auch hier nochmal nachlesen:
https://forum.fhem.de/index.php/topic,50238.msg419846.html#msg419846
https://forum.fhem.de/index.php/topic,50238.msg431833.html#msg431833

Viel Spaß damit.....
Pf@nne

FHEM auf: DS415+ (Master), Raspberry Pi 2

Muschelpuster

Das Ganze müsste doch auch ohne MQTT und SW-Eingriff mit dem ESPeasy-Projekt gehen, oder?
https://forum.fhem.de/index.php/topic,55728.0.html

nachfragende Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

M_I_B

Zitat von: Pf@nne am 29 Oktober 2016, 17:35:01ich mal was zusammenkopiert.....schicke mir mal deine Adresse per Mail oder PN.

Hey! Is ja super! Das WE hat ja noch nicht mal richtig angefangen!

Ich melde mich gleich per PN...

Ganz offiziell allerbesten Dank für deine Mühe!

Pf@nne

#35
Moin Micha,

ZitatJetzt bin ich so weit, das ich mich mal an den Code wagen möchte, den du da für mich verbrochen und in das Ding geflasht hast. Ich würde gerne ein paar Kleinigkeiten ändern, wie z.B. den Zustand der OUT's umdrehen, da z.Z. invertiert...
Kann ich den mit der Arduino- Software auslesen? Oder bekomme ich da nur HEX? Wenn nicht, schiebst du mir bitte mal den Quellcode rüber?

Auslesen zum Bearbeiten geht erstmal nicht...

Den Code habe ich dir angehängt, ist aber alles noch alpha-Stadium.....
Den ZIP mit den Librarys musst du nach /user/dokumente/arduino/libraries kopieren.
Zusätzich musst du noch das ESP8266-Board installieren.
Das findest du unter http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/110-hello-led-das-erste-lebenszeichen
Kann sein, dass noch weitere Libraries fehlen.

Vielleicht solltest du auch erstmal eine LED blinken lassen....
um dann voll einzusteigen......

Gruß
Pf@nne
FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

... naja, Alpha- Stadium ist das für mich nicht mehr, da es genau so funktioniert wie es soll. Also aus meiner Sicht schlechtenfalls BETA ;)
Ich habe mir jetzt erst mal ein paar ChinaKracher bestellt, denn an dem von dir Überlassenen will ich so nichts machen. Verschiedene Hutschienengehäuse dafür kommen wohl morgen und dann wird das dort kommende Woche verbaut und in Betrieb genommen. Wenn dann die Teile aus ChinaLand da sind, werde ich mich an denen versuchen und wenn das gut geht, tausche ich einfach. Dann kann ich auch in Ruhe erst mal eine LED blinken lassen und mich dann an das Umschreiben machen, falls ich da denn dran lang blicke...
So oder so eine ziemlich geile Nummer, gerade in Verbindung mit den per EN steuerbaren StepDown's. Ich habe in dem Zusammenhang noch etwas rumprobiert und feststellen können, das diese StepDown sich direkt via Diode vom Port aus steuern lassen. Dazu ist ein PullDown 4k7 gegen Masse geschaltet und der Port steuert über ne schnöde 4148 den EN auf. Damit ist gewährleistet, das die Schütze erst dann aktiv werden, wenn die komplette Peripherie bereit ist; fällt die Stromversorgung und/oder der WeMos aus, fallen die Schütze ab.
Solch ein StepDown macht auch die Stromversorgung für die ganze Geschichte, also aus den 12V für die Schütze die 3v3 für den WeMos (über R-C-R-C - Filter). Auch da könnte man dafür sorgen, das der WeMos erst verzögert seine 3v3 erhält, wenn die 12V einwandfrei stehen; der EN der Stepper scheint eine SchmidtTrigger- Funktionalität zu haben; teste ich noch explizit aus, da Dokumentation bei ChinaKrachern wie üblich Fehlanzeige ist...

Pf@nne

Zitat von: M_I_B am 04 November 2016, 10:51:15
... naja, Alpha- Stadium ist das für mich nicht mehr, da es genau so funktioniert wie es soll. Also aus meiner Sicht schlechtenfalls BETA ;)

Da ist schon noch einiges zu tun, ist alles so gewachsen, da müsste mal aufgeräumt werden.
Vordringlich wollte ich die TopicTrees mal in einen JSON-File im FS auslagern.
Dann können die Topics nachträglich geändert werden.....

Gruß
Pf@nne
FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

... au menno  >:(
Jetzt habe ich einige Tage mal was ganz anderes gemacht und schon bin ich vollkommen raus und stehe wie der Ochs vor'm Berg *MeggerSchimpf*

Also... Ich habe heute mal den Prototypen des Hutschienen- Aktors mit dem WeMos auf Lochraster geklebt (siehe unten). Der tut so weit vollkommen schmerzfrei. Dazu habe ich in Fhem ...

define PULL_ESP01 MQTT_DEVICE ESP01
attr PULL_ESP01 IODev MQTT
attr PULL_ESP01 room MQTT
attr PULL_ESP01 stateFormat transmission-state
attr PULL_ESP01 subscribeReading_S1 ESP01/Switch/Status/Relais_01
attr PULL_ESP01 subscribeReading_S2 ESP01/Switch/Status/Relais_02

define PUSH_ESP01 MQTT_BRIDGE ESP01
attr PUSH_ESP01 IODev MQTT
attr PUSH_ESP01 publishReading_R1 ESP01/Switch/CMD/Relais_01
attr PUSH_ESP01 publishReading_R2 ESP01/Switch/CMD/Relais_02
attr PUSH_ESP01 publishReading_state ESP01/state
attr PUSH_ESP01 room MQTT
attr PUSH_ESP01 stateFormat transmission-state

define ESP01 dummy
attr ESP01 readingList R1 R2 S1 S2
attr ESP01 room MQTT
attr ESP01 setList R1:on,off R2:on,off


define set_ESP_1 DOIF ([PULL_ESP01:S1] eq "on") (set ESP01 S1 on) DOELSE (set ESP01 S1 off)
define set_ESP_2 DOIF ([PULL_ESP01:S2] eq "on") (set ESP01 S2 on) DOELSE (set ESP01 S2 off)
#define set_ESP01 notify PULL_ESP01 set ESP01 $EVENT <<< Geht so nicht; schade eigentlich :(


... geschreibselt. Dsa geht so weit eigentlich auch. Aber mich nerven hier zwei Dinge, die ich nicht gesch.. gebacken bekomme:

1.
Ich habe jetzt notgedrungen für das Senden der Befehle zum WeMos ein MQTT- Device und zum Empfangen der Stati eine MQTT- Bridge.
Frage ist, ob man das nicht irgendwie in einem Device/Bridge zusammenfassen kann?

2.
Man beachte bitte die auskommentierte "notify" am Ende. Geht so natürlich nicht, da er dann in "state" z.B. "S1:on" ballert und nicht in die Reading S1 resp. S2
Frage hierzu: Geht das schlauer/besser als mit DOIF irgendwie?


EDIT: Und noch ein schwerwiegenderes Problem...
Nehmen wir an, R1 ist angezogen und R2 abgeworfen (Standard- Einstellung, SOLL auch nach Netzwiederkehr). Nun nehme ich das Netz weg und simuliere einen Netzausfall.
So, und nun kommt zwar R1 bei Netzwiederkehr für einige Sekunden, wird dann aber abgeworfen. R2, falls bei Netzausfall aktiv, wird NICHT wieder aktiv wie R1

Mit dem MQTT-Spy ist festzustellen, das der Status von R2 auf ON bleibt, obwohl definitiv abgeworfen (der Status wird durch einen Hilfskontakt des Schütz an den WeMos gemeldet), der Status von R1 wird nach Netzwiederkehr korrekt angezeigt.
Der Aktor selber steht aber immer noch in beiden Fällen auf ON. der bekommt das gar nicht mit, das zwischenzeitlich ein Netzausfall vorhanden war. Man muss also nun explizit ein OFF senden und ein ON hinterher, damit die Schütze einen definierten Status erhalten.

Um das Problem zu verdeutlichen, habe ich mal ein Video gemacht unter http://steamradio.de/_filez/_FHEM/problem_01.avi (8,5mb)

EDIT 2: Was ich noch machen könnte ist, den WeMos mit einem Elko/GoldCap zumindest so lange am Leben zu lassen, bis er den tatsächlichen Status an Muttern gemeldet hat. ABer das ist im Grunde nur Symptom- Behandlung und klärt auch nicht das ungleiche Verhalten der beiden Kanäle

Pf@nne

FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

... "dein" Code; ich habe da noch nichts dran geändert, da ich mit anderen Dingen etwas überbeschäftigt war ...
Ist also noch dein Okkinol, wobei auch die Ausgangs- und Eingangszuweisung gleich ist (R1/S1 = Schütz 1)

Pf@nne

Dann brauchst du doch aber nur deinen Wunschstatus beim Starten vorgeben und den Status an den Broker publishen....

void setup() { 
  Serial.begin(115200);
  Serial.println("");
 
  espClient.start_WiFi_connections();

  pinMode(R1_OUT, OUTPUT);
  pinMode(R2_OUT, OUTPUT);

  digitalWrite(R1_OUT, HIGH);
  espClient.pub(4,0,0, "on");
  digitalWrite(R2_OUT, LOW); 
  espClient.pub(4,0,1, off);


FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

... bei dir hört sich das immer so einfach an  ::)

Ok, werde ich mich am WE mal dran machen. Mal sehen, ob ich das hin bekomme. Dazu muss ich aber den WeMos wieder ausbauen, damit ich an den USB komme, oder?

und den Status an den Broker publishen....
ja, aber den Status der Eingänge, nicht der Ausgänge. Wichtig bei der ganzen Sache ich halt, das NIE beide Schütze abgefallen sein dürfen (außer bei Netzausfall natürlich) und auch erst Schütz2 sauber geschlossen sein muss, bevor Schütz1 abgeworfen werden kann. Also möglich Stati sind der Reihe nach :

  • R1=0, R2=0 (Netzausfall)
  • R1=1, R2=0 (Standard)
  • R1=1, R2=1 (Sync)
  • R1=0, R2=1 (Autark)
  • R1=1, R2=1 (Sync)
  • R1=1, R2=0 (Standard)
Am liebsten hätte ich für Schütz1 einen 3PNC+1NC+1NO genommen, aber oberhalb 16A sind die Teile jenseits der 200,-€ exorbitant teuer... Noch besser wären zwei motorisch betriebene Spannfeder- Schalter (die sind bistabil), aber an die kommt man erst gar nicht dran ...

Pf@nne

Moin,

Zitat von: M_I_B am 01 Dezember 2016, 10:02:13
Dazu muss ich aber den WeMos wieder ausbauen, damit ich an den USB komme, oder?

Nö, in der FW sind drei verschiedene OTA (Over The Air) implementiert.
Schaust du hier....
http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/133-ota-esp8266-over-the-air-flashen

Gruß
Pf@nne
FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

... das muss aber erst eingebaut werden? Oder hattest du da zumindest eine Option schon implementiert?
... sorry, bin noch etwas wirr im Kopp  ??? ::)

Pf@nne

Sollte drinn sein, gehe mal auf das WEB-IF des Controllers.....
Da gibt es einen Flash-Button, dann kannst6 du die *.bin auswählen....
FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

japp, is da ;) Also mit dem Andruino- Dingens die Änderungen machen, kompilieren und das BIN daraus über die WebUI hochsenden? So in etwa?

Pf@nne

FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

... ok, ich werde es mal versuchen; du rettest mich, wenn ich's verkacke?  ;D

EDIT 1:
Geht schon los... Sind die Dateien, die ich von dir bekommen habe:
ESP8266_Basic.h" enthält unbekannte Zeichen. Wenn der Code mit einer älteren Version von Arduino erstellt wurde, sollten Sie eventuell über Werkzeuge -> Kodierung korrigieren & neu laden den Sketch auf UTF-8-Kodierung aktualisieren. Wenn nicht, sollten Sie die ungültigen Zeichen manuell entfernen, um diese Warnung zu deaktivieren.

"ESP8266_Basic_data.cpp" enthält unbekannte Zeichen. Wenn der Code mit einer älteren Version von Arduino erstellt wurde, sollten Sie eventuell über Werkzeuge -> Kodierung korrigieren & neu laden den Sketch auf UTF-8-Kodierung aktualisieren. Wenn nicht, sollten Sie die ungültigen Zeichen manuell entfernen, um diese Warnung zu deaktivieren.

Korrektur habe ich natürlich versucht, hilft aber nix. Auch manuell (Notepad++) ist alles UNIX UTF8. Daran kann es also nicht liegen... Starte ich dennoch einen Comp- Versuch, erhalte ich ...
Arduino: 1.6.12 (Windows 7), Board: "WeMos D1 R2 & mini, 80 MHz, 921600, 4M (3M SPIFFS)"

In file included from C:\Users\Administrator\Desktop\WeMOS\MQTT_Switch\MQTT_Switch.ino:17:0:

sketch\ESP8266_Basic.h:57:30: fatal error: MySQL_Connection.h: No such file or directory

#include <MySQL_Connection.h>

                              ^

compilation terminated.

Mehrere Bibliotheken wurden für "ArduinoJson.h" gefunden
Benutzt: C:\Users\Administrator\Documents\Arduino\libraries\ArduinoJson
Nicht benutzt: C:\Program Files (x86)\Arduino\libraries\ArduinoJson
exit status 1
Fehler beim Kompilieren für das Board WeMos D1 R2 & mini.

Dieser Bericht wäre detaillierter, wenn die Option
"Ausführliche Ausgabe während der Kompilierung"
in Datei -> Voreinstellungen aktiviert wäre.

Für was braucht der MySQL?
Ich habe im Übrigen noch nichts geändert, sondern einfach mal stumpf versucht, deinen Sketch (richtig?) zu kompilieren ..

Pf@nne

Kommentiere MySQL einfach aus....

Basic.h

//MySQL
//#include <MySQL_Connection.h>
//#include <MySQL_Cursor.h>


ZitatFür was braucht der MySQL?
Ich möchte meine Sensorenwerte gleich in die FHEM dbLog Datenbank eintragen.
Damit wird FHEM entlastet.



FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

... aha ok; macht Sinn ;)

Aber ganz so einfach ist's dann doch nicht. Wenn ich das in der basic.h auskommentiere, rappelt es weitere Fehlermeldungen wie z.B. ... (Anlage).
Mir ist auch nicht klar, welche Dateien nur wirklich in dem Verzeichnis liegen müssen. Die *.h ist klar, aber auch die *.cpp ? Ich habe es in beiden Varianten versucht mit gleichem Ergebnis; neu erstellt hat er aber die *.cpp nicht (oder wo anders?)
Mit fehlen hier stumpf die Grundlagen, um das auch nur annähernd zu durchblicken, was wo gebraucht wird und warum  :-[

kleinerDrache

zum ersten Fehler  kann ich dir nix sagen aber zum 2ten *gg*:

Da haste schlicht eine Library 2 mal im System .Einfach die Library "C:\Program Files (x86)\Arduino\libraries\ArduinoJson" rauskopieren (noch nicht löschen) und sehen ob es dann kompiliert.
Raspi 2 - Hmusb2 , 2xJeeLink , EnOcean pi: Serie14 Geräte , 6xHM-Sec-Rhs , 6xHM-CC-RT-DN, verschiedene MySensor Nodes, ein bischen MQTT

M_I_B

.... nnnnnöööö ;)

C:\Program Files (x86)\Arduino\libraries\ ist leer. Die liegen offensichtlich alle in ...

C:\Users\Administrator\Documents\Arduino\libraries\

Und da ist "ArduinoJson" nur einmal drin ...

Pf@nne

Ich packe nachher nochmal mein gesamtes Library Verzeichnis....
Welche Arduino-Version nutzt du?
FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B


Pf@nne

Moin,

nimm mal die MySQL-Library mit rein, frisst ja kein Brot.....

1.6.12 läuft dann bei mir durch....
FHEM auf: DS415+ (Master), Raspberry Pi 2

kleinerDrache

ok ok nicht gleich hauen *gg*

aber wenn ich mich recht erinnere willst du nen ESP Programmieren der hat noch seinen eigenen Lib Ordner . Nutzt du Windows oder Linux ?

Sollte ich mich mit dem ESP vertan habne vergiss alles was ich gesagt habe ansonsten schau mal bei
Linux : /home/"deinName"/.arduino15/packages/esp8266/hardware/esp8266/2.3.0/libraries/
Windows : C:/Documents and Settings/"deinName"/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.3.0/libraries/

der ESP braucht zum Teil angepasste Libs
Raspi 2 - Hmusb2 , 2xJeeLink , EnOcean pi: Serie14 Geräte , 6xHM-Sec-Rhs , 6xHM-CC-RT-DN, verschiedene MySensor Nodes, ein bischen MQTT

Pf@nne

Moin,

die "angepassten" Libs ergeben sich doch durch die Boardauswahl......
Ich nehme immer das "Generic ESP8266 Module" das passt für den 12e eigentlich immer.
FHEM auf: DS415+ (Master), Raspberry Pi 2

M_I_B

@ kleinerDrache: Na, Windoof ;) Und in dem angegebenen Pfad sind reichlich Sache drin, auch Dateien für den ESP... Das passt also...

@ Pf@nne: Mach ich. Allerdings würde ich bei Gelegenheit schon gerne "erarbeiten", warum das reine Auskommentieren so viel Stress macht. Denn z.B. 1wire brauche ich auf dem Teil auch nicht; könnte also auch raus. Letztlich habe ich immer das Bedürfnis, nicht unnötige und ungenutzte Sachen mitzuschleppen...
Ich mach jetzt erst mal und dann schauen wir weiter....

kleinerDrache

Pf@nne

ebend aber sein Kompiler mault ja nicht nur das MySQL fehlt sondern unten auch was von

Zitatcompilation terminated.

Mehrere Bibliotheken wurden für "ArduinoJson.h" gefunden
Benutzt: C:\Users\Administrator\Documents\Arduino\libraries\ArduinoJson
Nicht benutzt: C:\Program Files (x86)\Arduino\libraries\ArduinoJson
exit status 1

Da Er aber sagt der Ordner ist leer ...... irgendwo muss sich die IDE das ja herholen oder ?

Wähle ich halt den ESP als Target aus wird der ESP-Lib Ordner soweit ich weiß mit durchsucht. Deswegen sollte Er mal schauen ob da noch ne JSON-Lib mit reingraten ist die da nicht reingehört *gg*

@M_I_B
mit reinem auskommentieren der Lib ist es nicht getan auch ALLE Funktionen die sich auf die lib beziehen müssen dann raus sonst FEHLER. Einfach drin lassen ist da einfacher der ESP hat mehr als genug Speicher da stört ungenutzter Code nicht wirklich.
Raspi 2 - Hmusb2 , 2xJeeLink , EnOcean pi: Serie14 Geräte , 6xHM-Sec-Rhs , 6xHM-CC-RT-DN, verschiedene MySensor Nodes, ein bischen MQTT

M_I_B

... so, ich habe jetzt einfach mal nach "ArduinoJson.h" auf der ganzen Pladde gesucht. Taucht tatsächlich zwei mal auf (siehe Anlache) ...
Aber so wirklich passt das nicht zur Fehlermeldung, da ja die angeblich doppelte Datei ganz wo anders in einem leeren Ordner gefunden wird... Schlunz  :o ::)

Ansonsten...
Ich habe die MySQL jetzt auch dahin kopiert, wo die anderen alle sind (/user/admin.../...) so wie die manipulierten Dateien überschrieben mit jenen aus dem ursprünglichen Archiv. Dann habe ich noch mal probiert... Erfolglos... Also irgend etwas ist hier vollkommen glunzig. Ich mache das ganze Ding noch mal platt, sichere vorher die Biblios und kopiere die später nach Neuinstallation da hin, wo die Installation selbst die Biblios auch hingepackt hat... Mal sehen, was passiert...

EDIT:
So, alles platt gemacht, alle verdächtigen Verzeichnisse manuell gelöscht und RegCleaner drüber laufen lassen. Nach Neustart Arduino neu installiert. Dabei fällt auf, das nach der Installation unter "C:\Dokumente und Einstellungen\Administrator\AppData\Local" resp. "C:\Users\Administrator\AppData\Local" kein Ordner angelegt wird.
´Vor dem ersten Start kopiere ich jetzt mal die gesicherten Libs dahin, wo die Installationsroutine die default- Libs auch hin kopiert hat.
... time goes by ...
shitt... Vergessen das ESP- Board in Arduino zu installieren... wo war noch mal der Pfad? ja, hier im Fred... ok... hab ihn ...
... time goes by ...
... tja ... Katzenkloo  >:( das war auch nix... Warum zur Hölle verteilt der willkürlich verschiedene Versionen wild auf der Festplatte? Donnerwetter noch mal  >:( >:( >:( So was hasse ich ja wie die Pest, wenn Programme nicht in ihrem eigenen Verzeichnis bleiben...

EDIT 2:
Als letzten Versuch habe ich noch mal "http://arduino.esp8266.com/staging/package_esp8266com_index.json" wegen OTA direkt aus Arduino eingebunden. Aber damit kennt er das Board gar nicht mehr (Arduino: 1.6.13 (Windows 7), Board: "Generic ESP8266 Module, 80 MHz, 40MHz, DIO, 115200, 512K (64K SPIFFS), ck, Disabled, OTA" // Board generic (Plattform esp8266, Paket esp8266) ist unbekannt // Fehler beim Kompilieren für das Board Generic ESP8266 Module.) und eine Option die Übertragung per OTA zu aktivieren finde ich auch nicht...

... und nu hab ich erst mal den Hals voll für heute  >:( Gute Nacht allerseits ...




Arduino: 1.6.13 (Windows 7), Board: "WeMos D1 R2 & mini, 80 MHz, 921600, 4M (3M SPIFFS)"

sketch\MQTT_Switch.ino.cpp.o:(.text.setup+0x10): undefined reference to `ESP8266_Basic::start_WiFi_connections()'

sketch\MQTT_Switch.ino.cpp.o: In function `HardwareSerial::begin(unsigned long)':

C:\Users\Administrator\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0\cores\esp8266/HardwareSerial.h:75: undefined reference to `ESP8266_Basic::start_WiFi_connections()'

sketch\MQTT_Switch.ino.cpp.o:(.text.loop+0x24): undefined reference to `ESP8266_Basic::handle_connections()'

sketch\MQTT_Switch.ino.cpp.o:(.text.loop+0x2c): undefined reference to `ESP8266_Basic::pub(int, int, int, char*)'

sketch\MQTT_Switch.ino.cpp.o:(.text.loop+0x40): undefined reference to `ESP8266_Basic::handle_connections()'

sketch\MQTT_Switch.ino.cpp.o: In function `loop':

C:\Users\Administrator\Documents\Arduino\WeMOS\MQTT_Switch/MQTT_Switch.ino:52: undefined reference to `ESP8266_Basic::pub(int, int, int, char*)'

C:\Users\Administrator\Documents\Arduino\WeMOS\MQTT_Switch/MQTT_Switch.ino:60: undefined reference to `ESP8266_Basic::pub(int, int, int, char*)'

sketch\MQTT_Switch.ino.cpp.o: In function `~ESP8266_Basic':

sketch/ESP8266_Basic.h:61: undefined reference to `ESP8266_Basic::ESP8266_Basic()'

sketch/ESP8266_Basic.h:61: undefined reference to `ESP8266_Basic::ESP8266_Basic()'

collect2.exe: error: ld returned 1 exit status

Mehrere Bibliotheken wurden für "Ethernet.h" gefunden
Benutzt: C:\Users\Administrator\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0\libraries\Ethernet
Nicht benutzt: C:\Program Files (x86)\Arduino\libraries\Ethernet
exit status 1
Fehler beim Kompilieren für das Board WeMos D1 R2 & mini.

Dieser Bericht wäre detaillierter, wenn die Option
"Ausführliche Ausgabe während der Kompilierung"
in Datei -> Voreinstellungen aktiviert wäre.

Omega-5

Zitat von: M_I_B am 02 Dezember 2016, 22:36:54
So, alles platt gemacht, alle verdächtigen Verzeichnisse manuell gelöscht und RegCleaner drüber laufen lassen. Nach Neustart Arduino neu installiert. Dabei fällt auf, das nach der Installation unter "C:\Dokumente und Einstellungen\Administrator\AppData\Local" resp. "C:\Users\Administrator\AppData\Local" kein Ordner angelegt wird.

Hallo Micha,

vieleicht mal die IDE nicht installieren, sondern als "portable" an eine Stelle auf der Platte entpacken, auf die Windows keine Zugriffsbeschränkungen oder Pfadersetzungen anwendet. Vorher natürlich die installierte Version restlos entfernen.

Ich trenne verschiedenen Versionen dadurch, dass ich die Arduino-IDE als portable anlege. Also auch mehrere Versionen nebeneinander. Beim kompilieren werden dann nur die Libraries benutzt die im Unterverzeichnis ./portable liegen.
Habe ich hier schon mal erklärt: https://forum.fhem.de/index.php/topic,58138.msg495778.html#msg495778

Gruß Friedrich
RaspberryPi2, nanoCUL, 3x DS18B20, FS20: 4x Funk-Schalter ST-4, LaCrosseGW,
HomeMatic: HMLAN, HM-WDS10-TH-O, HM_MYS_RelaisBoard,
I2C: HYT221 über modifiziertes Modul I2_I2C_SHT21.pm (Q&D),

M_I_B

Hallo Friedrich und alle anderen,

sorry wegen meiner späten Rückmeldung. Ich habe hier die ganze Bude voll wartender Reparaturen stehen, die natürlich alle bis Weihnachten fertig sein sollen :( Jedes Jahr das gleiche Theater: Weihnachten kommt wie immer vollkommen überraschend und unerwartet  ::)

Ich werde das mal mit der Portable genau so angehen, wie von dir beschrieben. Mal sehen, ob ich damit dann zu Rande komme. Sobald ich etwas Luft habe, werde ich mich dazu hier zurück melden...