Mikrocontroller über Ethernet verbinden

[Peter H. (borntopizza)]

Hi,

ich bin gerade dabei eine Steuerung für meine Fussbodenheizung zu bauen. 
Ich würde diese gerne über einen ATMEGA 328 via Ethernet steuern. Ich 
benutze ein enc28j60 Modul mit dem der Mikrocontroller über SPI mit dem 
Netzwerk verbunden ist.

Ich habe den Beispiel Sketch "Web Server" aus der "Ethercard.h" Library 
ein wenig angepasst, sodass ich die LED bzw. das Relais auch schon ein 
und ausschalten kann.

Nun möchte ich aber dass ein zweiter ATMEGA, der genau so mit dem 
Netzwerk verbunden ist, dem anderen ATMEGA sagt dass er jetzt das Relais 
ein bzw. ausschalten soll.

Müsste da der ATMEGA, der das Relais schaltet, als Client laufen und 
sich vom anderen (Web Server?) die Info holen "Relais an" bzw. "Relais 
aus" ?
Wie löst man so etwas am geschicktesten? Ich dachte anfangs daran auf 
der Website vom Web Server ein Feld zu machen, das entweder eine 1 oder 
eine 0 anzeigt. Das liest dann der Client und Schaltet dann.
Ich weiß leider nicht wie man diese Info mit dem Client aus der Website 
einliest.

Ich hoffe ihr könnt mir ein wenig auf die Sprünge helfen.

Danke und viele Grüße

Peter

[Wolfgang (Gast)]

Peter H. schrieb:
> Müsste da der ATMEGA, der das Relais schaltet, als Client laufen und
> sich vom anderen (Web Server?) die Info holen "Relais an" bzw. "Relais
> aus" ?

Die einfachste Lösung ist möglicherweise, wenn du die Information per 
UDP rüber schickst.

[STK500-Besitzer (Gast)]

Peter H. schrieb:
> Müsste da der ATMEGA, der das Relais schaltet, als Client laufen und
> sich vom anderen (Web Server?) die Info holen "Relais an" bzw. "Relais
> aus" ?
Jepp.

> Wie löst man so etwas am geschicktesten? Ich dachte anfangs daran auf
> der Website vom Web Server ein Feld zu machen, das entweder eine 1 oder
> eine 0 anzeigt. Das liest dann der Client und Schaltet dann.
> Ich weiß leider nicht wie man diese Info mit dem Client aus der Website
> einliest.

Dein Webserver liefert eine HTML-Seite, oder? (Du betreibst ihn momentan 
mit einem Browser vom PC aus).
Das ist eine Textdatei, die dein Client auswerten müsste.
Daten zum Server bekommst du per GET- (einfache Lösung) oder POST-Befehl 
(aufwendgere Lösung).
Wenn es eine Telnet-Library oder -Funktion gibt, brauchst du dich nicht 
um das HTTP-Gerafel kümmern, sondern kannst sie wie eine serielle 
Schnittstelle verwenden.

[Peter H. (borntopizza)]

Also der erste ATMEGA müsste ein Webserver sein, ich möchte den auch 
steuern können. Geht das dann dass der mit UDP eine Paket an den 2. 
schickt ? Ich finde nicht wirklich einen Sketch.. :-( Sorry ich kenn 
mich mit so kompliziertem Netzwerk Zeug nicht so gut aus

Die Website liefert der erste ATMEGA, an dem möchte ich sowohl die 
eigenen Ausgänge schalten können, als auch das Relais am Client.

Ist der GET Befehlt das mit dem Link (also 192.168.10.199/D5HIGH bzw. 
192.168.10.199/D5LOW) etc. ?


Danke und viele Grüße

Peter

[STK500-Besitzer (Gast)]

Peter H. schrieb:
> Ist der GET Befehlt das mit dem Link (also 192.168.10.199/D5HIGH bzw.
> 192.168.10.199/D5LOW) etc. ?

Jepp.
in dem Github-Repository, das ich gefunden habe ("google Ethercard.h"), 
gibt es auch ein Beispiel für einen WebClient.
Das wäre doch der Ansatz für dich.

[Stefan F. (Gast)]

Ich würde auch zum UDP Protokoll raten. Damit ersparst Du Dir einen 
großen Haufen Komplexität.

Bei UDP wird eine Nachricht wie eine Postkarte verschickt. Fire and 
forget. Was da drin steht, bleibt Dir überlassen. Betrachte eine UDP 
Nachricht als ein Array das du an eine Zieladresse sendest. Du brauchst 
keinen Verbindungsaufbau, kein Verbindungsende und auch der Aufwand für 
HTTP Header entfällt.

Es gibt nur drei Einschränkungen:
a) Die maximale Größe bestimmt das schwächste Glied in der Kette (1kB 
gehen praktisch immer).
b) Wenn du schnell nacheinander mehrere Nachrichten sendest, können sie 
durcheinander gewürfelt beim Empfänger ankommen. Aber nicht in lokalen 
Netzen, da ist die korrekte Reihenfolge sicher.
c) Wenn eine Nachricht aufgrund einer Übertragungsstörung nicht ankommt, 
findet keine automatische Wiederholung statt. Das passiert in lokalen 
Netzen nur äußerst selten.

Wenn du möchtest, kannst du den Empfänger natürlich so programmieren, 
dass er eine Bestätigung zurück an den Absender schickt. Und der 
Absender könnte bei ausbleibender Bestätigung eine Warnmeldung anzeigen 
oder mehrmals wiederholen.

Wenn du diesen Aufwand gar nicht brauchst, dann ist UDP auf jeden Fall 
viel einfacher, als TCP oder gar HTTP.

