Seltsam, dann habe ich auch keine Idee, wenn die Zuordnung passt und die Instanz vom richtigen Modul ist.
Mal einen Neustart probiert?
Habe sowohl den Symcon-Dienst, als auch den Win-Rechner auf dem Symcon läuft einmal durchgestartet. Geändert hat sich leider nix…SML Elektrizität Debug bleibt leer, der Cutter schnattert fröhlich vor sich hin im Debug…noch jmd eine Idee?
Grüße
Matthias
ich bin da ehrlicherweise ziemlich ratlos. Wahrscheinlich dreht Windows da wieder eine Sonderlocke…
Traust du dir zu, im Quelltext etwas zu ändern?
Dann probiere mal folgendes:
Zeile 64 in der module.php des Electricity-Moduls von
$this->SetReceiveDataFilter("");
auf
$this->SetReceiveDataFilter(".*");
anpassen. Bin gespannt, ob es dann funktioniert.
Grüße
Jürgen
Teste ich morgen! Danke dir!
Update: Habs getestet → leider keine Änderung.
Sehr merkwürdig alles…
Dann kommentiere bitte mal alle Zeilen mit
$this->SetReceiveDataFilter
weg. Wenn das auch nichts bringt, bin ich gedanklich auf dem Holzweg.
Grüße
Jürgen
Leider bleibt auch nach der Auskommentierung der drei Zeilen das Debug ruhig und still…
Was mir noch eingefallen ist, der Lesekopf wird ganz normal über einen Com-Port angesteuert von Windows. Aber das sollte normal sein, oder? Beim Com-Port und dem Cutter kommen die Daten ja an.
es bleibt merkwürdig.
Das ist alles ok. Es kommt ja was im Cutter an und wird auch weitergeleitet.
…Noch eine Idee:
Erzeuge mal eine JSON-Decoder-Instanz und hänge diese unkonfiguriert an den Cutter vom SML-Modul. Das macht zwar inhaltlich keinen Sinn, du kannst aber gucken, ob Daten ankommen. Wenn dort Daten kommen, können wir bestimmte Sachen schon mal ausschließen.
Hab ich gemacht, hier kommen Daten an. Auch wenn sie bissl komisch ausschauen 
dump (9).txt (62,3 KB)
das ist doch schon mal gut!
Wenn du die Serielle Schnittstelle vom Lesekopf in Symcon deaktivierst, dann musst du bei der Seriellen Schnittstelle, dem Cutter und der SML-Instanz ein graues Ausrufezeichen sehen. Ist das so?
Wenn ja, dann bitte nochmal die 3 Zeilen mit dem
$this->SetReceiveDataFilter(...
wegkomentieren und dann eine neue SML-Counter-Instanz anlegen und mit dem vorhandenen Cutter verbinden.
Absolut richtig, bei Deaktivierung habe ich vor SML, Cutter, das eben angelegte JSON und der Schnittstelle ein graues Ausrufenzeichen.
Habe Instanz neu angelegt mit auskommentierten Zeilen. Es kommen keine Daten bei SML an.
jetzt bin ich am Ende meines Lateins…
@paresy hast du noch eine Idee? Bei allen funktioniert das Modul und hier kommen keinerlei Daten an. Hat sich irgendetwas am Datenfluss geändert? ggf. nur bei Windows?
Wir haben bereits den ReceiveDataFilter rausgenommen, im Modul kommt direkt am Start
$data = json_decode($JSONString);
$this->SendDebug("Received", utf8_decode($data->Buffer), 1);
aber es kommt leider nichts an.
Grüße
Jürgen
sorry für den Aufwand. Ich hatte ja meinen alten Zähler auch ausgelesen und da hat alles wunderbar funktioniert. War ein Pafal Zähler. Allerdings war das damals ein anderes Modul bzw. auf eine andere Art. Gibt ein Thema dazu im Forum.
wie jetzt???
funktioniert es?
Nein das war mißverständlich. Ich habe es nochmal ausgebessert. Es funktioniert leider nicht.
Ich habe mal die Daten aus dem Debug bei mir auf einem 7.0er Testsystem unter Windows durch die Instanzkette gejagt. Das kommt soweit sauber bei der SML-Instanz an und wird auch korrekt dekodiert.
Das einzige, was ein wenig seltsam ist:
Schiebe ich beim ersten Mal das Telegramm inkl. Startframe in den Cutter, dann sendet der Cutter ein leeres Datenpaket an die SML-Instanz. Schicke ich dasselbe Telegramm noch mal an den Cutter, sendet er das erste Telegramm korrekt ohne Startframe an die SML-Instanz, hat dann aber das zweite Paket noch im Buffer. Das wäre ja soweit ok, weil er immer den Startframe vom nächsten Telegramm braucht, um das erste weiterzuleiten. Nur verstehe ich nicht, warum der Cutter dann beim aller ersten Mal ein leeres Datenpaket sendet. Ich hätte hier erwartet, dass das Telegramm komplett im Buffer landet und erst beim zweiten Telegramm etwas gesendet wird.
EDIT:
Aber vermutlich ist die Implementierung beim Cutter einfach so, dass er auch einen leeren Buffer sendet, wenn eine passende Trennzeichenfolge kommt. Jedenfalls kann ich die Daten von @vaclav2 unter Windows mit IPS 7.0 ohne Probleme nutzen und sie kommen sauber in der SML-Instanz an und werden von dieser verarbeitet. Von daher habe ich keine Idee, was da faul ist.
2 „Gefällt mir“
Ich hab jetzt noch ein paar Sachen ausprobiert. Seriellen Port neu angelegt, alte Module gelöscht … bringt leider alles nix. Wenn noch jmd Ideen bzw. Input hat, würde ich mich freuen.
Hallo
Heute den Pulse installiert und von SML Elektizität auf SML Elektizität über HTML gewechselt.
Leider kommen überhapt keine Daten an.
Die Bridge habe ich auf „webserver_force_enable“ true gestellt
Wenn ich „http://192.168.xxx.xxx/data.json?node_id=1“ aufrufe erhalte ich so win Paket.
eeeev×Ñœb b rcvGðŠ ISK •“ÂcWÝ v×Ñb b rcaw ISK •“Âa b
ÿÿrbeþ2zwaÇ‚ÿISKwa ÿ ISK •“Âwa ÿe €b RÿY 0¨wa ÿb RÿY 0¨wa ÿb RÿY wa ÿb RÿY am17wa ÿb RÿY am17wa ÿb RÿY wa a ÿbeR UÿÿÿçwaÇ‚ÿƒ¤JIìcô‚Š!7KZ_•QŸˆñ¦¥‹šZ]WoLXÍœ €e=5aG$p£D™cQh v×Ñžb b rcqc¸2 eeee <v
Das habe ich eingestellt
In der TibberApp funktioniert soweit die Datenabfrage.
Was mache ich falsch?
Kommen in der SML-Instanz überhaupt keine Daten an oder kommt das an, was du gepostet hast und es kann nicht dekodiert werden?
Wenn keine Daten ankommen, wie sieht es im I/O (HTTP Client) aus?
Guten Morgen.
Ist halt Weihnachten, grad nachgesehen und als Geschenk sind wie gewünscht alle Daten vorhanden.
Warum? Egal, hauptsache es hat geklappt und läuft.
Danke liebes Christkind 
Eine kurze Rückmeldung: Ich habe heute Symcon upgedatet und auf einmal hat SML die Variablen 1.8.0, 2.8.0 und 16.7.0 angelegt. Also hat das Update irgendwas umgestellt, dass die Daten bei der SML-Instanz ankommen. Evtl. hilft die Info jemandem.