Probleme: Keepalive - Sonnenuhr - Temperatursensor - Time-Zone und Winterzeit

[Rafale]

Hallochen,
ich habe in den vergangenen Tagen erste Tests mit dem NET-PwrCtrl HUT gemacht (gerade erst gekauft).
Grundlegend ist zu sagen, dass der angebotene Funktionsumfang des Gerätes meinen Erwartungen entspricht und ich damit zufrieden bin. Jedoch habe ich bei meinen bisherigen Versuchen auch verschiedene Dinge festgestellt, an deren Klärung ich interessiert bin:

1. Keepalive: Ein Netzwerkgerät kann in meinem Netzwerk via Handy und Computer mit WOL eingeschaltet werden. Das gleiche Gerät kann unter den gleichen Bedingungen jedoch nicht mit dem WOL des NET-PwrCtrl HUT gestartet werden. Eintrag im Logbuch:
So. 05.06.16, 09:26:33 Nr.8 WOL gesendet

2. Sonnenuhr: Der Timer ist so konfiguriert, dass er ein abgeschaltetes Relais einschaltet. Wird nun der Timer in einer Zeit konfiguriert, in der das Relais eingeschaltet sein soll, wird dieses nicht aktiviert und muss manuell eingeschaltet werden, um abzuschalten, wenn der Timer abgelaufen ist -anschließend funktioniert alles wie konfiguriert.
Umgekehrt - Wird nun der Timer in einer Zeit konfiguriert, in der das Relais ausgeschaltet sein soll, wird dieses nie aktiviert, auch nicht, wenn die Wiedereinschaltzeit erreicht wurde.
Kann für die Timer-Steuerung (Timer & Sonnenuhr) der Relais nicht die aktuelle Systemzeit der Sonnenuhr verwendet werden? Dann würde das Relais entsprechend der tatsächlichen Systemzeit gesteuert – auch nach dem Restart des Gerätes (z.B. nach Stromausfall).

3. Temperatursensor: Der Temperatursensor wurde im Gerät verbaut und übernimmt dessen Betriebstemperatur. Diese liegt (bei meinem Gerät) bei >25°C. Die Umgebungstemperatur des Gerätes liegt jedoch weit darunter, der Sensor kann also nur genutzt werden, wenn die gewünschte Schalttemperatur oberhalb der Arbeitstemperatur des Gerätes liegt. Kann der Temperatursensor auch extern angeschlossen werden, um die Beeinflussung vom Gerät auszuschließen?

4. Time-Zone und Winterzeit: Die Logik der Einstellungen erschließen sich mir nicht ganz.
UTC + 1 = MEZ. UTC + 2 = ME(S)Z. Warum muss die MEZ mit einem UTC +2 eingestellt werden, um die Uhr anschließende mit Häkchen der Winterzeit anzupassen? Sollte das (logisch) nicht umgekehrt sein? Aktuell wurden im Menü „Sonnenauf- und untergang“ +48,80°/+8,20° für Baden-Baden eingestellt (Angaben aus GoogleMaps), habe ich da vielleicht nur ein falsches Format verwendet?
Auch entspricht offenbar die angezeigte Uhrzeit im grauen Menübereich (Datum/Uhrzeit) oder im Menü „Zeiteinstellungen“ nicht der tatsächlichen Systemzeit mit der das Gerät arbeitet.
Z.B. wird durch das Setzen des Häkchens „es ist Winterzeit“ die Systemzeit nicht um -1 Stunde korrigiert (auch nicht nach der Synchronisation mit dem Zeitserver oder Reset).
Die Veränderung der Zeitzone im Menü „Sonnenauf- und untergang“ hat offenbar auf die Zeitstempel der Timer, nicht aber auf die angezeigte Systemzeit des Gerätes -> Timerzeit <> angezeigter Systemzeit. Dies führt dazu, dass man ggf. Timer konfiguriert, die scheinbar nicht funktionieren, weil die Zeitdifferenz (Timer-Zeit <> angezeigter Systemzeit) nicht erkennbar ist (ist mir leider so passiert).