Es gibt bei UDP einen wesentlichen Vorteil: Die Nachrichten bleiben 
zusammenhängend. Wenn du drei mal 100 Bytes sendest, dann kommen beim 
Empfänger auch drei mal 100 Bytes an (außer bei Störungen). Bei TCP ist 
das nicht sicher. Jeder Router darf TCP Pakete sammeln und in geänderter 
Stückelung weiter reichen. Aus 3x 100 bytes könnte dein Router 1x 300 
bytes machen. Oder 1x 290 bytes und dann 1x 10 Bytes für den Rest. Ich 
habe beobachtet, dass dieser Effekt vielen Programmierern nicht bewusst 
ist. Sie fallen dann auf die Nase, wenn die Kommunikation die eigenen 4 
Wände überschreitet, zum Beispiel das Internet einbezieht.

UDP überträgt Nachrichten als Paket, aber ohne automatische Wiederholung 
bei Verlust und ohne garantierte Reihenfolge.
TCP ist mehr als Datenstrom gedacht, der aus Sicht der Endpunkte Bytes 
seriell übermittelt wie ein UART Kabel. TCP wiederholt im Fehlerfall 
automatisch.

[John Doe (Gast)]

Stefanus F. schrieb:
> Es gibt bei UDP einen wesentlichen Vorteil: Die Nachrichten bleiben
> zusammenhängend. Wenn du drei mal 100 Bytes sendest, dann kommen beim
> Empfänger auch drei mal 100 Bytes an (außer bei Störungen). Bei TCP ist
> das nicht sicher.


Fragmentierung findet auf Layer 3 statt, daher können UDP-Pakete sehr 
wohl fragmentiert werden, ohne dass man etwas dagegen machen kann (Auch 
das DF-Bit muss ein Router laut Standard nicht zwingend beachten).
Bei 100 Byte-Paketen passiert das aber sicherlich nicht.

[Stefan F. (Gast)]

John Doe schrieb:
> Fragmentierung findet auf Layer 3 statt, daher können UDP-Pakete sehr
> wohl fragmentiert werden, ohne dass man etwas dagegen machen kann (Auch
> das DF-Bit muss ein Router laut Standard nicht zwingend beachten).
> Bei 100 Byte-Paketen passiert das aber sicherlich nicht.

Soweit ich weiß werden UDP Pakete nur fragmentiert, wenn sie (für ein 
übertragendes Gerät) zu groß sind. 1kB geht immer am Stück durch.

[BornTOPizza (Gast)]

Hmm,

das mit dem WebClient hab ich noch nicht hinbekommen.

Der will sich anscheinend nicht richtig verbinden...

[webClient]
IP:  192.168.10.71
GW:  192.168.10.1
DNS: 192.168.10.1
DNS failed
SRV: 0.0.0.0

<<< REQ
<<< REQ

#include <EtherCard.h>

#define STATIC 1 // set to 1 to disable DHCP (adjust myip/gwip values below)

// mac address
static byte mymac[] = { 0x74,0x69,0x69,0x2D,0x30,0x31 };
// ethernet interface ip address
static byte myip[] = { 192,168,10,199 };
// gateway ip address
static byte gwip[] = { 192,168,10,1 };

// LED to control output
int ledPin10 = 7;

byte Ethernet::buffer[700];

char const page[] PROGMEM =
"HTTP/1.0 503 Service Unavailable\r\n"
"Content-Type: text/html\r\n"
"Retry-After: 600\r\n"
"\r\n"
"<html>"
"<head><title>"
"Service Temporarily Unavailable"
"</title></head>"
"<body>"
"<h3>This page is used behind the scene</h3>"
"<p><em>"
"Commands to control LED are transferred to Arduino.<br />"
"The syntax: http://192.168.0.XX/?LED10=OFF or ON<br />"
"<br />"
"Status:<br />"
"1"
"</em></p>"
"</body>"
"</html>"
;

void setup () {
pinMode(ledPin10, OUTPUT);

Serial.begin(9600);
Serial.println("Trying to get an IP...");

Serial.print("MAC: ");
for (byte i = 0; i < 6; ++i) {
Serial.print(mymac[i], HEX);
if (i < 5)
Serial.print(':');
}
Serial.println();

if (ether.begin(sizeof Ethernet::buffer, mymac, 8) == 0)
{
Serial.println( "Failed to access Ethernet controller");
}
else
{
Serial.println("Ethernet controller access: OK");
}
;

#if STATIC
Serial.println( "Getting static IP.");
if (!ether.staticSetup(myip, gwip)){
Serial.println( "could not get a static IP");
blinkLed(); // blink forever to indicate a problem
}
#else

Serial.println("Setting up DHCP");
if (!ether.dhcpSetup()){
Serial.println( "DHCP failed");
blinkLed(); // blink forever to indicate a problem
}
#endif

ether.printIp("My IP: ", ether.myip);
ether.printIp("Netmask: ", ether.netmask);
ether.printIp("GW IP: ", ether.gwip);
ether.printIp("DNS IP: ", ether.dnsip);
}

void loop () {

word len = ether.packetReceive();
word pos = ether.packetLoop(len);

// IF LED10=ON turn it ON
if(strstr((char *)Ethernet::buffer + pos, "GET /?LED10=ON") != 0) {
Serial.println("Received ON command");
digitalWrite(ledPin10, HIGH);
}

// IF LED10=OFF turn it OFF
if(strstr((char *)Ethernet::buffer + pos, "GET /?LED10=OFF") != 0) {
Serial.println("Received OFF command");
digitalWrite(ledPin10, LOW);
}

// show some data to the user
memcpy_P(ether.tcpOffset(), page, sizeof page);
ether.httpServerReply(sizeof page - 1);
}

void blinkLed(){
while (true){
digitalWrite(ledPin10, HIGH);
delay(500);
digitalWrite(ledPin10, LOW);
delay(500);
}
}

