Nachrichten

61

BECKHOFF / Re: MB_SERVER mit OpenHAB

« am: 02. August 2019, 06:12:45 »

ich sagte ja auch das die verbindung klassisch aufrecht erhalten werden sollte

aber in deiner eigenen wireshark aufzeichnung kann man ja klar sehen das openhub nach der abfrage die verbindung gezielt abbaut !

beispiel:
in der grafik in zeile 89 sieht man das openhub die empfangenen daten bestätigt [ACK] und gleichtzeitig ein [FIN] mitsendet
was bedeutet das verbindung abgebaut werden soll !

62

Codesys 2 / Re: http request oscat network Z-wave api

« am: 02. August 2019, 06:01:04 »

zuerst muss du wissen in welcher form die authorisierung erfolgen muss
dazu sollte die dokumentation der api heran gezogen werden !

hast du diese ?

63

BECKHOFF / Re: MB_SERVER mit OpenHAB

« am: 30. Juli 2019, 06:24:24 »

es wird nach jeder einzelnen abfrage die verbindung wieder abgebaut
dann wieder aufgebaut und so weiter

wenn du aber zylisch etwas abfragen möchtest ist das nicht besonders intelligent

effektiver wäre es wenn die verbindung stehen bleiben würde


opebhab beendet die tcp verbindung und baut sofort wieder eine neue verbindung auf

ressourcen technisch hast du aber mit dem ip_control nur eine mögliche verbindung konfiguriert
die sps benötigt aber etwas zeit um diesen verbindungsabbruch ihrerseits zu verarbeiten
es sieht aber so aus als ob openhab mit einer neuen verbindungsanfrage daher kommt obwohl die sps die alte noch nicht ihrerseits technisch abgebaut hat.

lösungwege:
1. openhub baut nicht ständig die verbinung auf/ab
2. du betriebst openhub im udp mode (sollte er das können)
3. du schaust das openhub nach einer abfrage eine gewisse ruhezeit einhält

die wireshark aufzeichnung schaue ich mir dann noch an, aber es hört sich nach genau dem problem an

64

BECKHOFF / Re: MB_SERVER mit OpenHAB

« am: 28. Juli 2019, 10:24:59 »

hallo

das verhalten ist auf jeden Fall nicht normal und hier läuft etwas grundlegend falsch

wer was genau macht kann man mit einer wireshark Aufzeichnung am besten auswerten


beim mb_server kann immer nur eine aktive verbindung abgehandlet werden
was aber auch im normalfall kein problem ist !

durch irgendeinen grund (vermutlich) lässt obenhub die zuletzt verwendete verbindung bestehen während für die folgende abfrage über eine neue zusätzliche verbindung abgehalndelt wird.

richtig wäre wenn obenhub die verbindung offen lässt und immer diese weiter verwendet oder nach der abfrage dieser wieder schliesst und erst dann eine neue verbindung aufbaut

65

Modulentwicklung / Re: Philips Hue

« am: 22. Juli 2019, 19:22:37 »

hallo

interesse besteht prinzipiell immer

kannst du bitte deine bauteine online stellen und soweit möglich eine beschreibung machen
oder beispielprojekte...

66

Modulentwicklung / Re: Neuer Baustein zum Parsen von JSON-Streams

« am: 22. Juli 2019, 19:21:12 »

hallo mattsches

inwieweit ist den diese wetterauswertung von dauer.. ?
alle bisherigen haben sie uns irgendwann abgedreht...


die bausteine werden ich langfristig sicherlich integrieren
wenn ich was brauche werde ich mich bei dir melden

die portierungen mache ich auch gerne

67

Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION

« am: 22. Juli 2019, 19:17:17 »

vielen dank für deine mitarbeit !!

68

BECKHOFF / Re: SMTP ohne Authentifizierung

« am: 09. Juli 2019, 16:14:32 »

ERROR_C must du als HEX Zahl anschauen

linkes WORD ist die Ablaufschirttnummer und rechtes WORd ist der letzte SMNP ErrorCode

Beim ersten versuch ist es der Fehlercode 550

