So langsam wird es ja ganz fürchterlich weihnachtlich und so flog heute in der Mittagspause ein interessantes Weihnachts-Bastelprojekt durch meine Twitter-Timeline: Ein mit bunten LEDs geschmückter, äußerst hübscher Plastik-Weihnachtsbaum, der über ICMP-Pakete (also Ping-Anfragen) an diverse IPv6-Adressen in verschiedenen Farben blinkt und über einen Livestream beobachtet werden kann:
Die Bedienungsanleitung ist auf der Seite des Erfinders zu finden.
In einem meiner letzten Beiträge schrieb ich noch darüber, wie das Kommunikations-Kabel von Wago (ein USB-Kabel mit proprietärem Stecker für die Service-Schnittstelle auf diversen Controllern) unter Virtualbox genutzt werden kann und auch, dass es sich eigentlich nur um einen USB-zu-TTL-Adapter handelt.
Patrik stellte per Kommentar die Frage, ob man dann nicht auch statt des teuren Kabels einen normalen USB-zu-TTL-Adapter nutzen kann. Natürlich kann man.
Wer also statt des etwa 50€ teuren Kabels, das dann an 364 Tagen im Jahr irgendwo in einer Kiste verstaubt, lieber einen kleinen USB-Adapter für 2€ nutzen möchte, kann das problemlos tun.
Ich habe hier einen FTDI-Adapter für 2,20€ aus China, der per Mini-USB (da musste ich erstmal nach einem Kabel suchen, alles Micro-USB inzwischen) an den Computer angeschlossen wird. Er wird erkannt als:
ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Benötigt werden die Pins VCC, GND, TX und RX. Die Belegung am Wago-Controller ist von oben nach unten:
TxD und RxD werden logischerweise mit TX und RX verbunden, jedoch üblicherweise gekreuzt (was natürlich darauf ankommt, ob der genutzte Adapter auf der „Pin-Seite“ noch 1:1 belegt ist), VCC wird mit +5V verbunden, GND mit GND.
Das wars, mehr ist nicht zu tun. Das Kabel wird unter Windows beispielsweise in den Wago Ethernet Settings erkannt und kann zur Kommunikation genutzt werden.
Selbst gemacht steht übrigens aus dem Grund in Anführungszeichen, weil man ja hier nicht wirklich etwas selbst macht, außer einen FTDI-Adapter zu kaufen und anzuschließen.
CoDeSys in der Version 2.3 (also der klassischen Version, die unter anderem von den meisten WAGO-Controllern ausschließlich unterstützt wird) bringt eine eigene Webvisualisierung mit. Die Visu kann über CoDeSys zusammengesetzt werden, sie wird mit dem Programmdownload auf den Controller übertragen.
Das Problem daran: Die Visu besteht aus einem Java-Applet, das von manchen Browsern überhaupt nicht ausgeführt wird, unter anderem von Chrome oder mobilen Browsern.
CODESYS 3.5 bringt eine neue Visualisierung auf HTML5-Basis mit, die deutlich besser funktioniert. Jedoch laufen die „klassischen“ WAGO-Controller nicht mit CODESYS 3.5, wer nicht gerade einen PFC200 oder PFC100 einsetzt, wird davon nichts sehen.
Es gibt ein Projekt namens WebVisu auf sourceforge, das sich dieses Problems annimmt. Es stellt auf dem integrierten Webserver der Controller eine HTML5-Visu bereit, die mit CoDeSys 2.3 zusammenarbeitet und in wenigen Schritten auf den Controller „installiert“ werden kann.
Installiert insofern in Anführungszeichen, als dass diese Installation lediglich aus dem Kopieren einer einzelnen HTML-Datei auf den Controller besteht. Laut Wiki ist WebVisu kompatibel mit der WAGO 750-841 und dem Beck IPC, zufällig besitze ich einen uralten Controller 750-841 bei dem leider die Buskontakte nicht mehr besonders zuverlässig sind, aber zum Testen reicht es allemal.
Vermutlich funktioniert die Visu auch bei den anderen 750-8xx Controllern mit CoDeSys-WebVisu, davon habe ich allerdings kein Gerät zum spielen.
Die WebVisu.html wird einfach auf dem Controller unter /webserv abgelegt und ist danach unter der IP des Controllers unter /webserv/WebVisu.html zu finden.
Die Visualisierung wird unter CoDeSys ganz normal erstellt, das JAVA-Applet ist nachher auch problemlos nutzbar. Die HTML5-WebVisu ist nur zusätzlich vorhanden.
Zum Test habe ich einfach einen inkrementierenden Wert auf eine 8-fach Ausgangsklemme geschrieben und diesen Wert außerdem in der Visu als Zahlenwert, als LED-Zustand und als Kreisdiagramm dargestellt. Außerdem habe ich noch einen Toggle-Taster mit einer booleschen Variable eingefügt, um auch diesen Fall testen zu können.
Direkt in CoDeSys sieht das so aus:
In Chrome fehlt das Kreisdiagramm, generell werden neben dynamischen Formen wie dem Kreissegment auch Tabellen und Skalen nicht angezeigt. Vermutlich fehlen diese Darstellungen in der HTML5-WebVisu einfach:
Auf dem Smartphone wird die WebVisu quasi identisch dargestellt:
Die Bedienung der Schaltfläche funktioniert übrigens einwandfrei, sowohl im Desktop-Browser als auch auf dem Smartphone und die Grafikaktualisierung ist ziemlich flott und ohne Ruckeln.
Alles in allem also eine sehr passende Lösung für Leute, die eine einfache Webvisualisierung unter CoDeSys 2.3 erstellen wollen, die auch ohne JAVA-Applet und damit auch auf mobilen Geräten bedienbar ist.
Um mit SPS-Komponenten zu kommunizieren gibt es verschiedene Wege und fast alle führen zum Ziel. Bei bestimmten Einstellungsarbeiten oder Firmware-Updates ist es aber sinnvoll, die meistens vorhandene Service-Schnittstelle der Controller zu nutzen.
Jeder Hersteller bietet Service-Kabel an, die zu den eigenen Schnittstellen passen, die Kabel sind natürlich immer unterschiedlich.
Auch WAGO bietet ein „WAGO USB Service Cable“ an. Für Windows gibt es einen speziellen Treiber für dieses Kabel, für Linux nicht. Ich bin mir ziemlich sicher, dass dieser Artikel auch auf Siemens S7 und LOGO, sowie auf die meisten anderen SPS-Hersteller anwendbar ist, davon habe ich allerdings keine Altgeräte zum Basteln da.
Ich bin mir sicher, außer mir gibt es noch viele andere SPS-Menschen, die Zuhause Linux nutzen und zum Herumprobieren eine Virtuelle Maschine mit Windows laufen haben, in der die Entwicklungsumgebung läuft. Das Kommunikationskabel läuft allerdings in z.B. Virtualbox nicht ohne nachzuhelfen, wobei es sich wirklich um eine Kleinigkeit handelt.
Denn: Auch wenn jeder Hersteller ziemlich teure Kommunikationskabel in verschiedenen Ausführungen anbietet, eines haben sie gemeinsam: Es sind ziemlich stinknormale USB (oder RS232) auf TTL Konverter, die unter Debian als ttyUSB erkannt werden. Es muss lediglich der Virtualbox-Benutzer in die Gruppe dialout aufgenommen werden, damit er es benutzen darf:
usermod -aG dialout BENUTZERNAME
In der Virtualbox erscheint es bei installiertem Windows-Treiber dann ganz normal in der USB-Geräte-Auswahl:
Aktiviert man es dort, kann man es beispielsweise in den WAGO Ethernet Settings als Kommunikationsschnittstelle nutzen:
Ich betreibe seit langer Zeit ownCloud-Instanzen, um damit Daten zwischen diversen Geräten zu synchronisieren. Installation und Konfiguration sind sehr einfach und es gibt (neben WebDAV) native Clients für alle von mir genutzten Betriebssysteme.
Vor einiger Zeit habe ich ein Passwort geändert. Die Desktop-Clients unter Windows 7 und Debian funktionierten mit dem neuen Passwort anstandslos, ownCloud für Android hingegen nicht. Nach einigem Herumprobieren fand ich heraus, dass es eine hochgestellte 3 war (³), die das Problem verursachte. Ich änderte daraufhin das Passwort erneut (es enthielt weiterhin Sonderzeichen) und es funktionierte auf allen Geräten.
Seitdem ist einiges an Zeit vergangen und letztens erinnerte mich meine Passwort-Routine, das ownCloud-Passwort mal wieder zu ändern. Gesagt, getan und oh Wunder, ein Sonderzeichen funktionierte auf dem Android-Client nicht.
Dieses Mal war meine Neugier größer, ich deaktivierte die Zwangsumleitung auf HTTPS und schnitt den Netzwerkverkehr der App beim Einloggen über eine unverschlüsselte Verbindung mit. Die Login-Daten mit einigen Sonderzeichen sehen in der App so aus:
Im Mitschnitt sieht man schnell, wieso das Passwort nicht funktionieren kann (abgesehen davon, dass der Nutzer nicht existiert):
Halten wir also fest: Bestimmte Sonderzeichen werden von der „originalen“ ownCloud-Android-App zu Fragezeichen umgewandelt und so gesendet. Die „Standard-Sonderzeichen“ wie ?$% usw. scheinen zu funktionieren.
Da die App sowieso nicht unbedingt meine Definition einer guten Synchronisations-App erfüllt: Kann mir jemand eine gute WebDAV-App nennen, die unter Android die Verbindung mit ownCloud übernimmt und vielleicht auch mit den spezielleren Sonderzeichen klar kommt?
Vor ein paar Tagen habe ich eine kurze Übersicht über die Benutzung der OneWire-Schnittstelle in CODESYS 3.5 auf dem Raspberry Pi veröffentlicht. Inzwischen habe ich per Mail von mehreren Lesern die Frage nach einer funktionierenden Lösung mit Python bekommen, daher möchte ich das noch schnell hinterher schieben.
Um das ganze noch ein kleines Bisschen spannender zu machen, sind dieses Mal drei Sensoren gleichzeitig angeschlossen. Auf dem Breadboard sieht das so aus:
Schnell in gEDA abgezeichnet sieht es so aus:
Man sieht also, die Sensoren können parallel geschaltet werden, der Widerstand wird nur ein Mal benötigt.
Wenn, wie im oben bereits verlinkten Artikel die Kernelmodule über den Device Tree geladen sind (/boot/config.txt), sollten die drei Sensoren danach im Verzeichnis /sys/bus/w1/devices/ sichtbar sein, hier gibt es wieder für jeden Sensor einen Ordner, der mit seiner eindeutigen ID benannt ist:
Wie schon im ersten Artikel können auch hier die Werte mit der Datei w1_slave ausgegeben werden:
root@raspberrypi:/sys/bus/w1/devices/28-0216009b68ff# cat w1_slave
2f 01 4b 46 7f ff 0c 10 a7 : crc=a7 YES
2f 01 4b 46 7f ff 0c 10 a7 t=18937
So weit waren wir beim letzten Mal auch schon, jetzt gehts ans Python-Script.
Zuerst müssen wir die bis dahin ja noch nicht existente Datei mit dem Editor unserer Wahl öffnen. Ich mag nano, öffne die Datei also mit
nano temp.py
Um das Programm später mit dem richtigen Interpreter direkt ausführen zu können, müssen wir jetzt im Shebang python als ebendiesen nennen, danach legen wir fest, welche Bibliotheken geladen werden sollen:
#!/usr/bin/env python
import os, time, sys
Um Fehlern aus dem Wege zu gehen, laden wir nun noch die Kernelmodule, die wir nutzen möchten:
os.system('modprobe w1-gpio')
os.system('modprobe w1-therm')
Am Anfang des Programmes legen wir nun noch ein paar Werte als Variablen fest, die wir später benutzen können. Ich habe als sensorcount die Anzahl des Sensoren angegeben, unter sensors die Kennung der drei Sensoren als Array, unter sensorpath den Pfad zu den Geräteverzeichnissen als String und unter sensorfile den Namen der Datei ebenfalls als String:
sensorcount = 3
sensors = ['28-0216009b68ff', '28-021600b769ff', '28-021600bb4dff'];
sensorpath = '/sys/bus/w1/devices/'
sensorfile = '/w1_slave'
Nun erstellen wir die Funktion, die die Sensordaten abfragt und verarbeitet:
def callsensor(sensor):
f = open(sensorpath + sensor + sensorfile, 'r')
lines = f.readlines()
f.close()
if lines[0].strip() [-3:] != 'YES':
sys.exit('Fehler bei Sensor ' + sensor)
temp_line = lines[1].find('t=')
if temp_line != -1:
temp_output = lines[1].strip() [temp_line+2:]
temp_celsius = float(temp_output) / 1000
return temp_celsius
Die Funktion öffnet die Gerätedatei im Lesemodus, schreibt den Inhalt auf lines und schließt sie dann wieder. Die Variable sensor wird dabei später als Parameter beim Funktionsaufruf mitgegeben.
Zeile 1 wird nun auf die letzten drei Zeichen gekürzt und geprüft, ob diese „YES“ sind, also ob die Prüfsumme des Sensors okay ist. Wenn nicht, wird das Programm mit einer Fehlermeldung abgebrochen.
Nun wird der Index (also die Position) des Strings t= in der zweiten Zeile ermittelt. Ist diese nicht -1 (das gibt find zurück, wenn nichts gefunden wurde), wird Zeile 2 auf die Zeichen nach t= gekürzt (das ist der fünfstellige Temperaturwert des Sensors), der Wert wird durch 1000 geteilt und wir erhalten so den Wert in °C. Die Funktion wird dann beendet und der Temperaturwert zurückgegeben.
Nun fehlt nur noch der Teil, der die Funktion beim Aufruf des Programms ausführt und die Werte an stdout (also momentan die Konsole) zurückgibt:
for i in range(0, sensorcount):
s = sensors[i]
print('Sensor ' + str(i) + ': ' + str(callsensor(s)))
sys.exit()
Hier haben wir eine for-Schleife, die die Funktion callsensor für jeden Sensor einmal aufruft und die Sensor-ID aus dem Array als Parameter an callsensor übergibt. Das Ergebnis wird ausgegeben und das Programm wird beendet.
Das Programm müssen wir nun nur noch speichern. Um es ausführen zu können, müssen wir es noch ausführbar machen:
chmod +x temp.py
Wenn wir es nun in der Konsole ausführen, bekommen wir drei Ausgaben für unsere Sensoren:
root@raspberrypi:~/tutorials/temperatur# ./temp.py
Sensor 0: 18.437
Sensor 1: 19.937
Sensor 2: 20.062
Zum Schluss hänge ich die Programmdatei (übrigens kommentiert) hier an: Python-Programm temp.py
Wer sich mal etwas mit dem kostengünstigen verdrahten moderner Häuser oder Wohnungen auseinander gesetzt hat, wird schon auf den 1-Wire oder OneWire Bus gestoßen sein. Dieser Bus ermöglicht es, mit einem geringen Verdrahtungsaufwand zum Beispiel Sensoren an ein Gerät anzuschließen. Es werden mindestens zwei Adern benötigt, besser drei oder vier, es können jedoch mehrere Sensoren parallel angeschlossen werden.
Ein sehr beliebter Sensor ist der Temperatursensor 18B20 bzw. DS18B20, er misst die Temperatur auf 0,5°C genau und gibt diese als tausendstel aus, 21,5°C zeigt der Sensor also als 21500 an. Die Messung wird über eine Prüfsumme validiert.
Der Raspberry Pi bringt einen 1-Wire-Bus mit, der über die GPIO-Pins läuft. Der Bus mus jedoch zuerst eingeschaltet werden, dies geschieht über die Datei /boot/config.txt, hier muss eine Zeile mit folgendem Inhalt eingetragen werden:
dtoverlay=w1-gpio
Dies aktiviert im Device Tree die 1-Wire-Schnittstelle auf dem Standard-GPIO-Pin, also Pin 7. Nach dieser Änderung muss ein Neustart durchgeführt werden, der Bus ist nun aktiv.
Der Sensor hat drei Beinchen. Schaut man auf die abgeflachte Seite mit der Beschriftung, ist das linke Beinchen die Nummer 1 und damit GND (also 0V), das mittlere die Nummer 2 und damit DQ (die Datenleitung) und das rechte Beinchen ist die Nummer 3 und stellt die Versorgungsleitung VCC (3,3V) dar.
In diesem Beispiel schließen wir den DS18B20 mit drei Adern an die 3,3V Versorgungsspannung des Raspberry Pi an. Bei größeren Leitungslängen empfiehlt es sich, für die Versorgungsspannung 5V zu nehmen und den Widerstand von DQ auf eine separate Ader mit 3,3V zu ziehen. Zum Testen reicht dieser Aufbau aber allemal.
Die Verkabelung kann entweder fliegend verlötet werden, oder aber (etwas eleganter und einfacher) auf einem Breadboard aufgesteckt werden. Ich tat letzteres, wenn auch wegen akuten Jumperwire-Mangels nicht besonders ordentlich:
Jeder Sensor hat eine einmalige Kennung, unter dieser Kennung wird auch ein Geräteordner unter /sys/bus/w1/devices angelegt. In meinem Falle hat der Sensor die Kennung 28-021600bb4dff, daher ist der Geräteordner /sys/bus/w1/devices/28-021600bb4dff. In diesem Ordner befindet sich die Gerätedatei w1_slave. Lässt man sich diese Datei beispielsweise mit cat ausgeben, wird der Sensor abgefragt und die Checksumme, sowie die Temperatur ausgegeben:
Stimmen beide Checksummen überein, ist das Ergebnis plausibel und hinter der crc steht „YES“. Im Fehlerfall würde dort „NO“ stehen. In der zweiten Zeile wird die Temperatur angezeigt, teilt man diesen Wert durch 1000 kommt man auf die Temperatur in °C, bei mir also 20,125°C.
Das ist eigentlich schon alles. Diese Datei kann man natürlich über Scripte oder Programme auslesen und weiter verwenden.
Seit längerem gibt es ja von 3S die CODESYS Laufzeit für den Raspberry Pi, eine meiner Meinung nach für Privatanwender und Bastler schöne Lösung in die Automatisierung einzusteigen, ohne hohe Ausgaben für „echte“ SPS-Hardware zu haben.
Über CODESYS auf dem Raspberry Pi habe ich schon zwei Artikel verfasst. Im ersten Artikel wird unter anderem erklärt, wie die Laufzeit auf dem Gerät installiert wird und wie eine Verbindung zum Raspberry Pi hergestellt wird, im zweiten geht es eher um die Python-Bibliothek Pymodbus, die die Modbus-Kommunikation zum Beispiel zwischen einem Raspberry Pi und einem Controller mit CODESYS ermöglicht.
Wir benötigen also einen Raspberry Pi mit installierter CODESYS Laufzeit, sowie dem angeschlossenen und funktionierenden Sensor wie oben beschrieben.
Im CODESYS legen wir ein neues Projekt an und wählen als Zielsystem den Raspberry Pi.
Nachdem das Programm angelegt ist, baut sich automatisch die Struktur auf und man sieht auch schon den Punkt für 1-Wire (bzw. Onewire).
Zunächst muss eine Verbindung zum Raspberry Pi hergestellt werden, dafür werden per Doppelklick auf den Raspberry die Geräteeinstellungen geöffnet und die IP des Gerätes eingetragen (und die Zugangsdaten, falls nicht zuvor schon einmal geschehen). Wenn die Verbindung grün angezeigt wird, ist alles in Ordnung.
Nun kann mit der Konfiguration des 1-Wire Sensors begonnen werden. Per Rechtsklick auf den Eintrag „Onewire“ öffnet sich das Kontextmenü, hier wird über den Menüpunkt „Gerät anhängen“ das Gerät „Onewire_master“ angehängt.
Auf die selbe Art wird nun noch der Sensor DS18B20 angehängt: Rechtsklick auf Onewire_master, Gerät anhängen, DS18B20 auswählen.
Nun sind alle Geräte vorhanden, die benötigt werden. Der Sensor muss nun noch Parametriert werden, die Gerätekennung muss eingetragen werden. Hierzu öffnet man das Device per Doppelklick und trägt im Reiter „1-wire bus Parameter“ in der Spalte „Wert“ die Kennung ein, die eben schon in der Konsole angezeigt wurde, bei mir also 28-021600bb4dff. Das ganze als String, also in Hochkommata ‚.
Das war eigentlich schon alles, der Sensor sollte nun im Programm benutzbar sein. Den Temperaturwert kann man recht einfach nutzen, indem man den String rTemp des Sensors ausliest und beispielsweise auf eine Variable schreibt. Der Wert rTemp ist ein REAL, die Variable muss also auch den Typ REAL haben.
Im laufenden Programm sieht das ganze dann so aus:
Eigentlich recht simpel. Da mehrere Sensoren parallel angeschlossen werden können, kann man so einfach die Temperatur in einem ganzen Haus messen und dank der HTML5-WebVisu von CODESYS 3.5 auch optisch ansprechend im Netzwerk abrufbar machen. Eine Heizungssteuerung wäre natürlich auch ein guter Anwendungszweck.
Ich habe mir quasi als Vorsatz für 2016 vorgenommen, Speziallösungen für WordPress, die eventuell auch anderen helfen könnten, im WordPress Repository in Pluginform zu veröffentlichen.
Das erste Plugin wurde vorgestern gesichtet und freigegeben und ist seit eben im Repository verfügbar, es handelt sich um „Simple Terms And Conditions for BuddyPress“ und fügt, wie der Name vielleicht schon vermuten lässt, der BuddyPress-Registrierungsseite eine Checkbox zum Bestätigen der Nutzungsbedingungen hinzu.
Alle angezeigten Texte, sowie die Style-Parameter des umschließenden div lassen sich über das Backend ändern, es muss also nirgendwo in den Code eingegriffen werden.
Aktuell arbeite ich an Version 1.1 mit übersetzbaren Strings und deutscher Sprachdatei.
Ich habe, da höchstwahrscheinlich demnächst mindestens ein weiteres Plugin folgt, eine Unterseite angelegt, die als Verzeichnis der Plugins dienen soll. Das Plugin selbst hat eine eigene Seite mit einer etwas ausführlicheren Beschreibung und Anleitung erhalten.
Heute Mittag stellte ich mit erstaunen mehrfach fest, dass ich mich in der Uhrzeit geirrt habe. Ich habe mehrfach von meinem Smartphone die Uhrzeit abgelesen und kurze Zeit später anderswo auf einer anderen Uhr festgestellt, dass gerade innerhalb einer halben Minute etwa 10 Minuten vergangen sein mussten.
Das war äußerst verwirrend, weil mir das sonst nicht passiert. Ich habe ein recht gutes Zeitgefühl und wenn ich gefühlt alle 10 Minuten auf eine Uhr sehe, sind meistens auch ziemlich genau 10 echte Minuten vergangen.
Die Lösung heute:
Offenbar gingen die Uhren im eplus-Mobilfunknetz verkehrt.
Laut eplus soll das Problem behoben sein. Da aber die Mobiltelefone nicht ständig nach der aktuellen Uhrzeit fragen, geht zumindest mein OnePlus One noch etwa 10 Minuten nach. Ein Neustart des Gerätes oder das Aus- und wieder Einschalten des Mobilfunknetzes behebt das Problem.
Im März 2013 schrieb ich einen Artikel über die Behandlung eingehender Mails an Postfächer bei outlook.com und hotmail. Status damals war: Es gibt offensichtlich geblockte IP-Ranges, von denen Mails angenommen, aber nicht dem Empfänger zugestellt werden. Der Sender weiß so nicht, dass seine Mail nicht ankam, der Empfänger weiß nicht, dass er etwas hätte empfangen können. Eine gefährliche Situation also.
Im SSF wurde nun ein Erfahrungsbericht über Hosted Exchange bei OVH geschrieben (Hint: Nicht toll), von wo nach einigen Vorkommnissen ein Wechsel zu Microsoft selbst mit Office365 vollzogen wurde. Das weckte in mir die Erinnerung an die Erfahrungen mit Microsoft-Mailexperten damals, woraufhin ich gemeinsam mit dem Verfasser die heutige Konfiguration prüfte.
Kurz gesagt, das Verhalten von damals konnte ich nicht nachstellen.
Mein produktiver Mailserver wurde damals nach längerem Hin und Her mit dem Support entblockt und kann heute Mails an outlook.com senden, sie landen allerdings reproduzierbar im Spam.
Sende ich eine Mail an das Konto bei Office365, kommt diese ohne Beanstandung mit einem Spam-Level von 1 durch (als Spam werden Nachrichten zwischen 5 und 10 gewertet).
Sende ich eine Mail von einem meiner Server bei OVH stellt sich das Szenario anders, aber okay dar.
outlook.com bricht die Kommunikation nach dem mail from: ab mit folgender Fehlermeldung:
mail from: testmail@helium.fmaihost.de
550 SC-001 (BAY004-MC1F41) Unfortunately, messages from 37.59.60.14 weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
Connection closed by foreign host.
Sende ich vom gleichen Server eine Mail an das Konto bei Office365, kommt die Mail auch hier anstandslos durch.
Es ist zwar beides Outlook, die Spam-Filter unterscheiden sich aber offenbar stark, für die Kostenlosen Postfächer bei outlook.com werden offensichtlich IP-Bereiche gewisser Hoster komplett gesperrt. Ärgerlich für Kunden von OVH.
Wir verwenden Cookies, um Ihnen das beste Nutzererlebnis bieten zu können. Wenn Sie fortfahren, diese Seite zu verwenden, nehmen wir an, dass Sie damit einverstanden sind.
Akzeptieren
Datenschutzerklärung