[Peter H. (borntopizza)]

Bekommt der UDP "Sender" auch eine eigene IP bzw. kann man den dann auch 
als WebServer verwenden?

[Stefan F. (Gast)]

Du machst hier genau den Fehler, auf den ich oben hinwies. Du gehst 
einfach davon aus, den kompletten GET Request an einem Stück (Paket) zu 
empfangen.

Ist das jetzt TCP oder UDP? Wenn TCP, wo reagierst du auf 
Verbindungsaufbau und Ende?

[Peter H. (borntopizza)]

Ich weiss nicht was für ein Protokoll hier verwendet wird, hier laufen 
die Beispiel Sketches Webserver und Webclient aus der EtherCard.h 
Library.  Mikrocontroller.net wird mir ausgegeben. Nur den Inhalt meines 
Webservers mag er nicht anzeigen.

Ich kann mir auch nicht erklären woran das liegt.
Wenn ich mit dem Browser am PC auf den Webserver zugreifen also 
192.168.10.199 wird mir die Seite korrekt dargestellt. Das ganze aber 
ohne https:// bzw. http:// davor.

Sorry dass ich hierzu nicht mehr sagen kann, aber ich hab selber wenig 
bis keine ahnung :-(

Trotzdem Danke!

[Stefan F. (Gast)]

Das ist offensichtlich HTTP Protokoll in der Versin 1.0. Informiere Dich 
mal wie das Protokoll funktioniert und dann benutzt du Wireshark, um die 
Kommunikation auf Netzwerk-Ebene zu untersuchen. Das Programm zeigt 
nicht nur die Kommunikation auf allen Ebenen an, sondern markiert auch 
Fehler.

[H.Joachim S. (crazyhorse)]

Warum willst du es denn überhaupt via Ethernet machen? Die Vorteile 
(Geschwindigkeit, Datenmenge) brauchst du nicht.

Es gibt doch so schöne Bussysteme, die genau dafür hervorragend geeignet 
sind (incl. einfacherer Verkabelung).

Bei mir läuft CAN mit lächerlichen 10kBit (bedingt durch die 
Junkers-Therme, damit hat alles angefangen) - was soll ich sagen: völlig 
ausreichend.

[Peter H. (borntopizza)]

Ja zum einen Liegen dort schon Cat Kabel, Wifi ist nicht möglich und ich 
möchte die Steuerungen über POE Speißen, das ist eigentlich auch der 
Hauptgrund für Ethernet. Zum anderen möchte ja die Heizung aus der Ferne 
steuern können. ( Das ganze dann mit einer VPN Verbindung zur Fritz Box 
)

[Karl M. (Gast)]

Hallo  Peter H.,

ich möchte Dir noch einen weiteren Weg zum Smarten Haus aufzeigen,
eine Realisierung über IOBroker.
Auf, z.B. einem kleinen Raspberry Pi 3, lässt sich der IOBroker einfach 
auf dem OS Debian 9 installieren und betreiben.

Deine Aktoren und Sensoren, lassen sich dann über unterschiedliche 
Protokolle und Netze mit der Basiseinheit IOBroker verbinden.

Man kann so nicht nur eine Heizung steuern, sondern auch Licht, 
Rollladen, die Türklingel u.v.a einbinden.

Mit der Visualisierung VIS ist eine Nutzung auf unterschiedlichen 
Endgeräten möglich.

_Link_:
1) http://www.iobroker.net/
2) https://forum.iobroker.net/
3) [ioBroker] Installation & Einrichtung [Tutorial] [HD] 
https://www.youtube.com/watch?v=cThlN8In9mk

[Opensource _. (opensource)]

John Doe schrieb:
> Fragmentierung findet auf Layer 3 statt,...
nur wenn ein Layer 8 an eine bedingunglose Fragmentierung glauben möchte 
und

> ...daher können UDP-Pakete sehr wohl fragmentiert werden,
> ohne dass man etwas dagegen machen kann.
John Doe kann u.U. nichts dagegen machen, aber eigene Menschen können 
Wikipedia lesen:
 [Bedingung für IP-Fragmentierung]:"*falls* die Gesamtlänge des 
Datenpakets größer als die Maximum Transmission Unit der 
Netzwerkschnittstelle ist."
und durch kontrollierte Wahl der Netzwerkschnittstellen bspw. nur 
Ethernet(1500),W-lan(2312), Power-lan(1500) und Dsl (i.a. 1500-8 
wg.PPPoE) mit MTU=1492 (um externe Fragmentierung durch bspw. NAT zu 
verhindern auch etwas niedriger) die Anzahl der Fragmentierungen auf 0 
reduzieren.

Falls dein internes Netz über ISDN/X.25 Schnittstellen realisiert ist 
(X.25 ist die Hauptursache für Fragmentierungen im Internet, ist dort 
allerdings wie Fragmentierungen selbst kaum verbreitet) dann hilft eine 
MTU=(576-Protokoll_size) Einstellung.

> (Auch das DF-Bit muss ein Router laut Standard nicht zwingend beachten).
RFC 1191:"When a router is unable to forward a datagram because it 
exceeds the MTU of the next-hop network and its Don't fragment bit is 
set, the router is required to return an ICMP Destination Unreachable 
message to the source of the datagram,..."

> Bei 100 Byte-Paketen passiert das aber sicherlich nicht.
zumindest dürfte die sichere Einstellung den schlechten Empfang von 
Wikipedia und RCF erklärten. Wenn nur so kurze Fragmente empfangen 
werden können, dass 0 zusammenhängende Informationen bei John Doe 
angekommen sind, dann findet dort wohl weiterhin die berichte 
Fragmentierung statt.

