[Gelöst] userReading maximale Länge oder webcall maximale Länge

Begonnen von pula, 23 Dezember 2017, 18:13:25

Vorheriges Thema - Nächstes Thema

pula

Hallo,

ich arbeite grad an einer Sache, bei der ich einen ziemlich langen JSON-String per webcall in ein Reading schreiben möchte (Kanalinformationen inkl. laufender Sendung aus Kodi für ein widget in ftui).
Ich mache das mittels eines kleinen Skripts, das dann die FHEM-Url entsprechend feuert.
Leider wird der übermittelte String bei genau 15251 Zeichen abgeschnitten. Gibt es hier ein Limit? Und lässt es sich eventuell umgehen?

Danke im voraus und Cheers,

Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

pula

Popcorn? :-)
Eine Alternative wäre, für jeden Kanal ein Reading zu erzeugen, aber das wären dann ziemlich viele Readings...
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

betateilchen

Mit erschließt sich der Sinn nicht, in einem reading einen so langen String abzulegen. Dafür sind readings eigentlich nicht gedacht.


-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

pula

#4
Verstehe ich.
Der Sinn dahinter ist eigentlich ganz einfach erklärt:
Die Abfrage von den Kanal-Informationen von Kodi dauert je nach verwendeter Hardware einige Sekunden (weil für jeden einzelnen Kanal ein rpc-Call gemacht werden muss), was sich in einem Frontend wie ftui meiner Meinung nach nicht gerade gut macht, vor allem, weil ftui ja eher auf schwachbrüstigerer Hardware wie Tablets läuft und vor allem für menschliche Interaktion gemacht ist (und als Mensch ist Geduld nicht grad meine Stärke, wenn ich auf ein Tablet warten muss).
Die Idee ist, die benötigten Infos auf eher stärkerer Hardware (bei mir ein Linux-Server, auf dem fhem läuft) periodisch abzufragen und dann in ftui nur noch die Daten auszuwerten.
Ich fände es schön, wenn ich dann auf dem Tablet, auf dem ftui angezeigt wird, per Dropdown einen Kanal aussuchen kann und auch die Info habe, was gerade wo läuft....
Hast Du alternative Ideen? Wie gesagt, wenn ich zb 100 Kanäle in je einem Reading speichere, geht das auch, aber irgendwie erscheint mir das nicht so prickelnd...
Wenn ich die aktuellen Programm-Infos in dem Dropdown nicht ausgebe, geht es sich mit der Länge des Readings aus, aber komfortabler wäre natürlich, wenn diese Info auch angezeigt werden würde...




fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

herrmannj

es gibt für die Länge der URL inkl der Parameter (dein JSON) keine harte Grenze. In der Regel begrenzen sowohl Server als auch der Client. Mit knapp 16k bist Du schon sehr weit vorn, es gibt Clients die kappen bei 2k. In FHEMWEB konnte ich auf die Schnelle kein Limit sehen, es ist wohl Dein Client (der Sender).

Unabhängig von Sinn oder Unsinn das in ein Reading zu packen, solltest Du das als POST absenden, nicht als GET.


pula

Hallo,

danke für die Antworten!
Bin jetzt auf die Ursache für das Problem gestossen. Hatte nichts mit der Länge zu tun, sondern damit, daß sich in dem String, der ins Reading sollte ein "&" versteckt hatte. Hab das jetzt entsprechend kodiert, jetzt funktioniert alles wunderbar :-)

Sorry für die blöde/falsche Frage...

Cheers,

Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

KernSani

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

pula

fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram