Der Ardunio und direkte Ausgaben vom ZusiServer über TCP

[trainboy12]

Ich habe schon alles mögliche probiert, der Screenshot ist halt bei dem versuch entstanden.

[Daniel Rüscher aka Merlin]

Welche IP Adresse hat denn der Arduino?
Gib deiner LAN Karte im PC mal eine fixe IP Adresse im Bereich des schield (zu erkennen an der Subnet Maske) dann dürfte es funktionieren

[trainboy12]

Aber wenn ich in den Netzwerkverbindungen die IP festlege, dann wird das ja auch dann die IP vom Shield

Edith: Kann der Arduino eine eigene IP kriegen? Oder falls du den Anschluss meinst ist das bei mir COM3.

[F. Schn.]

@Dude:
Noch ein paar Vorschläge:

• Prüfen, ob Ethernet.begin erfolgreich war.
• Ausgeben der IP-Adresse, die der Ethernet-Shield hat (insbesondere bei DHCP).
• Ausgeben, mit welchem Server und welchem Port man sich verbindet.

@trainboy 169.254.?.? (insbesondere mit der Subnetzmaske 255.255.0.0) ist eine recht ungewöhnliche IP. (Nicht, das es nicht denkbar wäre, aber...) Noch seltsamer ist, das das WLAN dir eine IP aus einem anderen Adressraum zuweist (192.168.?.?). Vielleicht solltest du erst einmal schauen, was mit deinem Heimneztwerk los ist. (Denkbar wäre beispielsweise ein virtuelles Privates Netzwerk.) Eventuell solltest du auch mal prüfen, welche IP dem Arduino über DHCP zugetielt wurde. (Befehl Serial.println(Ethernet.localIP()); hinter den delay(1000);-Befehl (Zeile 60) einfügen.) Abschalten von DHCP und manuelle IP im Arduino-Script hast du auch schon mal probiert? (#define dhcp 0)

Nachtrag: Du hast den PC direkt mit dem Arduino verbuden? Ok, da kann es sein, dass DHCP überhaupt nicht funktioniert. Denkbar ist auch, dass dir die alte Problematik bei direkten Verbindungen zum Tragen kommt (Früher mussten bei direkten Verbindungen spezielle Kabel mit vertauschten Adern eingesetzt werden. Heute kann das möglicherweise die Hadware ausgleichen, aber ich weiß nicht, wie intelligent der Arduino-Ehernet-Shield da handelt, bzw. ob die Hardware auf diesen Fall ausgelegt ist).

[Arne aus dem Norden]

@trainboy 169.254.?.? (insbesondere mit der Subnetzmaske 255.255.0.0) ist eine recht ungewöhnliche IP. (Nicht, das es nicht denkbar wäre, aber...) Noch seltsamer ist, das das WLAN dir eine IP aus einem anderen Adressraum zuweist (192.168.?.?). Vielleicht solltest du erst einmal schauen, was mit deinem Heimneztwerk los ist.

Ich hab das jetzt auch mal annähernd so probiert. Seinen genauen "Aufbau" kann ich mangels W-LAN nicht nachvollziehen.

Ich denke er hat einen W-LAN Router über DHCP mit seinem PC verbunden via eines USB-Adapters und dann gleichzeitig den PC parallel mit dem Arduino über ein uns vom Typ unbekanntes Kabel.

Fall 1: wenn ich meinen PC mit meinem Kabelrouter verbinde, bekomme ich -ganz klar- eine ähnliche Adresse wie er (192, 168, 178, 33) am PC zugeteilt. Wenn ich jetzt den Arduino ebenfalls an den Router hänge kann ich mich sofort mit #define dhcp 1 verbinden.
-> heißt: wenn am W-LAN Router zusätzliche RJ45-Buchsen für Kabelanschluß wären und er DORT den Arduino mit dhcp 1 anschließt, müßte es mit 192.168.178.35 als Zusi-Server bei ihm gehen.
Mit dhcp 0 geht es bei mir immer noch, wenn ich eine Adresse aus dem selben Adressraum verwende, in meinem Fall 192, 168, 178, 177

Fall 2: wenn ich mich DIREKT mit dem PC mit Kabel verbinde, bekomme ich auch eine ähnliche IP, (169, 254, 227, 228) unter ipconfig von meinem Win 7 angezeigt. Jeglicher Versuch sich mit DHCP 1 zu verbinden schlägt nun -genau wie bei Maurice- fehl.
Wenn ich DHCP 0 setze und die shield_ip auf 169, 254, 227, 229 setze kann ich mich aber sofort verbinden.
-> heißt: bei deaktivertem W-LAN und unter ipconfig angezeigter Adresse 169.254.240.56 müßte sich der Arduino unter dhcp 0 und shield_ip 169.254.240.57 sofort verbinden.

Ich würde jetzt also zuerst mal letzteren Weg GENAU SO probieren:

Code: Alles auswählen

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE,0xED};