NB.: geschichtlich u.U. ganz interessant: zu einem weltweiten Einsatz 
von OSI-Netzwerkprotokollen nach ISO-OSI-Standard (Layer 1..7) wird es 
wohl allenfalls Jahrzehnte nach der Fertigstellung von Hurd kommen, 
allerdings war die Hoffnung auf OSI-Protokolle in den 1990er gerade in D 
der Grund Internet bzw. IP-Protokolle abzulehnen.
Teilweise lassen sich IP Protokolle mit den OSI-Layern veranschaulichen, 
aber teilweise sind diese nicht so 'sauber' wie ein Microkernel bzw. 7 
Layer Modell getrennt.

Eine einfach stattfindende Fragmentierung auf einem Layer oder 
IP-Protokoll wie in der Welt von sicher 100 byte Fragmentierten wäre 
weder nach IP noch einem OSI-Protokoll zulässig.

[Strubi (Gast)]

Moin,


Peter H. schrieb:
>
> Ich habe den Beispiel Sketch "Web Server" aus der "Ethercard.h" Library
> ein wenig angepasst, sodass ich die LED bzw. das Relais auch schon ein
> und ausschalten kann.
>
> Nun möchte ich aber dass ein zweiter ATMEGA, der genau so mit dem
> Netzwerk verbunden ist, dem anderen ATMEGA sagt dass er jetzt das Relais
> ein bzw. ausschalten soll.
>

Ich könnte Dir dafür jetzt ne fertige Opensource-Lösung aufschwatzen, 
aber was Stefanus sagt, hat für ein einzelnes Relais im Sinne von "Keep 
it simple" die meiste Wahrheit: Denk dir ein einfaches UDP/TCP 
Paket-Protokoll aus, was einen vernünftigen "Ack, hab ich gemacht" 
zurückgibt.

Alle anderen Optionen wie Webserver, Iobroker und was auch immer aus der 
SCADA-Welt ist dafür viel zu schwergewichtig.

[John Doe (Gast)]

Opensource _. schrieb:
> John Doe schrieb:
>> Fragmentierung findet auf Layer 3 statt,...
> nur wenn ein Layer 8 an eine bedingunglose Fragmentierung glauben möchte
> und
>> ...daher können UDP-Pakete sehr wohl fragmentiert werden,
>> ohne dass man etwas dagegen machen kann.
> John Doe kann u.U. nichts dagegen machen, aber eigene Menschen können
> Wikipedia lesen:


Opensource kann sicherlich nichts gegen Legasthenie oder andere Ursachen 
Deines dramatischen Leseverständnisses machen, aber andere Menschen 
haben zumindest erfolgreich die Grundschule absolviert.


>  [Bedingung für IP-Fragmentierung]:"*falls* die Gesamtlänge des
> Datenpakets größer als die Maximum Transmission Unit der
> Netzwerkschnittstelle ist."


Falsch! Nicht mal für das Wikipedia-Lesen und -Zitieren reicht es bei 
Dir. Hier das Vollständige Zitat:
"Die IP-Fragmentierung bezeichnet die Aufteilung eines IP-Datenpakets 
auf mehrere physikalische Datenblöcke, falls die Gesamtlänge des 
Datenpakets größer als die Maximum Transmission Unit der 
Netzwerkschnittstelle ist. "
Fragmentierung kann auch erfolgen, wenn die MTU der 
Netzwerkschnittstelle größer ist. Versteht aber nur jemand, der die RFCs 
lesen kann.


>> (Auch das DF-Bit muss ein Router laut Standard nicht zwingend beachten).
> RFC 1191:"When a router is unable to forward a datagram because it
> exceeds the MTU of the next-hop network and its Don't fragment bit is
> set, the router is required to return an ICMP Destination Unreachable
> message to the source of the datagram,..."


Ja, und wo widerspricht sich das? Lern bitte erstmal Lesen und die 
deutsche Sprache. Das kannst Du offensichtlich nicht. Was ich 
geschrieben hab, ist dass ein Router fragmentieren darf, auch wenn die 
MTU des nächsten Netzwerks gross genug ist.


>> Bei 100 Byte-Paketen passiert das aber sicherlich nicht.
> zumindest dürfte die sichere Einstellung den schlechten Empfang von
> Wikipedia und RCF erklärten. Wenn nur so kurze Fragmente empfangen
> werden können, dass 0 zusammenhängende Informationen bei John Doe
> angekommen sind, dann findet dort wohl weiterhin die berichte
> Fragmentierung statt.


Bei Dir sind offensichtlich schon in der Grundschulzeit nur Fragmente 
des Lernstoffs angekommen, sonst würdest Du ausreichend Lesekenntnisse 
haben.

[Marc H. (marchorby)]

Hallo Peter,

sorry, aber wenn du schon Arduino benutzt, warum machst du es nicht 
gleich auf einem ESP32? Der ENC28J60 braucht sehr viel Strom. Zudem hat 
der ESP genügend Speicher für eine Website und 
UDP-Befehlsinterpretierung.

[STK500-Besitzer (Gast)]

Peter H. schrieb:
> Bekommt der UDP "Sender" auch eine eigene IP bzw. kann man den dann auch
> als WebServer verwenden?

Jeder Teilnehmer im Netz braucht eine eigene IP-Adresse.
Wie sieht dein Netzwerk mit den ATmegas bis jetzt aus?
Hängt da noch ein Router dran?
Kannst du da reingucken, welche IP-Adressen vergeben sind?

Stefanus F. schrieb:
> Du machst hier genau den Fehler, auf den ich oben hinwies. Du gehst
> einfach davon aus, den kompletten GET Request an einem Stück (Paket) zu
> empfangen.

und das auf Die Frage mit der IP-Adresse. ROFL

[Stefan F. (Gast)]

