Tja… Die Meldung ist leider dem alten Design des Moduls geschuldet.
Es blockiert so lange das Senden bis entweder eine Antwort oder ein Timeout kommt.
Währenddessen wird dann ein Fehler geworfen.
Sobald ich das Modul umbaue, sollte der Fehler weg sein.
Michael
So, mein kleines XB-ZB-Netzwerk ist ja nun ein paar Tage in Betrieb und folgendes ist zu beobachten:
Die rein serielle Kommunikation mit meiner Wetterstation auf dem Dach und dem Vliesfilter im Garten läuft ohne Probleme.
Etwas Sorgen macht mir die Verbindung in den Keller zu meinem Heizkessel.
Hier bekomme ich sporadisch - manchmal auch sehr viele - Exception Errors vom Typ „Send Data Timeout“ und „RequestSendData is locked“, wenn ich serielle Daten an meine Heizungssteuerung versende/empfange.
Auch das Schalten eines Data Outs funktioniert oft nicht und wirft den Fehler: „Send Data Timeout“ und oft beobachte ich, dass der in Symcon angezeigte Zustand nicht dem der Hardware entspricht.
Meine Frage - in erster Linie an Nall chan - ist nun: kann es sein, dass das Funksignal vom ersten Stock in den Keller (durch 2 Stahlbetondecken und 2 Wände zu stark geschwächt wird, obwohl ich die „Pro“-Variante XBee-S2C Module mit stärkerer Sendeleistung verwende?
Ich muss an einer Lösung arbeiten und Frage mich nun, ob ein zusätzlicher XB ZB Router im Erdgeschoss eine Verbesserung bringen könnte?
Ein weiteres mögliches Problem könnte sein, dass zu viele Befehle nacheinander an die XBee Module abgesendet werden. So sende ich jede Minute die errechnete Vorlauftemperatur, frage den aktuellen Vorlauf und den aktuellen Rücklauf ab und alle 15 Minuten stze ich den Output Port D3 und alle Befehle erzeugen ja auch ein Echo zurück an den Coordinator - immer jede volle Minute.
Gruß
Dieter
Also an den ‚RequestSendData is locked‘ bin ich dran.
Warum du einen Timeout beim senden hast, kann ich dir aber nicht wirklich sagen.
Ebensowenig ob dir ein zweiter Router hilft.
Hast du sonst die Möglichkeit die einzelnen Kommunikationen zu syncronisieren, so dass sie nicht alle zum gleichen Zeitpunkt, sondern leicht versetzt starten ?
Eventuell ist das Netzwerk einfach in dem Augenblick überfordert.
Bin mir auch gerade unsicher, aber eventuell gibt es einen Parameter (RR) wo du die Anzahl der Versuche noch mal um bis zu 3 erhöhen kannst.
Vielleicht wird es auch etwas/viel besser wenn ich die Warteschlange einbaue und die ‚RequestSendData is locked‘-Fehler somit behebe.
Michael
Hallo Michael,
Danke für Deine Antwort - bin gespannt was Deine geplanten Änderungen bewirken.
Ich habe auch mal einen XB-ZB Router in die Mitte aufgestellt und bilde mir ein die Fehlermeldungen sind etwas zurück gegangen.
Momentan wirft der „XBee_RequestState()“ Befehl am häufigsten Fehler - und zwar einen ‚Send Data Timeout‘
Gruß
Dieter
Hallo Michael,
ich habe mal nachgeschaut aber bei mir gibt es keinen ‚RR‘ Parameter, den man ändern kann.
Interessant ist auch folgendes:
wenn der Command „XBee_RequestState()“ per Event aufgerufen wird, wirft er meistens Exception Errors vom Typ „Send Data Timeout“
starte ich das script mit dem command „XBee_RequestState()“ manuell, läuft es ohne Probleme durch
schon seltsam - oder?
Gruß
Dieter
Baue das jetzt mal um, damit sollten die Fehler aufhören.
Aber warum nutzt du RequestState ?
Besser ist es, wenn die XBees den Status der Pins selbst mitteilen.
Michael
Hallo Michael,
ich habe ‚RequestState‘ benutzt, weil der geänderte Status oft nicht durch kam, obwohl angewählt.
Gruß
Dieter
Zu den XB ZB-Kanälen: Was genau muss ich einstellen, damit nur die obersten Kanäle (z.B. Kanal 14) im 2,4GHz Band genutzt werden. Ich habe irgendwie den Verdacht, dass mein Haus-WLAN die zeitweiligen Probleme verursachen könnte. Zu dem Thema gab es in diesem Forum ja auch schon Empfehlungen.
Ich vermute es ist der Parameter in „SC“ , verstehe aber die Nutzung nicht richtig.
Gruß
Dieter
Hallo Michael,
hast Du inzwischen schon was umgebaut? Momentan bekomme ich fast nur noch die „RequestSendData is locked“ Fehler.
Zur Info: ich habe den SC-Parameter meiner Module auf ‚4000‘ gesetzt, damit sollte die genutzte Frequenz nicht mit WLAN-Kanälen in Konflikt geraten.
Gruß
Dieter
Ja, fertig… Muss heute noch testen.
Ein paar Macken sind noch da.
Michael
Hallo Nall chan,
hier Dein DAU - leider muss ich mal wieder nerven.
Habe dann gestern ganz mutig auf das MASTER Modul gewechselt, in der Hoffnung, dass es nun reibungslos läuft.
Sofort hatte ich wieder die schon mal beschriebenen Probleme:
Nachrichten sind im Coordinator Port (komplett) zu sehen, werden machmal gar nicht oder vorne gekürzt an die Splitter/Cutter weitergeleitet.
Im Coordinator Port Debug Fenster ist alles noch korrekt vorhanden - aber im Gateway Debug Fenster sind die Nachrichten bereits verstümmelt oder fehlen ganz.
auch interessant dabei ist, dass dies erst nach Deinen letzten Änderungen auftritt. Vorher hatte ich manchmal Probleme Nachrichten an die Router zu senden, aber Messages von den Routern kamen immer komplett an.
Ich würde Dich bitten da noch mal reinzuschauen.
Gruß
Dieter
und dann habe ich seit der Modulumstellung alle 2 - 3 Minuten folgende Fehlermeldung:
dabei ist die Instance #22439 das XBee ZigBee Gateway und was die RegVar mit „Fehler beim 2. Senden“ sagen will ist mir auch nicht klar (vor allem welche RegVar - habe davon eine ganze Menge).
Gruß
Dieter
Ich verstehe das nicht wirklich, da der letzte Tester und jetzige Master identisch sind !
Sicher dass sich nicht vielleicht wieder die Einstellung der API-Version verstellt hat ?
Ich kann dass sonst morgen Nachmittag noch mal Aufbauen, aber aktuell kann ich mir das nicht erklären.
Michael
Hatte ich schon geprüft - Kein Haken bei API 2 und die Module hatte ich ohnehin nicht umgestellt.
Habe gerade auch noch mal geprüft: Im Coordinator Port Debug Fenster ist alles noch korrekt vorhanden - aber im Gateway Debug Fenster sind die Nachrichten bereits verstümmelt oder fehlen ganz.
Gruß
Dieter
Also ich habe das eben noch mal alles bei mir getestet und es läuft ohne Probleme.
Lediglich beim Empfang kann es sein, das die Daten fragmentiert eintreffen.
Siehe hier:
Du musst also in dem Script hinter der RegVar die Daten wieder zusammenfügen.
Verloren geht da bei meinen Versuchen nichts.
Auch in die andere Richtung funktioniert dies tadellos.
Deinen zweiten Beitrag mit den Fehlern im Log hatte ich auch glatt übersehen, hier verstehe ich noch gar nicht wie dieser Fehler zu Stande kommt. Wenn der String leer wäre, kommt er gar nicht bis zu der Stelle 
Kannst du mir einen Auszug vom Debug des SerialPort vom Coordinator posten, wenn der Fehler im Log auftritt ?
Ich baue noch etwas mehr Abfragen und Debugs ein und stelle das heute abend noch online.
Michael
Edit: Doch schon online.
Hallo Michael,
Danke, dass Du Dich der Sache noch mal annimmst.
Jetzt kommt es noch ‚doller‘ seit dem ich auf das Master umgestiegen bin, bekomme ich auch keine Fehlermeldungen mehr.
Sehr mysteriös :eek:
Ich stelle mal was zusammen - ich muss ja immer auf diesen Fall warten, denn es funktioniert ja auch zeitweise.
Gruß
Dieter
Hallo zusammen,
darf ich mal kurz zwischen fragen. Was kann ich denn alles über XBee alles anlernen.
Muss ich da auch auf eine Geräteliste achten? Ich habe dazu noch nichts gefunden.
Gruß
MacToolz
Ich habe explizit nur die Originalen Module von Digi als Koordinator getestet. Wenn du andere Geräte hast, welche ebenfalls das API Protokoll von Digi können, kannst du es ausprobieren. Ohne Garantie auf Erfolg.
EndDevice seitig ist die serielle Schnittstelle und die IO-Pins implementiert.
Direkt Geräte werden somit nicht unterstützt, dort muss du eine passende Instanz in IPS haben oder selber per Registervariable arbeiten.
Michael
Moin Michael,
ich wollte mal fragen, ob Du zu folgendem Problem vielleicht einen Tipp für mich hast.
In unserem Verein haben wir symcon auf einem Raspi mit dem XBee/ZBee Modul im Einsatz.
Der Coordinator ist direkt mit einer HAT-Platine auf dem Raspi.
Es gibt z.Zt. 7 Router, wobei davon nur immer einer dauernd eingeschaltet ist - die anderen werden nur bestromt, wenn die entsprechende Werkzeugmaschine eingeschaltet wird.
Nach einer frischen Installation funktioniert alles perfekt und das ZBee Netzwerk wird gehalten und auch Werkzeugmaschinen die eingeschaltet werden ‚joinen‘ das Netzwerk.
Nun zum Problem: Ab und an bricht das ZBee Netzwerk ab - keine Ahnung warum und keiner der Router kann danach ‚joinen‘ - der Coordinator jedoch scheit brav sein ‚ND‘ (Node Discovery) zu senden - aber es antwortet niemand.
Erst wenn wir den Coordinator ziehen (also stromlos machen = RESET?) und wieder stecken, baut sich das ZBee Netzwerk auf für X Tage.
Nun meine Frage: ist es mit Deinem PHP-Modul möglich an den Coordinator ein RESET zu senden, damit dieser Zwangsweise das Netzwerk neu aufbaut oder gibt es dafür einen anderen Befehl?
Zum prüfen ob das Netzwerk ‚steht‘ sende ich einen Dummy Command an das dauernd eingeschaltete Router-Modul und erhalte als Response ein ‚false‘ wenn der Befehl nicht abgesetzt werden kann und weiß damit, das das ZBee Netzwerk nicht mehr existiert.
Auch nur der kleinste Hinweis dazu wäre von großer Hilfe.
Gruß
Dieter