byte server_ip[] = { 169, 254, 227, 56 };

int port = 1435;

byte shield_ip[] = { 169, 254, 227, 57 };

#define dhcp 0

Vorrausgesetzt natürlich, W-LAN deaktiviert und ipconfig zeigt immer noch die 169, 254, 227, 56 so an...
Und da würde ich jetzt gerne wissen was passiert...

[Andreas Karg]

Die 169er-IPs würfelt Windows sich selber aus, wenn der Netzwerkadapter auf "IP automatisch beziehen" gestellt ist und es kein funktionierendes DHCP gibt. Theoretisch sollte das automatisch für ein funktionierendes Netz unter Windows-Rechnern sorgen; das hat zumindest in meinem Dunstkreis aber noch nie geklappt

Gehe ich recht in der Annahme, dass irgendwo im Arduino-Programm eine IP fest eingestellt ist? In dem Falle würde ich dem Netzwerkadapter im Windows von Hand eine IP zuweisen, die bis auf die letzte Zifferngruppe identisch ist; und dazu eine Subnetzmaske von 255.255.255.0. Dann *müsste* es klappen.

[trainboy12]

Vielen Dank Arne. Funktioniert jetzt tadellos.
Ist das bei euch auch so, das blinkende LM - z.B. Wechselblinken, Geschwindigkeitsüberwachung etc. - unregelmäßig blinken?
Also ab und zu leuchtet er mal etwas länger auf, ein bisschen später nur ganz kurz usw. .
Damit kann man/ich natürlich leben, ist halt nur interessehalber.

Gruß
Maurice

[Arne aus dem Norden]

Na also, geht doch

Ist das bei euch auch so, das blinkende LM - z.B. Wechselblinken, Geschwindigkeitsüberwachung etc. - unregelmäßig blinken?
Also ab und zu leuchtet er mal etwas länger auf, ein bisschen später nur ganz kurz usw. .
Damit kann man/ich natürlich leben, ist halt nur interessehalber.

Ja, zumindest bei mir tut es das. Und bei mir war das auch schon so, wenn ich den anderen Weg gegangen bin über USB mit dem Script aus dem Thread "Ausgänge". Das Wechselblinken hat bei mir immer schon etwas "gehangen".

Ich meine sogar, das es bei ausführlicher serieller Protokollierung schon beim Datenempfang vom Server als Unregelmäßigkeit erkennbar war. In gewissen Abständen war ein Befehl mit Wert 0,00 mehr dazwischen.

[trainboy12]

Mit dem Skript von "Ausgänge" war es schon sehr gut gelungen, da war alles ok. Naja ist ja nicht schlimm.

[Arne aus dem Norden]

Mit dem Skript von "Ausgänge" war es schon sehr gut gelungen, da war alles ok.

Richig aufgefallen war mir das das damals DA auch erst, als ich alte PZB-Leuchtmelder über Relais und keine LED direkt angeschlossen hatte.
Es war plötzlich mehr zu hören als zu sehen.

