Die ReportID unterscheidet verschiedene Typen von Reports. Die sind für jedes HID-Gerät implementationsabhängig. Da musst Du in der Protokollbeschreibung nachsehen oder selbst das Protokoll analysieren. Die offizielle HID-Spezifikation findet sich unter USB.org - HID Tools. Mehr als mit der WMRS200 zu reden hab ich mit HID bisher nicht gemacht. Der Begriff HID-Buffer ist mir auch nicht geläufig.
Ich sehe da leider nirgendwo das Wörtchen HID. Das sieht mir da eher nach einem USB-Gerät mit eigenem Treiber aus. Die ReportID beim HID beschreibt von welchem Datensatztyp die gesendeten Daten sind (siehe HID Reports).
Da da Delphi-Beispielcode bei ist könntest Du Dir ein IP-Symcon-Modul schreiben. Ist eigentlich recht unkompliziert. Meine Delphi-Kenntnisse haben nach vier Jahren Inaktivität immernoch dafür gereicht.
Keine Treiber ist auch nicht richtig. Eher: Der Treiber ist beim OS dabei. Als was das USB-Gerät anzusehen ist steht dann schon in den Deskriptoren. Ich vermute, dass die Befehle in IP-Symcon nur für richtige HID-Devices funktionieren und nicht für jedes USB-Gerät.
Meinen Link würde ich so interpretieren, dass für identisch große Datensätze anhand der ReportID eine Unterscheidung möglich ist, wie diese zu interpretieren sind. Nimmt man z.B. einen Block von 3 Byte Länge könnte ReportID 0 bedeuten, dass Byte 1 Luftfeuchtigkeit, Byte 2 und 3 Temperatur darstellen; ReportID 1 sagt, dass Byte 1 bis 3 zusammen einen 24bit Zählerwert darstellen.
Bei der WMRS200 hat das keinen interessiert, da gibt es nur ReportID 0. Empfange Pakete sagen dann in Byte 1, wie viele Bytes des Datenblocks zu verwerten sind. Diese muss man dann bis zum Auftauchen einer Trennfolge zusammensetzen und die Datensätze interpretieren. Welcher Sensor was gesagt hat ist dann im jeweiligen Datenblock zu finden.
Wofür die ReportID gut ist, kann ich dir auch nicht sagen. In Protokollen wird nur definiert, wohin man senden soll. Ich kenne bis jetzt auch nur Geräte, wo an an die #0 gesendet werden muss. Der Rest wird dann über die folgenden Bytes geregelt, da dort meistens ein RS232 ähnliches Protokoll aufgesetzt ist.
Das würde gehen, wenn die Implementation auf Deinem PIC das zuläßt.
Man könnte das so implementieren, das man die übergebenen Daten als Addresse, Value -Paare versteht.
Also um Register 1 mit Wert 255 zu versorgen, kann man chr(1).chr(255) senden.
Zum Auslesen könnte man es so machen, das auf alle Addressen 128 addiert wird. Alle übergebenen Werte sind dann halt Adressen (oder man macht noch ein Befehlsbyte statt dem Adressbit dazu)
BTW: da ich das Projekt ja kenne: Der PIC sollte auch eine Quittung liefern, ob er einen Befehl angenommen und ausgeführt hat.
Ich bin der Meinung das Horsts Script noch einen Fehler hat.
if (((int)HID_GetDeviceVendorID($hid_id) != $vendor_id) && ((int)HID_GetDeviceProductID($hid_id) != $product_id))
An dieser Stelle wird davon ausgegangen das die HID noch eine Verbindung hat. Welche aber schon nicht mehr vorhanden sein kann. Hier müßte meines Erachtens noch eine Prüfung über HID_GetDevices erfolgen ob z.B. die Product ID überhaupt noch existiert.
Mein Velleman Board verliert auch manchmal die Verbindung. Ich muss dann den HID schließen und wieder öffnen - dann klappts wieder.
Deswegen habe ich mal das Skript ausprobiert. Ich habe die 3 IDs korrekt eingetragen - leider setzt das Skript nur den Timer und scheint sonst nichts zu machen? Es kommt keine Meldung (echo) und ein geschlossenes HID wird auch nicht geöffnet…
Wenn der HID das Gerät ansich nicht verliert, dann reicht ja, wenn du per Timer eine IPS_ApplySettings im Skript ausführst. Du kannst dir das Gesuche dann quasi sparen
Wenn der HID das Gerät ansich nicht verliert, dann reicht ja, wenn du per Timer eine IPS_ApplySettings im Skript ausführst. Du kannst dir das Gesuche dann quasi sparen
Ich habe zwei Gateways mit gleicher Vendor und PID, je nach dem welches Gerät ausfällt werden in IPS manchmal dach dem reconect die falschen serial ID´s zugewiesen. Gibt es eine Möglichkeit das zu verhindern? Außer manuell natürlich.
ja so habe ich das jetzt auch gemacht, es darf sich halt die serial ID nicht ändern, bei USB Geräten passiert das aber teilweise. Mir wäre deshalb eine weitere Kennung des Gerätes lieber, HID_GetDevices reicht hier leider nicht aus.
Das Script läuft bei mir unter (IPS 2.6) durch, erzeugt aber am Ende eine Warnung:
Warning: Gerät hat keinen Schreibzugriff in C:\IP-Symcon\scripts\ReConnect_VellemanUSB.php on line 54
[0] in function IPS_ApplyChanges in C:\IP-Symcon\scripts\ReConnect_VellemanUSB.php on line 54
device opened...
Das Problem scheint also in der Funktion IPS_ApplyChanges($hid_id); verursacht zu werden.
Die Verbindung wird nicht hergestellt, von Hand geht es problemlos.
Hat das mit der IPS Version 2.6 zu tun?
Gibt’s eine Lösung? Oder Tips, wie ich dem Problem auf den Grund gehen könnte?
ich komme irgendwie mit den Lösungsansätzen in diesem und anderen Threads nicht weiter.
Seit ich angefangen habe den IPS Dienst vor einer Sicherung zu beenden, um eine konsistente Datenbank zu haben,
verbindet sich zu 99% die HID Instanz nach dem Neustart des Dienstes nicht mehr mit mit meiner USB Wetterstation.
Die Wetterstation hängt an einen USB-to IP Gateway SX-1000U. Die HID-Instanz wird als fehlerhaft angezeigt, Haken bei geöffnet, Anzeige bei Gerät: ?:I Bridge.
Wenn ich nun den Haken wegnehme und auf übernehmen klicke- dann Haken wieder gesetzt und übernehmen-> geht nicht.
Wenn ich in das Dropdown bei Gerät klicke und exakt die gleiche Bezeichnung auswähle, dann Haken wieder setzen und auf übernehmen -> alles ok
Ich habe zur Zeit Version IPS 3.2 V3521
Das script macht entweder gar nichts, weil es das Device als geöffnet erkennt oder wenn ich das Gerät vorher per Befehl schliesse, dann findet es kein Device.
