Meldungen seit controller v3.3 zu falschem Datentyp
-
@apollon77 said in Meldungen seit controller v3.3 zu falschem Datentyp:
@crunchip Aulo wenn das was nicht geht nur die Anzeige der versionsnummer ist dann ist das ja verkraftbar
Oder?Ich habe das jetzt nochmal gechecked. @crunchip hat recht. Konfigurationsmässig geht beim Radar2 garnichts mehr. In der Konfig funktioniert nicht mal mehr der speichern und schliessen Button und man kann keine neuen Geräte hinzufügen.
Das ist mir garnicht aufgefallen, weil er trotzdem IRGENDWO her die alten Daten ausliest. Das ganze muss schon vor ein paar Versionen passiert sein.
Hier die Konfig, komplett leer:
Die Daten kommen aber trotzdem:
Kommen die aus der objects.json?
Ich bin gerade mal WEIT zurück auf die 1.2.5 gegangen und siehe da, die Objekte sind da:
Issue ist erstellt:
https://github.com/frankjoke/ioBroker.radar2/issues/101 -
@fabian1 sagte in Meldungen seit controller v3.3 zu falschem Datentyp:
ch bin gerade mal WEIT zurück auf die 1.2.5 gegangen und siehe da, die Objekte sind da:
das hab ich so nicht probiert, ob ne "uralt" Version mit admin5 klar kommt, bekannt ist jedenfalls das seit admin5 die Konfigseite nicht mehr funktioniert, nur mit alter Oberfläche scheinbar(jedoch noch nicht getestet).
nach dem gestrigen Aufruf einer neuen Version hatte ich auch nicht vorher kontrolliert, was geändert wurde, sondern nur installiert, in der Hoffnung dass das Konfigproblem damit behoben sei. -
@crunchip said in Meldungen seit controller v3.3 zu falschem Datentyp:
@fabian1 sagte in Meldungen seit controller v3.3 zu falschem Datentyp:
ch bin gerade mal WEIT zurück auf die 1.2.5 gegangen und siehe da, die Objekte sind da:
das hab ich so nicht probiert, ob ne "uralt" Version mit admin5 klar kommt, bekannt ist jedenfalls das seit admin5 die Konfigseite nicht mehr funktioniert, nur mit alter Oberfläche scheinbar(jedoch noch nicht getestet).
nach dem gestrigen Aufruf einer neuen Version hatte ich auch nicht vorher kontrolliert, was geändert wurde, sondern nur installiert, in der Hoffnung dass das Konfigproblem damit behoben sei.In der neuen Github Version funktioniert die Konfig jetzt wieder!
-
Hallo
bei mir läuft der IObroker jetzt ca seit einer Woche auf js3.3 und mit admin5. Bisher sehr reibungslos doch heute werde ich auf einmal durch einen übervollen Log überrascht der durch den mqtt Adapter einen Datenpunkttyp meldet:
2021-08-18 06:07:46.587 - [32minfo[39m: mqtt.0 (843) State value to set for "mqtt.0.HeizKellerTank2.Lux.Helligkeit" has to be type "number" but received type "string"Wenn ich es richtig sehe steht auf Github, dass mit Version 2.4.0 vom 9.5.2021 für js3.3 diese datentypfehler berücksichtigt wurden.
Was läuft falsch und kann ich tun?
Besten Dank.
-
@pete0815 Instanz stoppen, DP löschen, Instanz starten, wenn weg ok, wenn nicht issue
-
@crunchip Danke! Fahre gleich einen Test. VG
-
@pete0815 naja die andere frage ist warum eine Helligkeit als String ankommt. Sendet da ggf jemand anders Müll?
-
@apollon77 sagte in Meldungen seit controller v3.3 zu falschem Datentyp:
@pete0815 naja die andere frage ist warum eine Helligkeit als String ankommt. Sendet da ggf jemand anders Müll?
ich denke MQTT sendet (bisher??) immer STRING
-
@homoran said in Meldungen seit controller v3.3 zu falschem Datentyp:
@apollon77 sagte in Meldungen seit controller v3.3 zu falschem Datentyp:
@pete0815 naja die andere frage ist warum eine Helligkeit als String ankommt. Sendet da ggf jemand anders Müll?
ich denke MQTT sendet (bisher??) immer STRING
So war auch mein Verständnis und habe so den Einstieg zur ALIAS Nutzung gelernt.
Da ich vor @crunchip Hinweis bereits ein Restore angestoßen habe, kam es nicht mehr zur Durchführung aber bisher ist Ruhe. Fand es nur "komisch" da bisher alles gut lief und mich heute morgen aus dem NICHTS 16MB der Log-Datei anlachten. Muß jetzt mal die älteren Logs durchsuchen ob heute Nacht wirklich die erste war wo dies los ging, aber gestern war ich noch im Log und der war "sauber".
Edit: Die Meldungen bzgl. falscher Datentyp laufen bei mir von 20:45h bis 6:30h alle 20 Sekunden in den Log. Daraufhin gestern nochmal mit Hilfe meine Blocklys untersucht, aber am Type des Mqtt DPs ändert das ja erst mal nichts. Also die Mqtt DPs (type = number) gelöscht und Adapter neu gestartet. Erst mal war Ruhe (type=string). Heute morgen wieder der Log voll. Dies betrifft 2 DPs über Mqtt. Komischerweise ist ein DP wieder geändert in type=number er meldet im Log aber den anderen DP den ich mit type=string in den objekten finde.
mqtt.0 2021-08-19 09:18:18.835 info State value to set for "mqtt.0.HeizKellerTank2.Lux.Helligkeit" has to be type "string" but received type "number"{ "common": { "name": "HeizKellerTank2/Lux/Helligkeit", "write": true, "read": true, "role": "variable", "desc": "mqtt server variable", "type": "string" }, "native": { "topic": "HeizKellerTank2/Lux/Helligkeit" }, "type": "state", "from": "system.adapter.mqtt.0", "user": "system.user.admin", "ts": 1629315610961, "_id": "mqtt.0.HeizKellerTank2.Lux.Helligkeit", "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }Die Log Einträge starten dazu für mich ohne Grund heute um 06:37h.
-
gerade nochmal die DPs gelöscht und nachdem Adapterstart sehe ich zum ersten mal das im Log:
2021-08-19 09:27:08.239 - info: mqtt.0 (12701) Changed type of "mqtt.0.HeizKellerTank2.Lux.Lux" from "string" to "number" 2021-08-19 09:27:08.370 - info: mqtt.0 (12701) Changed type of "mqtt.0.HeizKellerTank2.Lux.Helligkeit" from "string" to "number" -
Moin,
Ich habe Fehlermeldungen beim Homatic Adapter
hmip.0 2021-08-19 09:39:40.236 info State value to set for "hmip.0.devices.3014F711A0001118A995181C.channels.1.endpositionAutoDetectionEnabled" has to be type "string" but received type "boolean" hmip.0 2021-08-19 09:39:40.233 info State value to set for "hmip.0.devices.3014F711A0001118A995181C.channels.1.processing" has to be type "string" but received type "boolean" javascript.0 2021-08-19 09:39:38.561 info script.js.10:_Beleuchtung.14:_All_in_One_3: 1870 hmip.0 2021-08-19 09:39:38.516 info State value to set for "hmip.0.devices.3014F711A0001118A9950BEB.channels.1.endpositionAutoDetectionEnabled" has to be type "string" but received type "boolean" hmip.0 2021-08-19 09:39:38.511 info State value to set for "hmip.0.devices.3014F711A0001118A9950BEB.channels.1.processing" has to be type "string" but received type "boolean"reichen die als Info ?
Ich kann noch mehr liefern.^^mfg
-
@pete0815 Was ist denn der Inhalt nachts? Nicht das das mqtt ding Nachts eine 0 als Zahl sendet und tagsüber Werteals String?
-
@digi-bit GitHub Issue bei hmip bitte anlegen. Die kann ich alle nur fixen wenn ich Sie kenne
-
@apollon77
Das ist ein Helligkeitssensor (BH1750FVI) an einem ESP8266. Nachts sendet er sicher eine 0. Bei den Datentypen bin ich völlig ahnungslos. Dachte Mqtt ist immer string und ob sogar ein Client dies ändern kann, überrascht mich völlig.Bitte gebt einen Hinweis, wenn das nicht jS3.3 "Baustelle" ist sondern zB Mqtt-Adapter oder sogar der Client "vermurkst". Hatte heute morgen den IOBroker auch neu gestartet. Im Moment steht der type beider DPs =number und es gibt keine Meldungen im Log. Die Inhalte sind derzeit auch ungleich 0.
-
@pete0815 Mach History Adapter an für den Datenpunkt und logge mit.dann siehst Du was er drin hat. Oder ein kleines JavaScript was den Datenpunkt loggt ...
-
@apollon77 said in Meldungen seit controller v3.3 zu falschem Datentyp:
@pete0815 Mach History Adapter an für den Datenpunkt und logge mit.dann siehst Du was er drin hat. Oder ein kleines JavaScript was den Datenpunkt loggt ...
Ok. Nutze bisher kein history nur sql und influxDB, aber habe es jetzt mal dafür eingeschaltet. Was soll dies prüfen? Der Datentyp wird nicht mit aufgezeichnet, oder? In sql/influxDB lege ich den einmal fest und Änderungen würden wohl Fehler ergeben. Oder geht es um den zeitlichen Verlauf der Werte? Das ist einfach auch so abzuleiten, wie gesagt Helligkeitssensor Draußen, also Sonnenaufgang/untergang Goldene Stunde etc. geben dazu Aufschluß.
Edit: Gerade in den Log geschaut und seit 20:49h kommt wieder:
mqtt.0 2021-08-19 20:49:46.102 info State value to set for "mqtt.0.HeizKellerTank2.Lux.Helligkeit" has to be type "number" but received type "string"Aktueller Wert (20:59h) ist aber noch 3,4Lux also die Null/0 kann es nicht alleine sein.
Was mir jedoch auffällt ist der Unterschied in der Darstellung (Helligkeit immer Zweistellig mit Null davor und Komma und Punkt):
Schaue ich mir die Konfiguration der Datenpunkte an, dann ist type=number
-
@pete0815 sagte: Unterschied in der Darstellung (Helligkeit immer Zweistellig mit Null davor und Komma und Punkt)
Führende 0 und Komma können beide nur Strings sein.
Vermutlich wandelt der MQTT-Adapter nach Zahl, wenn er kann. Diese Strings kann er aber nicht wandeln. -
@paul53 Das klingt sehr plausibel. Daher: Warum sendet das Gerät das so komisch?
-
@paul53 said in Meldungen seit controller v3.3 zu falschem Datentyp:
@pete0815 sagte: Unterschied in der Darstellung (Helligkeit immer Zweistellig mit Null davor und Komma und Punkt)
Führende 0 und Komma können beide nur Strings sein.
Vermutlich wandelt der MQTT-Adapter nach Zahl, wenn er kann. Diese Strings kann er aber nicht wandeln.Danke, ich glaube langsam fällt der Groschen und natürlich wieder Hausgemachter Murks von mir.
Im Log taucht ja nur die Warmeldung zum DP Helligkeit auf.
Der DP Lux kommt zwar vom gleichen Client ist aber ein automatisch übermittelter Wert aus der Messung.
Der DP Helligkeit ist von mir durch einen Softwarefilter geschickt um träger auf Wolken etc. zu reagieren und wird per manuellem Befehl per Mqtt geschickt. Dabei wird auch festgelegt wie der Datenpunkt formatiert werden soll. Ich wollte nur eine Nachkommastelle festlegen und dabei heraus gekommen ist auch eine zweistellige Zahl zur Not mit führender 0.
Dies scheint dann bei der Automatischen Konvertierung zum Problem zu werden sobald die 0 führt also Werte <10Lux übertragen werden. Ich habe nun nur noch die Nackommastellen definiert und muß abwarten, da die Messung inzwischen nur noch 0 ergibt.Vielen Dank für Eure Unterstützung und sorry für meinen Murks!
-
@apollon77 said in Meldungen seit controller v3.3 zu falschem Datentyp:
@glasfaser Wir verschieben die instalator Adapter gerade und kommen morgen wieder ins Repo ... ALso botte issues einfach par stunden später anlegen bitte
Hallöchen zusammen,
ich musste, aufgrund eines Stromausfalles und einer daraufhin verreckten iobroker Installation, alles wieder neu aufsetzen, was aufgrund BackItUp sehr gut funktioniert hat (bin noch Neuling in der iobroker- Welt). Nur mit dem Kodi Adapter hat die Installation nicht geklappt. Ich habe versucht den Adapter ganz normal über die Adapterseite zu installieren (iobroker läuft mit dem Image von der iobroker Seite auf einem Raspi 4).Als Fehlermeldung kommt folgendes:
npm ERR! code E404 npm ERR! 404 Not Found - GET https://github.com/instalator/kodi-ws/tarball/master/ npm ERR! 404 npm ERR! 404 'kodi-ws@https://github.com/instalator/kodi-ws/tarball/master/' is not in the npm registry.npm ERR! 404 You should bug the author to publish it (or use the name yourself!)npm ERR! 404 It was specified as a dependency of 'iobroker.kodi'npm ERR! 404 npm ERR! 404 Note that you can also install from anpm ERR! 404 tarball, folder, http url, or git url. npm ERR! A complete log of this run can be found in:npm ERR! /home/iobroker/.npm/_logs/2021-08-23T10_36_02_654Z-debug.log ERROR: host.iobroker-pi Cannot install iobroker.kodi@2.0.5: 1 ERROR: process exited with code 252021-08-23T10_36_02_654Z-debug.log
Ich habe ja oben schon gelesen, dass das Repo gelöscht wurde und Ihr das in der Community wiederherstellen wolltet. Habe ich hier was falsch gemacht oder kann ich was machen, damit die Inst. funktioniert?
Gruß,
Richy