Bei umfangreicheren Befehlsübermittelungen kann es übrigens durchaus bei diesem neuen Script zu perfomanceverlusten kommen durch das serielle Protokoll.
Wenn man also fertig ist mit konfigurieren und das Gefühl hat, das es etwas hängt: einfach mal die ganzen serial.prints und serial.beginn auskommentieren.
Bei neuerer Firmware scheint es sogar zu reichen, das Serial.beginn(9600); im void setup auszukommentieren. Wenn das Script dann nicht mehr läuft, halt einfach alle weiteren Serial.print* auch mal rausnehmen.
Bei der PZB alleine wirds aber nicht viel bringen, das macht sich erst bemerkbar wenn du Tacho und Manometerwerte laufend mitprotokollierst.

[Daniel Rüscher aka Merlin]

Noch mal kurz zum Thema IP...
Natürlich braucht der Shield eine zum PC unterschiedliche IP.
169.0.0.0 ist wie Andi schon sagte ein Windowseigenes Subnet was benutzt wird wenn weder IP noch DHCP Server vorhanden sind.

Daraus ergeben sich 2 Möglichkeiten:
Entweder DHCP, oder
Beiden beteiligten Kommunikationspartnern (PC & Shield) eine Feste IP zuweisen. Prinzipiell kann man jede hernehmen. Besser ist jedoch Adressen aus dem Pool192.168.0.x mit Subnet Maske 255.255.255.0 her zu nehmen.

[Stephan/Taschi]

Ähm, ich habe zwar nicht so wirklich viel Ahnung von dem Thema - aber sollte es nicht auch möglich sein, eine Verbindung über Hostnames aufzubauen? Die lassen sich schließlich prima festsetzen und man kann für die IPs einfach DHCP weiternutzen, ohne groß mit statischen IPs et cetera rumwurschteln zu müssen.

[Andreas Karg]

Wenn der Arduino DHCP (und Namensauflösung) unterstützt, müsste das klappen. Man muss ihn halt dann noch in das selbe Netz kriegen wie Zusi-Rechner und DHCP-Server. Und genau da hakelte es wohl zumindest beim OP.

[Arne aus dem Norden]

Man muss ihn halt dann noch in das selbe Netz kriegen wie Zusi-Rechner und DHCP-Server. Und genau da hakelte es wohl zumindest beim OP.

Ich muß dazu kurz anmerken, das Maurice sich zuerst an mich mit dem Problem per PN gewand hatte. Ich hatte in meiner ersten Antwort ihm bereits geschrieben, das eine unterschiedliche IP nötig ist und gebeten die Sache mit dhcp 0 und 1 jeweils zu testen. Weil es trotzdem Probleme gab, vermutete ich selber das Problem noch irgendwo anders beim W-LAN etc. und habe selber geraten, die Sache hier nochmal öffentlich zu besprechen. Als Apple-User ist Windows einfach nicht mein Fachgebiet ;-)

Nun hat sich ja nach meinem -extra deswegen- minutiösen Beitrag meiner Verbindungseinstellungen gezeigt, das es eben doch nur genau an den zuerst vermuteten Gründen lag.

Ich denke deswegen nicht, das es einen grundsätzlichen Bedarf an Änderungen im Script gibt, obwohl ich gerne in der nächsten Version noch einmal eine ausführlichere Verbindungsaufbauprotokollierung mit verwendeten IPs einbringen könnte wie von F.Schneider vorgeschlagen.
Ich hatte im ersten Post dieses Threads ja bereits geschrieben: mein Ziel ist es, als Nicht-Programmierer den Zugang zu den Server-Daten für andere Nicht-Programmierer zu vereinfachen, aber es kann u.U. halt eine kleine Auseindersetzung mit den eigenen Windows-Netzwerkeinstellungen erfordern.
Immerhin ist die Konfiguration bei Benutzung eines gewöhlichen Kabel-Routers mit nur einer IP des Zusi-Server zu schaffen, und die findet sich mit ipconfig unter Windows recht leicht...

Ich bin selber auch erst letzte Woche von XP auf Win7 gewechselt und hab das Shield in wenigen Minuten wieder ans laufen bekommen. Dagegen habe ich selber z.B. den halben Abend benötigt, um Zusi 2 wieder zu installieren, weil ich die ganze Geschichte mit den Rechten gerade im Programme Ordner von Win7 erstmal auf den Schirm kriegen mußte...