Marc H. schrieb:
> warum machst du es nicht gleich auf einem ESP32?

Vielleicht weil Power over WLAN noch nicht erfunden wurde.

[H.Joachim S. (crazyhorse)]

Stefanus F. schrieb:
> Vielleicht weil Power over WLAN noch nicht erfunden wurde.

Du bist etwas hinterher, funktioniert prima :-)
https://www.wimo.com/power-over-wlan_d.html

[Marc H. (marchorby)]

Stefanus F. schrieb:
> Marc H. schrieb:
>> warum machst du es nicht gleich auf einem ESP32?
>
> Vielleicht weil Power over WLAN noch nicht erfunden wurde.

Er kann ja das Kabel zur Stromversorgung hernehmen. Zudem kann man am 
ESP noch ein Phy anschließen

[Peter H. (borntopizza)]

Also ich hab jetzt noch ein wenig weiter probiert, und bin jetzt wieder 
mal an einem punkt an dem ich nicht weiter komme :-)

Am Seriellen Monitor wird mir jetzt das ausgegeben was ich sehen will.

"<<< REQ >>>
HTTP/1.0 503 Service Unavailable
Content-Type: text/html
Retry-After: 600

<html><head><title>Sers</title></head><body>Status: 1 <br />The syntax: 
http://192.168.0.XX/?LED10=OFF...";


Jetzt weiß ich leider nicht wie ich das in einen String bekomme und dann 
die 1 bzw. 0 hinter Status als Variable "isolieren" kann. Vielleicht 
könnt ihr mir ja helfen. Ich weiß nicht welcher Befehl den Website Text 
postet.

// Demo using DHCP and DNS to perform a web client request.
// 2011-06-08 <[e-mail]>
//
// License: GPLv2

#include <EtherCard.h>

// ethernet interface mac address, must be unique on the LAN
static byte mymac[] = { 0x78,0x69,0x69,0x2D,0x30,0x37 };

byte Ethernet::buffer[700];
static uint32_t timer;

const char website[] PROGMEM = "192.168.10.199";

// called when the client request is complete
static void my_callback (byte status, word off, word len) {
  Serial.println(">>>");
  Ethernet::buffer[off+300] = 0;
  Serial.print((const char*) Ethernet::buffer + off);
  Serial.println("...");
}

void setup () {
  Serial.begin(57600);
  Serial.println(F("\n[webClient]"));

  // Change 'SS' to your Slave Select pin, if you arn't using the default pin
  if (ether.begin(sizeof Ethernet::buffer, mymac, 8) == 0)
    Serial.println(F("Failed to access Ethernet controller"));
  if (!ether.dhcpSetup())
    Serial.println(F("DHCP failed"));

  ether.printIp("IP:  ", ether.myip);
  ether.printIp("GW:  ", ether.gwip);
  ether.printIp("DNS: ", ether.dnsip);

#if 1

  // if website is a string containing an IP address instead of a domain name,
  // then use it directly. Note: the string can not be in PROGMEM.
  char websiteIP[] = "http://192.168.10.199/";
  ether.parseIp(ether.hisip, websiteIP);
#else
  // or provide a numeric IP address instead of a string
  byte hisip[] = {http://192.168.10.199/};
  ether.copyIp(ether.hisip, hisip);
#endif

  ether.printIp("SRV: ", ether.hisip);
}

void loop () {
  ether.packetLoop(ether.packetReceive());

  if (millis() > timer) {
    timer = millis() + 5000;
    Serial.println();
    Serial.print("<<< REQ ");
    ether.browseUrl(PSTR("/foo/"), "bar", website, my_callback);
    Serial.println();
    Serial.print(ether.browseUrl(PSTR("/foo/"), "bar", website, my_callback));
  }
}

Das mit IOBroker schau ich mir aufjedenfall nochmal an ! Ich habe auch 
anfangs ein wenig an Node Red gedacht, mal sehen .

Danke und viele Grüße

Peter

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Peter H. schrieb:
> ich bin gerade dabei eine Steuerung für meine Fussbodenheizung zu bauen.
Wenn ich mir diese Platine so anschaue, dann möchte ich dir damit Glück 
wünschen...   ;-)

Denn das brauchst du angesichts der Tatsache, dass da weit und breit 
kein wirksam angeschlossener Blockkondensator am µC ist. Die 
Keramikkondensatoren, die irgendwo auf der Leiterplatte sitzen und 
kreuz&quer verbunden sind, helfen dem µC da nicht.

Auch das Layout um den Oszillator hat nichts mit dem Vorschlag aus dem 
Datenblatt zu tun.

Auf diese Art kann man kuriose und schwer zu findende Fehler zu Gesicht 
bekommen.

[Peter H. (borntopizza)]

Die Platine ist jetzt wirklich nichts besonderes, aber an ihr liegts 
definitv nicht. Sieht man denn die Kondensatoren oben links nicht ? :D

[Opensource _. (opensource)]

John Doe schrieb:
> Opensource _. schrieb:
>> John Doe schrieb:
>>> Fragmentierung findet auf Layer 3 statt,...
>> nur wenn ein Layer 8 an eine bedingunglose Fragmentierung glauben möchte
>> und
>>> ...daher können UDP-Pakete sehr wohl fragmentiert werden,
>>> ohne dass man etwas dagegen machen kann.
>> John Doe kann u.U. nichts dagegen machen, aber eigene Menschen können
>> Wikipedia lesen:
>
>
> Opensource kann sicherlich nichts gegen Legasthenie oder andere Ursachen ...
wenn John Doe 0 Worte aus einem kopierten Text nennen kann (100% 
Legasthenie), dann bleibt "Opensourse" sicherlich das Einzige was in das 
sichere 100 byte passt.