Vielen Dank für sachdienliche Hinweise, denn ich kann natürlich nicht ausschließen, dass ich etwas falsch konfiguriert habe.
Rafale

[andy]

Hallo,

Danke für die ausführliche Beschreibung.

Bitte bedenken, dass wir nicht die Denkweise jeden Kunden implementieren können. Wir hätten es gerne! An der Denkweise ist nichts falsches aber andere Kunden andere Wünsche.

1. Keepalive: wird auf jeden Fall gesendet. Bitte mit Wireshark testen.
2. Sonnenuhr: Die meisten Kunden wünschen manuelles Einschalten nach der Einstellung.
3. Temperatursensor: Ist nur ein interner Sensor. Nicht für die absolute Umgebungstemperatur geeignet. Wenn man auf den Temperaturanstieg achtet, kann man die Umgebungstemperatur interpolieren.
4. Time-Zone und Winterzeit: Bitte Uhrzeit und die Lage eingeben. Rest läuft automatisch.

LG Andy

[Rafale]

2016-06-10 Wirashark for WOL.zip

(246.3 KiB) 427-mal heruntergeladen

Hallo Andy,
vielen Dank für Ihre Informationen.
Offensichtlich haben wir mit dem gleichen Gerät unterschiedliche Erfahrungen gemacht und diese können ja (wie bekannt) sehr subjektiv bewertet sein.
Objektiv lässt sich aber feststellen, dass der NET-PwrCtrl HUT das WOL protokolliert, dieses jedoch vom Endgerät nicht erkannt wird.
Ihrem Vorschlag entsprechend habe ich dies mit dem Wireshark aufgezeichnet und Ihnen die Screenshots in einer PDF (2016-06-10 Wirashark for WOL.zip) angehängt. Ich habe zum Vergleich die WOL von meiner Handy-App und von meiner PC-App mit eingefügt.
Und auch Wireshark erkennt die Telegramme der beiden Apps als WOL-Telegramm, nicht aber das vom NET-PwrCtrl HUT gesendete Telegramm.
Liegt das möglicherweise an der Zieladresse? Sollte dies nicht ein Broadcast-Telegramm sein - also an eine Broadcast-Adresse gesendet werden. Ihr Telegramm wird an die Adresse 0.4.0.0 gesendet - und dort vermutlich von niemandem erwartet.
Auch werden die WOL der Apps an den Zielport 9 gesendet, das Ihre aber an den Port 7 (speilt das eine Rolle?).
Wie auch immer ... ich bin nicht so der Fachmann, aber auch für mich scheint ersichtlich, das da etwas nicht passt.

Das mit dem Temperatursensor ist sehr schade, da man diesen (selbst bei vorgeschlagener Interpolierung) für gewöhnliche Raumtemperaturen (18°C - 23°C) nicht verwenden kann - und selbst Rutenbeck hat dies begriffen

Die übrigen Dinge sind für mich nicht so sehr von Bedeutung, da sie vom User beeinflussbar sind. Nehmt sie als Anregung oder Datenmüll

Also bitte bitte bitte die WOL-Geschichte noch mal prüfen und ein Update bereitstellen - währe schon sehr angenehm, wenn das funktionieren würde - gel?

Vielen Dank schon mal ...
Rafale

[andy]

Hallo Rafale,

Habe an WOL etwas geändert: Ports auf 54040, 9
Die durften keine Role spielen. Interessant!

Bitte die FW für HUT probieren:

NET-CONTROL 6.0 IO.zip

(375.78 KiB) 442-mal heruntergeladen

LG Andy

[Rafale]

Hallo Andy,
danke für Deine schnelle Korrektur der Ports. Das gesendete Packet wird nun auch vom Wireshark als MagicPacket erkannt. Jedoch funktioniert das Wecken der NAS noch immer nicht.
Ich denke, das Problem liegt in der Zieladresse. Diese ist noch immer mit 0.4.0.0 angegeben. Sollte dies aber nicht eine Broadcast-Adresse sein z.B. 255.255.255.255 oder die Broadcast-Adresse des SUB-Netzes verwendet werden? So machen das zumindest die anderen Apps, die ich z.Z. benutze.
Kannst Du das noch einmal prüfen - bitte, bitte, bitte
Vielen Dank!
Rafale