[Daniel Rüscher aka Merlin]

IP und DHCP sind keine direkten Windowsprobleme.
Hostnamenauflösung klappt nur mit DHCP.
Nur was du mit dem vorletzten Absatz sagen willst kapier ich nich so ganz.

[Max Senft]

Hi!

... Hostnamenauflösung klappt nur mit DHCP. ...

Du meinst wohl DNS (Domain Name Service). Namensauflösung geht auch in einem Netz ohne DHCP (also nur mit statischen Adressen).

Gruß
Max

[Total]

Eine Sache geht mir massiv auf die Nerven: Ich bin normalerweise über W-Lan online, sobald ich aber den Arduino angesteckt habe hab ich kein Internet mehr auf dem Rechner, offenbar versucht der krampfhaft über den Arduino ins Netz zu gehen. Hat jemand ne Lösung für mich?

Da musst Du dich wohl mit dem "route"-Kommando auseinandersetzen. Voraussetzung wäre dann wohl grundlegendes Verständnis für, ähm ja, Routing.

Die Default-Route wird von Windows anscheinend immer über Kabel gesetzt. Das müsstest Du auf das WLAN-Device ändern, nachdem Du den Arduino angesteckt hast.

Gruß

Christian

Ok...Wo und Wie?

[Christian Sch.]

Man nehme eine Eingabeaufforderung und führe sie als Administrator aus.

Code: Alles auswählen

route print -4

zeigt bei mir folgendes:

Code: Alles auswählen

===========================================================================
Schnittstellenliste
 24...00 21 86 6e 53 f6 ......Bluetooth-Gerät (PAN) #2
 22...00 21 5c 0b 3d af ......Intel(R) Wireless WiFi Link 4965AGN
 21...00 21 5c 0b 3d af ......Intel(R) 82566MM Gigabit Network Connection
  1...........................Software Loopback Interface 1
 14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 29...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #2
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.2.1    192.168.2.105     26
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      192.168.2.0    255.255.255.0   Auf Verbindung     192.168.2.105    281
    192.168.2.105  255.255.255.255   Auf Verbindung     192.168.2.105    281
    192.168.2.255  255.255.255.255   Auf Verbindung     192.168.2.105    281
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.2.105    281
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.2.105    281
===========================================================================
Ständige Routen:
  Keine

Wir haben: Das WLAN als Interface 22, LAN als Interface 21. Die Defaultroute ist die mit dem Netzwerkziel 0.0.0.0.

Code: Alles auswählen

route delete 0.0.0.0

löscht die Default-Route.

Code: Alles auswählen

route add 0.0.0.0 mask 0.0.0.0 if 21

ändert die Default-Route auf LAN.

Wie sieht es denn mit den Adressen der beteiligten Geräte aus ( Router, PC, Arduino, Sonstige ) ?

Gruß

Christian

[Marvin]

Hast du schon Neuigkeiten wegen dem unregelmäßigen Blinken?

Bei mir ist das bei der PZB ziemlich stark. Ist mir aber auch schon bei anderen Plugins aufgefallen

[Arne aus dem Norden]

Hast du schon Neuigkeiten wegen dem unregelmäßigen Blinken? Bei mir ist das bei der PZB ziemlich stark. Ist mir aber auch schon bei anderen Plugins aufgefallen

Hi,

nein. Ich wüßte das auch gerne, woran es genau liegt.
Wie ich schon oben schrieb, ich meine das der Server gelegentlich einen Befehl mehr sendet.
Ich würde ev. mal die serielle Protokollierung im Arduino komplett auskommentieren. Das wird das Problem zwar nicht beheben, aber möglicherweise fällt es dann weniger oder kaum noch auf.

Ansonsten hab ich auch schonmal darüber nachgedacht, das es ja noch die ID 0x6a "PZB restriktiver Modus" gibt. Ev. geht das, wenn der Wert =1 ist, die Ausgabe der blauen LM unterdrücken und ein sauberes Wechselblinken mit nem Timer des Arduino selbst erzeugen, keine Ahnung ob das hinhaut...

Gruß, Arne