Hm, mir ist noch gar nicht aufgefallen, dass das ein Problem ist. Ich habe einen Core i5-3570K (QuadCore) und da verursacht der Dienst 0% CPU-Auslatung mit gelegentlichen Spitzen bis 2%…
Im Moment habe ich leider keine Zeit, mich weiter mit dem eBus Connector zu beschäftigen. Aber wenn ich das nächste Mal dazu komme, Verbesserungen zu machen, kann ich auch schauen, ob mir was bzgl. Performance auffällt. Wird aber für mich schwierig zu testen sein…
Hallo,
bei mir ist es ähnlich. Ich arbeite zwar zur Zeit noch auf meinem Arbeitsrechner, ein AMD 4-Kern mit max. 3,4 GHz, aber der Prozess kommt nur auf ca. 0,8% CPU-Auslastung und das im Debug-Mode. Ferner habe ich die neue Variante noch nicht übernommen, die sicher noch etwas sparsamer ist.
Gruss Klaus.
Wie gesagt, bei mir läuft das alles auf einem single core n270 mit 1,6Ghz Atom. Der ist nicht gerade für seine Leistungsfähigkeit bekannt. Wenn es hier kein Potential mehr gibt oder es zu aufwendig wäre, ist es auch so.
Hallo,
trotzdem, der eBus Connector sollte auch auf einem 1,6Ghz Atom viel weniger Last erzeugen. Mein Heizungsrechner arbeitet auf einem Via-Miniboard. Da dürfte Dein Atom sogar etwas leistungsfähiger sein. Ich habe dort einige USB- und zur Zeit zwei COM-SSt am Laufen. Die COM-SSt werden dabei nicht so elegant abgefragt wie beim eBus Connector. Wie sieht es denn mit der Speicherauslastung aus? Wenn nicht genug frei verfügbar ist, dann kostet das Auslagern natürlich Zeit. Hast Du Version 1.2 im Einsatz?
Gruss Klaus.
Hallo terenyi,
super Sache bisher, doch leider funktioniert die Übergabe nach IPS-Symcon noch nicht so richtig (überhaupt nicht)…
Nachfolgend meine Paramter:
eBus-Ethernet-Adapter: Com10, 192.168.201.68:5000
PC-IP-Adresse vom IPS-Server: 192.168.201.100
eBus Connector Einstellungen: Com10, 8812, 192.168.201.100, 8813
Starte ich die Console per Hand, bekomme ich die empfangenen Paket sauber aufgezeigt.
Folgende Schritte habe ich in IPS ausgeführt:
UDP-Socket erstellt: Sende-Host 192.168.201.100 : 8812 - Empf.-Host: 192.168.201.100 : 8813
Dann Register Variable erstellt: Übergeordnete Instanz ist der UDP-Socket und die Ziel-ID ist das Skript:
<?
$eBusMessage = $_IPS[‚VALUE‘];
?>
Im Meldungsfenster werden keine eBus Meldungen angezeigt.
Kannst Du/könnt Ihr mir bitte helfen? DANKE
ZipFam
Gibst du im Ziel-Skript die Nachricht auch aus?
IPS_LogMessage("eBus", $eBusMessage);
Vielen Dank für Deine Antwort…
Irgendwie habe ich das Gefühl, dass keine Informationen im IPS ankommen…
Für mich zur Klarstellung: eBusConnectorConsole COM10 8812 192.168.201.100 8813 bedeutet:
COM10 = Virtuelle Schnittstelle des EBUS-Ethernet-Kopplers
8812 = Port des eBus-Connector (IPS sendet über diesen Port Nachrichten an den Connector)
192.168.201.100 = IP-Adresse vom IPS-Rechner
8813 = Port über den der eBus-Connector Nachrichten an IPS (192.168.201.100) leitet…
Irgendwo ist der Wurm drin… Die Firewall ist deaktiviert… Meldungen müssen durchkommen!
Hast Du noch eine Idee?
Also im 4. Screenshot hast du auf jeden Fall mal einen Tippfehler. Im Script muss es = und nicht == lauten.
Habe ich geändert … Vielen Dank… Hat leider keinen Erfolg gehabt …
Hm. Probier mal an den eBus Connector senden, also ob es in diese Richtung geht. Ansonsten würde ich mal mit netstat checken, ob die Ports offen sind bzw. sonst mal irgendeinen Port-Monitor probieren.
Das schaut schon mal nicht schlecht aus. Du kannst die Prozess-IDs noch abgleichen, 14124 müsste der eBus Connector sein, 10204 IP-Symcon.
Bist du sicher, dass da nicht noch irgendeine Art von Firewall (z.B. Windows Firewall) läuft? In der Konsole vom eBus Connector stehen am Anfang auch keine Fehlermeldungen, wo er den UDP Port aufmacht?
Mal probiert, den eBus Connector mit Adminrechten laufen zu lassen?
Ansonsten bin ich, was die Ferndiagnose betrifft, mit meinem Latein auch am Ende. Wie gesagt, mit irgendeiner UPD-Test-App (wo man Pakete senden und empfangen kann) könnte man es noch probieren.
Das Problem scheint ja an der UDP-Kommunikation zu liegen und hat nicht wirklich was mit dem eBus direkt zu tun, daher weiß ich hier leider auch nicht weiter.
Ich habe das Tool UDPTool benutzt … der eBusConnector sendet an die IP 192.168.149.1 … Warum ? Keine Ahnung ! Wenn ich jedenfalls IPS umstelle, erhalte ich die Meldungen - Super …
Vielleicht hat es mit VMWare Workstation 9 zu tun?..
Komisch. Kann gut sein, dass es was mit der VMware zu tun hat, habe es damit nicht getestet.
Aber Hauptsache es geht!
ja, vielen Dank erstmal … werde mich jetzt an den eBus Manager wagen…
Zitat:
[QUOTE=axelp;189943]Ich habe Probleme beim Senden, obwohl ich in meinen Skripten nichts geändert. So schaut es in der Konsole aus. Any idea?
[SENDING ] FF 15 B5 09 04 0E 2F 00 00 4F
[SEND ERR] Expected B5, received AA
[SENDING ] FF 15 B5 09 04 0E 2F 00 00 4F
[SEND ERR] Expected 15, received AA
[SENDING ] FF 15 B5 09 04 0E 2F 00 00 4F
[SEND ERR] Expected 15, received AA AA AA
Hallo Profis,
bei mir tritt der gleiche Effekt beim Aktivieren des Sende-Ports auf. Ohne Senden läuft alles einwandtfrei.... Die Einstellungen bzgl. der COM-Schnittstelle im Gerätemanager kann ich nicht ändern. Ich benutze den Ethernet-Koppler mit Windows Server 2003. Auch beim Verstellen des Pegels keine nennenswerte Änderungen.
Seit Ihr hier schon weiter?
ZipFamDer eBus Connector lauscht (in der neuesten Version) gleichzeitig während des Sendens und sendet jeweils das nächste Byte erst dann, wenn das vorige Byte korrekt „zurückgehört“ wurde.
Das Problem scheint aber zu sein, dass das gleichzeitige Lauschen und Senden bei manchen zu lange dauert, sodass dazwischen schon Auto-SYN-Zeichen von der Heizung gesendet werden, wodurch der eBus Connector abbricht und es neu versucht.
Ich werde - wenn ich dazukomme, momentan schaut es zeitlich bei mir aber schlecht aus - in den eBus Connector eine Option einbauen, mit der dieses „listen while send“ ein- oder ausgeschaltet werden kann. Wenn man es ausschaltet, sollte es beim Senden schnell genug gehen. Dafür kann es dann aber Kollisionen geben. (Seid ich bei mir das „listen while send“ verwende, habe ich übrigens das Problem mit dem Überhitzen des Speichers nicht mehr.)
Der Switch, um das „listen while send“ wieder auszuschalten, sollte für die Leute, die jetzt ein Problem haben, ein Workaround sein. Vielleicht finde ich auch eine Möglichkeit, das „listen while send“ generell zu beschleunigen, aber da kann ich nichts versprechen.
Ah, jetzt verstehe ich. Habe mein eBus Adapter über ein USB/Ethernet-Adapter laufen. Wahrscheinlich gibt es damit Timing-Probleme…
Hallo terenyi,
vielen DANK, dass Du Dich der Sache annimmst…
Ich freue mich schon auf die Lösung
So, habe jetzt noch einmal den eBus Connector etwas überarbeitet. Neben ein paar generellen Verbesserungen (sollte die Fehlerrate jetzt noch weiter senken, das Versenden bei aktivierter „listen while sending“ Funktion konnte ich aber leider nicht wirklich viel beschleunigen), gibt es zwei neue Funktionen:
[ul]
[li] NEU: Da manche Leute anscheinend Probleme damit haben, kann die zuvor genannte „listen while sending“ Funktion auch abgeschaltet werden (Nachrichten werden als Ganzes versendet, ohne auf Kollisionen zu achten). Dafür bei der Konsolen-Applikation einfach den entsprechenden Switch (-lws) weglassen bzw. das Registry-File für den Windows-Service entsprechend anpassen.
[/li][li] NEU: Zu Testzwecken kann die Zeit, die zum Versenden von einzelnen Nachrichten benötigt wird, in der Konsole angezeigt werden. Dafür bei der Konsolen-Applikation einfach den entsprechenden Switch (-sw) hinzufügen.
[/li][/ul]
Ein paar Beispielaufrufe:
Mit „listen while sending“:
eBusConnectorConsole COM10 8812 192.168.0.1 8813 -lws
Ohne „listen while sending“:
eBusConnectorConsole COM10 8812 192.168.0.1 8813
Mit „listen while sending“, mit Zeitmessung:
eBusConnectorConsole COM10 8812 192.168.0.1 8813 -lws -sw
Ohne „listen while sending“, mit Zeitmessung:
eBusConnectorConsole COM10 8812 192.168.0.1 8813 -sw
Die Leute, die mit der „listen while sending“ Funktion Probleme haben, lasst mich wissen, wie lange das Senden bei euch mit/ohne der Funktion dauert.