Guten morgen zusammen!
seit geraumer Zeit werte ich mit meinem GIRA HS UDP-Pakete aus, die von verschiedenen, meist selbst gebauten Arduino-basierten Sensoren, via Ethernet gesendet werden.
Nun wollte ich einen Heizkörpersensor an den Start bringen, der Wemos-D1-ESP8266 WLAN basiert ist und die Vorlauf und Rücklauftemperatur meldet.
In der Debug-Seite des HS sieht das dann so aus und geht nicht.
10.10.2022 07:23:07 (Prot: ??) (Port: 6707) (Absender-IP: 192.168.178.17)
(Recv: 93) 0x42 0x61 0x64 0x20 0x4f 0x47 0x3a 0x32 0x38 0x2e 0x46 0x46 0x36 0x34 0x31 0x45 0x32 0x32 0x37 0x33 ... Rest mal weg gelassen
Bad OG:28.FF641E2273B9FD-Vorlauf:32.5C 28.FF641E07FAE23A-Ruecklauf:29.8C Spreizung: 2.8C END
(Gesamt: 0) (Work: 0) (Typ: Liste) (OK: 0)
Nach langem Suchen und drauf starren steht dort: (Prot: ??) und ist die Ursache für ein (OK:0)
Gleiche Daten von einem älteren Debian Server mit nc gesendet:
10.10.2022 07:26:59 (Prot: UDP) (Port: 6707) (Absender-IP: 192.168.178.187)
(Recv: 93) 0x42 0x61 0x64 0x20 0x4f 0x47 0x3a 0x32 0x38 0x2e 0x46 0x46 0x36 0x34 0x31 0x45 0x32 0x32 0x37 0x33 ... Rest mal weg gelassen
Bad OG:28.FF641E2273B9FD-Vorlauf:32.5C 28.FF641E07FAE23A-Ruecklauf:29.8C Spreizung: 2.8C END
(Gesamt: 15) (Work: 15) (Typ: Liste) (OK: 1)
Was macht ein UDP-Paket aus, das vom HS als solches erkannt wird oder nicht?
Ein UDP-Paket ist ja nun simpel, Da kann man nicht viel falsch machen.
Also muss das Problem doch irgendwo im IP-Rahmen liegen?
Weiss man, was der HS an der Stelle prüft?
Hatte jemand schon mal das Problem und hat einen Work-Around?
Viele Grüße
Nick
seit geraumer Zeit werte ich mit meinem GIRA HS UDP-Pakete aus, die von verschiedenen, meist selbst gebauten Arduino-basierten Sensoren, via Ethernet gesendet werden.
Nun wollte ich einen Heizkörpersensor an den Start bringen, der Wemos-D1-ESP8266 WLAN basiert ist und die Vorlauf und Rücklauftemperatur meldet.
In der Debug-Seite des HS sieht das dann so aus und geht nicht.
10.10.2022 07:23:07 (Prot: ??) (Port: 6707) (Absender-IP: 192.168.178.17)
(Recv: 93) 0x42 0x61 0x64 0x20 0x4f 0x47 0x3a 0x32 0x38 0x2e 0x46 0x46 0x36 0x34 0x31 0x45 0x32 0x32 0x37 0x33 ... Rest mal weg gelassen
Bad OG:28.FF641E2273B9FD-Vorlauf:32.5C 28.FF641E07FAE23A-Ruecklauf:29.8C Spreizung: 2.8C END
(Gesamt: 0) (Work: 0) (Typ: Liste) (OK: 0)
Nach langem Suchen und drauf starren steht dort: (Prot: ??) und ist die Ursache für ein (OK:0)
Gleiche Daten von einem älteren Debian Server mit nc gesendet:
10.10.2022 07:26:59 (Prot: UDP) (Port: 6707) (Absender-IP: 192.168.178.187)
(Recv: 93) 0x42 0x61 0x64 0x20 0x4f 0x47 0x3a 0x32 0x38 0x2e 0x46 0x46 0x36 0x34 0x31 0x45 0x32 0x32 0x37 0x33 ... Rest mal weg gelassen
Bad OG:28.FF641E2273B9FD-Vorlauf:32.5C 28.FF641E07FAE23A-Ruecklauf:29.8C Spreizung: 2.8C END
(Gesamt: 15) (Work: 15) (Typ: Liste) (OK: 1)
Was macht ein UDP-Paket aus, das vom HS als solches erkannt wird oder nicht?
Ein UDP-Paket ist ja nun simpel, Da kann man nicht viel falsch machen.
Also muss das Problem doch irgendwo im IP-Rahmen liegen?
Weiss man, was der HS an der Stelle prüft?
Hatte jemand schon mal das Problem und hat einen Work-Around?
Viele Grüße
Nick
Kommentar