> Falsch! Nicht mal für das Wikipedia-Lesen und -Zitieren reicht es bei
> Dir. Hier das Vollständige Zitat:
> "[Die IP-Fragmentierung BEZEICHNET die Aufteilung eines IP-Datenpakets
> auf mehrere physikalische Datenblöcke], falls die Gesamtlänge des
> Datenpakets größer als die Maximum Transmission Unit der
> Netzwerkschnittstelle ist. "
wenn John Doe eigenständig lesen könnte und den 'vollständigen' Halbsatz 
inkl. des Wortes "beZEICHNET" verstehen könnte, dann könnte John Doe 
verstehen, dass der bezeichnungs Habsatz für die vollstndige sachliche 
Beschreinug 0 Inhalt hat.

Wenn Joh Doe 0 Worte aus dem mühsam kopierten 'vollständigen' Zitat 
nennen kann und automatisch
> Fragmentierung kann auch erfolgen, wenn die MTU der
> Netzwerkschnittstelle größer ist.
unter der Kopie ausgibt, dann bleibt Jphn Does Layer 8-3 sicher in der 
Fragmentierung.

> Was ich geschrieben hab, ist dass ein Router fragmentieren
> darf, auch wenn die MTU des nächsten Netzwerks gross genug ist.
wenn du lediglich von "opensource" berichten kannst, dann ist das Wort 
"required" (dt.: erforderlich) aus RFC 1911 sicherlich etwas zu 
anspruchsvoll für 100 byte.

> Ja, und wo widerspricht sich das?
- "das" aus 100 byte Fragmention: "das DF-Bit muss ein Router laut 
Standard nicht zwingend beachten"
- "das" aus RFC:"the router is required to return an ICMP Destination 
Unreachable message
wenn du keine englischen Worte lesen kannst und du hilflos nach "das" 
als Ersatz fragen musst, dann benötigst du sicherlich Hilfe um dein 
erstes Wort aus Texten nennen zu können.

Falls du einmal schreiben kannst was du nicht verstanden hast, dann 
benötigst du evtl. zukünftig keine so starke Fragmentierung.

Hilfegesuche wie:
> Lern bitte erstmal Lesen und die deutsche Sprache.
wenn John Doe 0 englische Worte aus einer RFC in seiner Reaktion 
nennen kann, dann helfen auch solche Bittgesuche nichts.

John Dope versteht sicherlich nicht, dass er Worte aus einer RFC 
selber nennen müsste und sein Hilfegesuch ein Fremder möge für John 
lesen ihn in dauerhafte Abhängigkeit bringt.

> Bei Dir sind offen sichtlich schon in der Grundschulzeit nur Fragmente
> des Lernstoffs angekommen, sonst würdest Du ausreichend Lesekenntnisse
> haben.
sicherlich sind solche visuellen Erlebnisse, wenn exakt 0 Worte aus 
kopierten Text beantwortet werden konnten, in sicheren 100 byte 
Fragmenten empfangen worden.

Wenn du zukünftig einmal ohne Hilfe von "opensource" auf einen Text 
antworten möchtest, dann müsstest du schon lesen lernen und einzelne 
Wörter aus einem Text nennen nennen können. Solange du nur 
"Opensource" aus der Überschrift schreiben kannst bleibt dir natürlich 
eine eigene Antwort verwehrt.

In deinem Netz dürfte eine einfach stattfindende Fragmentierung auf 
Layer 3 (OSI) als Alternative zu IP-Protokollen sicherlich die beste 
Lösung sein.

Fall John Doe einmal das erste Wort aus Wikipedia oder anderen 
opensource Texten im Zusammenhang in seiner Reaktion verwenden kann dann 
musst er nicht "opensource" um Hilfe bemühen und schafft zukünftig 
vielleicht sogar sein Netz mit x.25 (MTU ca.500 byte) zu betreiben

[Stefan F. (Gast)]

Nicht schon wieder!
Das ist doch der Schwurbel-Kasper, den man nur unter Drogeneinfluss 
verstehen kann.

Kannst du auch mal etwas interessantes (eventuell gar fachliches) von 
Dir geben, als immer nur andere niedermachen? Oder ist das schon zu viel 
verlangt.

[Opensource _. (opensource)]

Stefanus F. schrieb:
> Nicht schon wieder!
> Das ist doch der Schwurbel-Kasper, den man nur unter Drogeneinfluss
> verstehen kann.
deine spezielle Erfahrung du könntest den Schwurbel-Kasper nur unter 
Drogeneinfluss verstehen, während du nüchtern so unter Einfluss stehst, 
dass du kein Wort aus fremden Texten beantworten kannst, sind 
sicherlich eine sehr fachliche Ausgabe.

Wenn maximal Schwurbler 0 Worte aus der Umwelt nennen können dann ergeht 
es denen wie den Schwurblern aus dem Internet die bereits eine 
Bohrmaschine(!) erlebt haben die "furchtbar klappert und wackelt" 
(einfach so im Internet zu finden) und sich nur an den Ort des Kaufes 
erinnern konnten, aber nicht das der Ort bereits beim vormaligen Kauf 
kein Probiermarkt war.


> Kannst du auch mal etwas interessantes (eventuell gar fachliches) von
> Dir geben,
sobald du die Möglichkeit hast in ganzen Sätzen eine konkrete Frage zu 
stellen oder eine *konkrete Aussage bspw. WAS (Text) dich so aufgeregt 
hat, kannst du auch fachliches lesen.

> als immer nur andere niedermachen?
wenn du Zugang zu realen Sätzen bekommen solltest, dann könntest du 
nachlesen, dass der Beitrag einfach den FAKE der irgendwie 
stattfindenen Fragmentierung beantwortet hat.