[andy]

Es wird natürlich als Broadcast gesendet. Die 0.4.0.0 kenne ich nicht. Du benutzt A Netzwerk. Ist die Maske ok?
Bei mir hat es auch mit den alten Portnummern (bei allen andern seit 5 Jahren auch...glaube ich) funktioniert.
Ist bei Dir Broacast blockiert? Prüfe genau Dein Netzwerk. Ich bin sicher die Leiste ist ok.

LG Andy

[Rafale]

Hallo Andy,
Ja, ich benutze ein "scheinbar" Klasse A-Netzwerk, welches aber in diesem Bereich zur Verwendung in Unternehmen zugelassen ist und vielfach auch so eingesetzt wird. Das verwendete Netzwerk ist Bestandteil eines Unternehmensnetzwerkes. Das von mir benutze Segment hat eine 24er Netzmaske (255.255.255.0) woraus sich die Netzwerkadresse 0 mit der Bradcast-Adresse 255 des Netzwerksegments 10.10.5.xxx ergeben.
Da ich ohne physikalische Veränderung des Netzwerks und seiner Komponenten sowie auch ohne Veränderung von Einstellungen an Router oder Switchen meine NAS vom PC und vom Handy aus wecken kann, sollte dies auch mit dem Net-PwrCtrl möglich sein. Eindeutig wird nun nach Deiner Änderung auch durch den Wireashark ein MagicPacket erkannt. Leider wird dies aber an die Adresse 0.4.0.0 gesendet. Dies kannst Du aus den ersten Screenshots des Wireshark (vergleichend zwischen allen drei WOL-Telegrammen) sehr leicht erkennen.
Die Netzwerkadressen sind dabei:
10.10.5.9 -> Net-PwrCtrl
10.10.5.157 -> Wireshark-PC mit WOL-App
10.10.5.176 -> Handy mit WOL-App
Selbst wenn PC und Net-PwrCtrl und NAS am gleichen Switch angeschlossen werden, ändert sich am WOL-Verhalten der NAS nichts.
Zum Spaß habe ich nun auch noch das WOL meines Routers aufgezeichnet (siehe Anhang), der das WOL auch (erfolgreich) an die Broadcast-Adresse 255.255.255.255 sendet - übrigens Source Port 1050 und Destination Port 2304 - der Port ist demnach also weniger entscheidend.
Im Vergleich dazu im Anhang noch einmal der Screenshot zum WOL des Net-PwrCtrl nach Deiner Änderung, bei dem für mein Verständnis das Telegramm nicht an die Braodcast-Adresse gesandt wird (Destination: 0.4.0.0).
Zitat Wikipedia: "Das Datenpaket ist entweder direkt an die Netzwerkkarte adressiert oder wird als Broadcast verschickt. Es enthält sechsmal in Folge den hexadezimalen Wert FF; unmittelbar danach erscheint die ununterbrochene 16-malige Wiederholung der MAC-Adresse der Netzwerkkarte des jeweiligen Zielsystems." und ich denke, dass man Wikipedia soweit noch trauen kann.
Schönen Abend noch und danke für Deine Unterstützung.
Rafale

[andy]

Morgen,

Bitte noch mal testen:

NET-CONTROL 6.0 IO.zip

(375.94 KiB) 449-mal heruntergeladen

Bei uns wird Broadcast bei Wireshark gezeigt.

Bin 2 Tage nicht da.

LG Andy

[Rafale]

Hallo Andy,
vielen Dank wieder für Deinen schnellen Service.
Diesmal hat es geklappt - die NAS läuft an .
Im Anhang findest Du wieder den Screenshot vom Wireshark.
Ich werde es noch ein wenig in unserer Applikation testen, aber ich denke, nun passt es - vielen Dank dafür und noch eine gute Zeit.
LG Ralph

[andy]

Danke Dir für die Mühe. Es hat auch uns geholfen.

LG Andy