beim zweiten versuch ist es der Fehlercode 501

das einfachste wäre wenn du eine wireshark mitschnitt des datenverkahr machen könntest

69

oscat.lib fuer CoDeSys 3 / Re: IP_CONFIG bei mehreren UDP Geräten

« am: 03. Juli 2019, 10:19:55 »

hallo

da die steuerung als server urgiert kennt diese anfangs ja nicht das gegenüber
sobald aber ein ulux etwas gesendet hat das erkennt der ip_control von wem das gekommen ist
darauf kannst du dann auch antworten da die source-ip und source port bekannt sind

kannst du denn auch als client an die ulux etwas senden ?
wenn ja dann brauchst du nur für jeden ulux einen eigene ip_control einrichten

aber irgendwie kommt mir das alles etwas merkwürid vor



gibt es denn irgendeine dokumentation übe das netzwerk verhalten der ulux

70

oscat.lib fuer CoDeSys 3 / Re: IP_CONFIG bei mehreren UDP Geräten

« am: 02. Juli 2019, 17:43:23 »

Hallo

SPS ist SERVER (passiv)
und beide ulux senden an die steuerung an den gleichen port (weil nicht änderbar am ulux)

wenn du den IP_CONTROL im C_MODE = 5 betreibst
sollte dieser von beliebigen Absendern UPD-Daten an den angegebenen Port entgegennehmen

natürlich kommen dann abwechselnd von den ulux geräten telegramme herein
diese solltest du möglichst im selben zyklus verarbeiten
da im nächsten zyklus schon wieder vom anderen etwas kommen kann

notfalls kann man gezielt den datenempfang blocken und wieder freigeben

aber du solltest mal den grundlegenden test machen ob von beiden geräten am selben IP_CONTROL daten-empfangsbuffer was ankommt

71

oscat.lib fuer CoDeSys 3 / Re: IP_CONFIG bei mehreren UDP Geräten

« am: 02. Juli 2019, 14:30:42 »

hallo

wer ist hier client und wer ist server


kannst du mal den original ip_control bausteine exportieren und in hier als datei online stellen

wie sieht deine ip_control parametrierung aus 

72

oscat.lib fuer CoDeSys 3 / Re: IP_CONFIG bei mehreren UDP Geräten

« am: 02. Juli 2019, 08:28:49 »

hallo

ich habe den technischen zusammen hang zwischen rpi und ulux noch nicht verstenden

kannst du das etwas genauer darstellen

welche geräte hast du
welche ip-adresse und port haben diese
mit wem genau willst du dann kommunizeren

mit mehreren geräten mit unterschiedlicher ip und gleichen port zu kommunizieren ist mal kein problem

73

BECKHOFF / Re: SMTP ohne Authentifizierung

« am: 28. Juni 2019, 06:22:39 »

hallo

ich habe kurz mal den code gecheckt

wenn der baustein kein password übergeben bekommt dann wird an sich der ganze authenifizierungs block ausgelassen
es wird dann unterschieden zwischen modus smtp und extend smtp

so wie es aussieht habe ich das vor langer zeit auch integriert (schon lange her ...)

sollte gehen....
 

74

oscat.lib fuer TwinCAT/CoDeSys / Re: Problem mit DATE_ADD seit OSCAT 331_beta (TwinCat) ?!?!

« am: 13. Juni 2019, 07:23:13 »

hallo

es gibt ja schon lange eine oscat_basic 3.33 dort sollte dieser fehler ja behoben sein

du solltest möglichst schnell deine "alte" version 3.31 austauschen !

75

oscat.lib fuer CoDeSys 3 / Re: DLOG_STORE_FILE_CSV überschreibt jedesmal das alte File

« am: 07. Juni 2019, 15:53:35 »

solange der dateiname gleich bleibt und der parameter "save_data" mit einer remantenten variable belegt ist sollte selbst ein reboot daran nichts ändern
und alle daten landen in dieser datei

ansonsten habe ich nicht wirklich verstanden was den nun hier das problem sein soll bzw wollt ihr denn nun genau machen

bring doch mal eine genauere beschreibung