Wenn du nur schwurbeln kannst und keinen originalen Text ohne Hilfe 
beantworten kannst, dann bleiben deine Horrorgeschichtchen einfach 
unreparierbar.
Vielleicht ist eine bei dir stattfindene Fragmentierung auch die Ursache 
0 Worte fachlich nennen zu  können.

Kannst du eine fachliche Aussage wann eine Fragmentierung im realen 
Router stattfindet bzw. stattfinden würde/sollte nennen ?

[Stefan F. (Gast)]

Du hast vergessen, zu erwähnen, dass auch zu dumm zum korrekten zitieren 
bin.

[Opensource _. (opensource)]

Stefanus F. schrieb:
> Du hast vergessen, zu erwähnen, dass auch zu dumm zum korrekten zitieren
> bin.
Nein. Wenn du den fachliche Hintergrund, dass zum zitieren mehr als ein 
(1) Wort aus dem zu zitierenden Text benötigt wird, verstehst, könntest 
du das auch verstehen.


Wenn der Zwang zum schwurbeln ohne eine konkrete Aussage so groß ist, 
dass du immer  weiter schwurbeln musst, dann ist die Frage:
"Kannst du eine fachliche Aussage wann eine Fragmentierung im realen
Router stattfindet bzw. stattfinden würde/sollte nennen ?"
sicherlich etwas zu fremdfachlich.

[Stefan F. (Gast)]

Wenn wir damit KI Systeme trainieren, brabbeln sie nur noch dummes Zeug 
wie Babies.

[Opensource _. (opensource)]

Stefanus F. schrieb:
> Wenn wir [die Schwurbler die 0 externe Worte nennen
> können und von uns berichten müssen] damit [mit dem was wir
> produzieren] KI Systeme trainieren, brabbeln sie nur noch dummes Zeug wie 
Babies.
wenn die KI auch so derartig unter Produktionszwang gesetzt wird, dass 
sie immer aus sich herausgeben muss, dann endet so eine KI sicherlich 
wie die Schwurbler die nicht anhalten können weil sie kein Wort 
verstehen können.

Wenn die Stefanus Gemeinschaft eine Frage:
"Kannst du eine fachliche Aussage wann eine Fragmentierung im realen
Router stattfindet bzw. stattfinden würde/sollte nennen ?"
beantworten könnte, dann müsste die keine "Babies" für ihre fachliche 
Ausgabe verwenden, sondern könnte einen von ihnen selbst antworten 
lassen.

[Taiwanese (Gast)]

Die Wahl der Hardware betrachte ich als schlecht.
Das tut man sich doch nicht ( mehr) an.

Schon gesagt, ich wiederhole aber:

ESP32, MQTT und das Ekosystem ist überragend.

Das Kabel kannst Du zur Versorgung nehemen und gleichzeitig auch für die 
Datenübertragung RS 4xx.

Der Wlan nutzen, out of The Box.
MicroPython, Arduino, espeasy......

Tu Dir den Gefallen!

[Mitlesa (Gast)]

Lothar M. schrieb:
> Denn das brauchst du angesichts der Tatsache, dass da weit und breit
> kein wirksam angeschlossener Blockkondensator am µC ist. Die
> Keramikkondensatoren, die irgendwo auf der Leiterplatte sitzen und
> kreuz&quer verbunden sind, helfen dem µC da nicht.

Lautstarke Zustimmung von mir.

Und es wundert mich doch sehr dass niemand schon früher das
Hardware-Thema angesprochen hat.

Peter H. schrieb:
> Sieht man denn die Kondensatoren oben links nicht ?

Wenn man die Kondensatoren einfach nur auf die Platine klebt dann
sieht man sie auch. Dann haben sie den gleichen Effekt.

Peter H. schrieb:
> ... aber an ihr liegts definitv nicht.

Erinnert mich an den Satz den Windows-Programmierer manchmal
von sich geben wenn sie sich zur Fehlerfreiheit/Problemen ihrer
Programmschöpfung äussern: "Works on my machine".

Peter H. schrieb:
> ... aber an ihr liegts definitv nicht.

Da ist aber garantiert was im Argen, der (vermutete) Spanungsregler
hat auch nur zufällig einen Kondensator in seiner Nähe platziert,
zwei (richtig dimensionierte) braucht es dort auf jeden Fall.

Die Platine funktioniert nur zufällig (vielleicht) aber nicht
weil für alle Fälle vorgesorgt wurde.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Ich frag mich grade eher wie man es schafft sone Riesenplatine zu 
entwerfen und dabei die Bauteildichte gegen Null gehen zu lassen.
Zudem besteht die Platine gefühlt zur Hälfte aus Drahtbrücken.
Also da hätt man auch gleich auf Lochraster fädeln können!
Dann ist da nichtmal enn Verpoishcerer Standard ISP drauf, sondern sowas 
eigenes als 1x Reihe.

Sowas geht auch in 1 lagig:
https://www.ulrichradig.de/home/index.php/dmx/alias-2

Muss ja kein Artnet rauf, sondern dein Code.

[H.Joachim S. (crazyhorse)]

Und der Strombedarf des ENC....
Wenn man da ein paar 24/7 laufen lässt, kommt da am Jahresande einiges 
an Minusgeld raus.

[Stefan F. (Gast)]

Wenn der TO unbedingt die Kombination AVR+Ethernet-Controller will, 
würde ich zu einem CrumbX1-Net Modul 
(https://www.chip45.com/download/CrumbX1-NET_V1.2_infosheet.pdf) raten. 
Dazu passend bietet der Hersteller ein POE Add-On Board an. Das Ganze 
hat dann ungefähr das Format einer Streichholzschachtel und funktioniert 
garantiert zuverlässig.

Die aktuelle beispiel-Firmware dazu kommt "zufällig" von mir: 
http://stefanfrings.de/net_io/index.html

Und ganz "zufällig" empfängt sie Kommandos zum Schalten der I/O Pins via 
TCP Socket und HTTP, ganz so wie der TO es haben möchte. Ich bin sicher, 
dass er meinen Code in Windeseile an seine Bedürfnisse anpassen kann, 
falls er nicht schon (wie ich vermute) genau zum Anwendungsfall passt.

Die Stromaufnahme ist in Bereitschaft 70mA und bei aktiver Übertragung 
120mA, also ähnlich dem ESP8266.

[Mitlesa (Gast)]

H.Joachim S. schrieb:
> Und der Strombedarf des ENC....

... hat auch was mit dem Layout zu tun. Da bekommt der ENC
seine Masse und Versorgung über möglicherweise sehr ver-
schlungene Masse- und Vcc-Pfade. Wer schon mal was von
Verkopplungen über Masseströme erlebt hat wird ein Lied
davon singen können. Aber ...

Peter H. schrieb:
> an ihr liegts definitv nicht.

[Marokscha (Gast)]

Peter H. schrieb:
> Also ich hab jetzt noch ein wenig weiter probiert, und bin jetzt wieder
> mal an einem punkt an dem ich nicht weiter komme :-)

Das war zu erwarten...

[Torsten (Gast)]

Habe zu einem ähnlichen Thema in den letzten Tagen ein paar Tests 
gemacht. Und zwar ging es bei mir darum, in der Hauptverteilung im 
Keller mittels einem Nano v3 (Atmega 328P) zwei Lampen zu schalten, die 
an der Außenfassade angebracht sind (kein Bewegungsmelder, ist mehr eine 
optische Sache). Da es dort kein WLAN gibt, habe ich (direkt in Fernost) 
ein Ethernet-Shield bestellt, welches einen W5500 besitzt (Wiznet). Da 
gibt es unterschiedliche Shields, ich rede von so nem ganz kleinen Teil, 
das man zB bei Ebay kriegt und lediglich zehn Pins hat und keine Taster. 
Was ich so im Netz gefunden habe, ist ein W5500 vom Strombedarf 
effizienter als ein W5100. Vom Strombedarf sieht das so aus (jeweils 
inkl. Arduino gemessen an 5V und mit einem einfachen Multimeter):

Nano v3 (alleine): 14,5 mA
Nano v3 + W5500 (@100 MBps): 128 mA
Nano v3 + W5500 (@10 MBps): 84 mA
Nano v3 + W5500 (Power down): 47 mA

Info: Um die Geschwindigkeit anzupassen bzw. den PowerDown zu erzwingen, 
muss man die Ethernet2-Lib etwas modifizieren und das Phy-Register 
passend parametrieren. Habe mir dazu eine kleine Methode implementiert, 
so dass ich das aus dem Sketch raus machen kann.

Im Vergleich dazu einen ESP-01: Den habe ich mit ca. 70 mA bei 3.3V 
gemessen, ein ESP-12E auf einem NodeMCU-Entwicklerboard war bis auf 2-3 
mA ungefähr gleich. Also muss man sich schon überlegen, ob man sich den 
Stress mit Ethernet wirklich antun will, so ein ESP-01 ist ziemlich 
kompakt und braucht unterm Strich halt auch weniger Strom. Ok, hat aber 
auch nur zwei GPIOs. Datenaustausch habe ich, wie es hier auch schon 
erwähnt wurde, mit MQTT gemacht. Kann ich nur empfehlen, da kann man 
sich den ganzen Overhead mit Webserver sparen.

Energieeffizienz:
Meine ursprüngliche Idee war, dass ich den Arduino schlafen lasse und 
per Wake-on-Lan aufwecke, dabei war mir allerdings vorher nicht klar, 
dass der wesentlich größere Verbrauch vom Ethernet-Shield ausgeht. Mein 
aktueller Plan ist jetzt, dass ich per MQTT fetche und dann das 
Ethernet-Shield schlafen lege. Nach ein paar Minuten wecke ich es wieder 
auf und dann wird erneut gefetcht und wieder geschlafen. Parallel 
definiere ich noch einen Schalter in openHAB, der sowas wie 
"Eth-Standby" heißt. Den Zustand dieses Schalters lese ich ebenfalls per 
MQTT aus oder steuere darüber, ob das Eth-Shield schlafen gelegt wird. 
So könnte ich also, wenn ich wollte, das Eth-Shield auch wach halten.
Da ich die zu schaltende Lampe aber eigentlich nicht in "Echtzeit" 
schalten können muss, passt das im Prinzip auch schon ohne diesen 
Schalter. Ob das im Alltag so funktioniert, muss ich dann noch testen. 
Ist bislang nur eine Idee.

[svensson (Gast)]

Mal ein anderer Gedankenansatz:

> Kat. 5 Kabel liegen dort. Zwei ATmegas koppeln.

Warum mißbrauchst Du die Kabel nicht einfach? 2-4 Adern für die 
Stromversorgung (evtl einfach einen PoE-Injector verwenden) und die 
restlichen 4 Adern zur direkten Koppelung der beiden ATmegas. Schon 
entfällt das ganze Geraffel mit dem Webclient.

Wir machen das sehr oft. Bei uns laufen z.B. analoge/digitale Sensoren, 
analoge Telefone oder Steuerungssignale über TwistedPair (Cat. 5/6/7), 
weil die Infrastruktur heute nahezu in jedem Raum vorhanden ist. Zudem 
ist das TP-Kabel heute oftmals billiger als traditionelles 
Fernmeldekabel.

[svensson (Gast)]

Ach so, ich vergaß: Wenn man so etwas macht, dann ist es extrem wichtig, 
die Ports an den Patchfelder ordentlich zu beschriften!