NEWS

@oliverio said in Test Adapter mytime:

Da Countdown-Timers ja durch beschreiben von Datenpunkten anpassbar sind und

Ich laufe beim Anlegen eines Countdown und klicken auf den SetDP Button auf Probleme. Ich lege einen Namen an und setze die Stunde auf 1.

mytime.0 2025-01-22 20:27:10.268 info starting. Version 1.4.0 in /opt/iobroker/node_modules/iobroker.mytime, node: v20.18.1, js-controller: 7.0.6 host.iobroker 2025-01-22 20:27:09.591 info instance system.adapter.mytime.0 in version "1.4.0" started with pid 1612894 host.iobroker 2025-01-22 20:26:39.267 info Restart adapter system.adapter.mytime.0 because enabled host.iobroker 2025-01-22 20:26:39.266 error instance system.adapter.mytime.0 terminated with code 6 (UNCAUGHT_EXCEPTION) mytime.0 2025-01-22 20:26:38.728 warn Terminated (UNCAUGHT_EXCEPTION): Without reason mytime.0 2025-01-22 20:26:38.727 info terminating mytime.0 2025-01-22 20:26:38.726 info cleaned everything up... mytime.0 2025-01-22 20:26:38.718 error Cannot set properties of undefined (setting 'config') mytime.0 2025-01-22 20:26:38.717 error TypeError: Cannot set properties of undefined (setting 'config') at mytimeCountdown.setCountdownConfigMsg (/opt/iobroker/node_modules/iobroker.mytime/lib/mytimeCountdown.js:588:46) at mytimeCountdown.processMessages (/opt/iobroker/node_modules/iobroker.mytime/lib/mytimeCountdown.js:566:18) at mytimeclassNew.processMessages (/opt/iobroker/node_modules/iobroker.mytime/lib/mytimeserver.js:60:48) at Mytime.onMessage (/opt/iobroker/node_modules/iobroker.mytime/main.js:102:22) at Mytime.emit (node:events:518:28) at change (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/build/cjs/lib/adapter/adapter.js:7262:20) at Immediate.<anonymous> (file:///opt/iobroker/node_modules/@iobroker/db-states-redis/build/esm/lib/states/statesInRedisClient.js:291:37) at process.processImmediate (node:internal/timers:483:21) mytime.0 2025-01-22 20:26:38.715 error unhandled promise rejection: Cannot set properties of undefined (setting 'config') mytime.0 2025-01-22 20:26:38.714 error Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().

Nodejs-Installation:
/usr/bin/nodejs v20.18.1
/usr/bin/node v20.18.1
/usr/bin/npm 11.0.0
/usr/bin/npx 11.0.0
/usr/bin/corepack 0.29.4

ioBroker Core: js-controller 7.0.6
admin 7.4.10

@martin-g said in Test Adapter Bosch Indego:

@tombox ah ok. Wenn ich das bei der leeren weißen Seite machen muss teste ich das nachher nochmal.

Ich hab die leere Seite neu geladen und dann erst F12 gedruckt.

Danke für den Hinweis.

Also, hat mit dem Hinweis geklappt. Danke 🙂

@frederik-buss ich auch, neuen Token habe ich erstellt. Bringt aber auch nichts…

Dieser Adapter ist derzeit nicht in Repositories gelistet und seit längerem nicht aktualisisert worden. Er kann daher nur als ALPHA Status und nicht mehr supported betrachtet werden. (Falls diese Einstufung falsch ist, lieber Maintainer den Adapter bitte in dei Repos aufnehmen lassen).

Da derzeit offenbar nicht aktiv an diesem Adapter gearbeitet und getestet wird ein Info an alle Nicht-Tester / Normalnutzer:

Von direkten Installation von GitHub - insbesondere auf produktiven Systemen - wird explizit abgeraten.

GitHub Versionen können sich jederzeit (auch kurzfristig) ändern und durchaus auch in sich inkonsistent und fehlerhaft sein. Versionsangaben von GitHub Installationen sind Schall und Rauch da die Versionsnummer zumindest bei Verwendung der standardmäßigen Umgebung erst im Zuge der Releaseerstellung geändert wird.

Auf explizite Aufforderung durch den Entwickler kann eine GitHub Installation zur Fehlereingrenzung oder zum Test neuer Funktionalität - unter Inkaufnahme des erhöhten Risikos - natürlich erfolgen.

Adapter die nur via GitHub oder npm (also NICHT aus einem der beiden Repositories) installierbar sind sind mit erhöhter Vorsicht zu betrachten. Hier sollte der Entwickler drum ersucht werden eine Aufnahme in die Repositories zu veranlassen indem z.B. ein Issue im Adapterrepository erstellt wird.

Und falls es irgendwie unklar ist:

ioBroker unterstützt folgende Arten von Installation:

aus dem STABLE Repository

Das sind Adapter Releases die keine groben Fehler aufweisen (sollten). Natürlich kann es auch dort Fehler geben, die Behebung davon obliegt dem jeweiligen Dev und kann ggF auch dauern.

aus dem LATEST Repository

Das sind Adapter Releases die neu erstellt wurden und nur rudimentär getestet sind - oft auch als BETA Releases bezeichnet. Releases aus dem LATEST sind primär für unsere zahlreichen freiwilligen Tester gedacht. BETA / LATEST Releases können durchaus Fehler aufweisen - auch wenn ich davon ausgehe dass jeder aintainer dies zu vermeiden versucht. Vom Einsatz auf produktiven Systemen wird abgeraten außer man braucht irgenein neues Feature (z.B. neues Gerät) unbedingt. Hier muss dann jeder Entscheiden was ihm wichtig ist.

direkt von GITHUB

Von Installationen direkt aus Giuthub wird definitiv abgeraten außer auf Anweisung des Maintainers und für den Fall dass man gemeinsam mit diesem etwas testen will. Details siehe oben.

direkt von npm

Diese Installation kann erforderlich sein, wenn man eine bestimmte Version installieren möchte / muss. Im Normalfall sollte man direkte npm Installationen ebenso meiden wie direkte GitHub Installationen - ausgenommen um z.B. zu einer bekannten Version downzugraden - obwohl hier wenigstens ein definierter Stand garantiert ist.

Adapter die NUR via npm und/oder nur via GitHub installierbar sind sollte man meiden - diese wurden nicht mal einem rudimentären Review unterzogen und sollten mit dem Attribut "vollständig auf eigenes Risiko verwenden" installiert werden. Hier empfiehlt es sich den Developer zu ersuchen eine Aufnahme in die Repos zu veranlassen. Wenn dieser darauf nicht reagiert sollte man von einer eher kurzen und unklaren Lebensdauer des Adapters ausgehen. Support meiner-/unsererseits für solche Adapter ist mit sicherheit minimalistisch.
@mcm1957
Comment

Leave a comment

Footer

Hi @garfonso,

Entschuldige die späte Antwort, ich war beruflich eingespannt. Ich habe jetzt mal Diverses ausprobiert und es läuft mit dem Standard-Alarm-Panel wieder. Der Fehler scheint bei mir gelegen zu haben. Das Mushroom Card Alarm Panel klappt nicht, aber das kann an einer Versionsinkompatibilität liegen.

Ein anderes nerviges Verhalten habe ich aber leider feststellen müssen. Ich benutze ein paar Seiten in meinem Dashboard für smarte Schalter mit Display (NSPanel Pro). Für diese verstecke ich den Header und habe bei den entsprechenden Browser-Objekten, z.B. "lovelace.0.instances.8e7570cc-fae9c9a6" den "hideHeader" State jeweils auf true gesetzt. Bei allen anderen Browser-Objekten habe ich die entsprechenden States auf false gesetzt, ebenso den Default-Wert "lovelace.0.instances.hideHeader".

Nur leider "vergisst" Lovelace immer wieder, in den Browsern den Header zu zeigen, in denen er das soll. Ich muss teilweise mehrmals Reload drücken, bis die Headerbar angezeigt wird.

Könntest du prüfen, warum dies so ist? Es wäre wirklich toll, wenn die Anzeige des Headers zuverlässig über die States steuerbar wäre.

Viele Grüße!

@oliverio
jetzt stimmt es Danke

@lvogt, da bin ich mir jetzt nicht mehr so sicher ob es an der Durchreichung liegt. Ich muss zwar zugeben das ich von Linux keine Ahnung habe aber wenn ich das sehe, wird der Empfänger doch durchgereicht, nur mit einem anderen Namen als von mir vermutet:

usb-devices ... T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=04b4 ProdID=0003 Rev=00.00 S: Manufacturer=IMST S: Product=iU891A C: #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=200mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=01 Driver=cdc_acm I: If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm I: If#=0x2 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=05 Prot=00 Driver=(none) ... dmesg | grep tty dmesg: read kernel buffer failed: Die Operation ist nicht erlaubt iobuser@iobroker3:/$ find /sys/bus/usb/devices/usb*/ -name dev /sys/bus/usb/devices/usb1/dev /sys/bus/usb/devices/usb1/1-1/dev /sys/bus/usb/devices/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input4/event3/dev /sys/bus/usb/devices/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input4/mouse2/dev /sys/bus/usb/devices/usb1/1-1/1-1:1.0/0003:0627:0001.0001/hidraw/hidraw0/dev /sys/bus/usb/devices/usb2/2-1/2-1:1.0/ttyUSB0/tty/ttyUSB0/dev /sys/bus/usb/devices/usb2/2-1/dev /sys/bus/usb/devices/usb2/2-1/2-1:1.1/ttyUSB1/tty/ttyUSB1/dev /sys/bus/usb/devices/usb2/dev /sys/bus/usb/devices/usb2/2-2/dev /sys/bus/usb/devices/usb2/2-2/2-2:1.0/tty/ttyACM0/dev /sys/bus/usb/devices/usb3/dev

So wie ich es interpretiere könnte der Empfänger unter "ttyACM0/dev" erreichbar sein. Das wird im Adapter zwar angezeigt als verfügbare Schnittstelle aber funktioniert nicht.

Im Enocean Adapter taucht der Stick übrigens mit Namen auf.

enoceanimst.JPG

Das Durchreichen scheint also doch zu funktionieren.

Ich bin gespannt ob @wutschkooo mehr Erfolg hat.

Same here:
Ich werde heute meinen freundlichen fragen, warum Ford noch nicht im 20. Jahrhundert angekommen ist.
8eb13327-8469-4775-9dcf-1dc3affe4558-image.png

Bla, bla, bla . America first. Ford begründet das mit den Europäschen Datenschutz Gesetzen. Aber damit werben tun sie. Nur eben nicht in Europa.

7bf0a68e-861a-4661-8116-6e9d5482c4a6-image.png

02d5f3b6-47bb-4699-946c-ee445c334dd0-image.png

62ebe892-fcbb-45ce-9fa9-9e81a5152807-image.png

kann mir jemand sagen, wie ich die Netzwerkkarte dazu bewegen kann, die korrekten Informationen anzuzeigen.
Es sagt momentan, dass alle miteinander reden. Node 5 habe ich aber ausgeschaltet.
975bcf30-6b2d-4395-a734-b0b3761e163d-image.png
d23ba7c4-a4b8-4cdc-8907-7cf49869d628-image.png

@mcu das hat geklappt aber nun alles auf Node 003 unbennen geht nicht mal so geschwindt?

af6c42cb-0310-4b4c-9538-bfa70d155916-image.png

@Johan-Suck Sorry die Antwort auf deinen Post sollte eigentlich nicht stattfinden

Placeholder

Hi. Ich habe das Problem mit den Fehleranzeigen nach @Francis Anleitung erfolgreich gelöst. Vielen Dank.
Ich bekomme allerdings noch folgenden Fehler (error):

Couldn't handle 'Informationen.Ablaufzeiten' -> 'Abschaltung VD': TypeError: Cannot read properties of undefined (reading '0')

Was kann ich hier machen? Hat diesen Fehler noch jemand? Die Variable habe ich auch schon manuell angelegt, ändert aber nix. Fehler kommt scheinbar bei lesen Wertes vom Adapter.

Firmware der Alpha Innotec Wärmepumpe (LWDV91) ist V3.90.3.

@mcm1957

Haben wir ja ausdiskutiert 🙂

Ich hab das apiproblem jetzt so gelöst das ich einen State mit dem Datum des letzten erfolgreichen Datenabrufs befülle und beim Start mir den state.ts davon ansehen ob der 1 Minute länger her ist als die maximale Zykluszeit. Das andere hab ich raus genommen.

Es bleibt noch eines, das ich für stable noch lösen muß, der Adapter versucht jetzt bei erfolglosem Verbindungsversuch alle 10 Minuten daten abzurufen, das muß ich noch unterbinden für "too many api request". Aber nicht mehr heute.

2.1.0-ALPHA.0 (2025-01-19)

(ticaki) Change: min. js-controller to 6.0.11
(ticaki) Change: Outdated data is updated at startup.
(ticaki) New: Photo link added in current weather
(ticaki) New: Metric and Imperial are available for selection - Will be taken into account with the next data update.
(ticaki) New: In the event of a data retrieval error, an attempt is made again after 10 minute
(ticaki) Remove admin option (restart blocking)
(ticaki) Rewritten in Typescript

installation siehe oben

@dirkhe Ich hatte die verlinkte Erläuterung schon gesehen und nun nochmals Schritt für Schritt erneut nachvollzogen. Mit viel Sorgfalt hat es dann geklappt und ich habe eine Testverbindung aus dem Adapter heraus mit "access" quittiert bekommen.
Ich ziehe meinen Hut für das Ermitteln der beschriebenen Vorgehensweise!
Danke, da wäre ich nicht dahinter gekommen!

@peter-4

Hi peter. Ich habe auch den Controller 2. Zertifikat kann aktiviert bleiben. Das ist nur für den Fall das Bosch die Zertifikate ändert.

Erst einmal kannst du sicherstellen, dass du das richtige Passwort eingegeben hast. Dann kannst du noch sicherstellen, dass du auf den Controller Knopf einmal ganz kurz drückst. Beim Controller 1 waren es 3s jetzt nur noch einmal kurz. Anschließend sollte es funktionieren.

@mikerow Danke für deine prompte Antwort.
Leider fehlt bei uns da die Einstellmöglichkeit für (Lade-) "Geschwindigkeit". Kommt auch nichts unter "Plan bearbeiten".

Wann wurde dein 500e gebaut ? (Unserer ist aus der allerersten Serie, Zulassung in 12/2020)

Und welche Abos hast Du bei Fiat ?
Wir haben: MyCar, MyNavigation und MyRemote.
Und bei MyRemote heißt es jetzt (neuerdings ?) sogar: "Einstellung des Ladepegels"

Allerdings war es beim (teuren) Renewal des MyCar-Abos nach 3 Jahren schon ein mittleres Drama, bis endlich nur mal wieder der SoC angezeigt wurde. 😞

IMG_2345.PNG

2025-01-18_14h51_22.png

@ilovegym sagte in Test Adapter espresense:

@ticaki
investier lieber dein Dev-IQ in NSPaneladapter oder so..

Ja der Adapter - wenn das konfigurieren nicht wäre, wäre der fast fertig... war er schon letzten Jahr im März - aber keiner kann react und mit jsonconfig.json geht das echt nicht.

@marc-berg
Du hattest zwar keine Frage gestellt, ich möchte aber trotzdem antworten, einfach auch damit für diejenigen, die hier mitlesen kein falscher Eindruck entsteht, dass man auch bei der sinnvollen Nutzung des Adapters "mit JSON hantieren muss", weil das nicht stimmt.

Wenn man ein Video macht, wie ein Brief in einen Briefkasten geworfen wird, mag das als Nachweis gelten, dass der Brief verschickt wurde, aber kein Nachweis dafür, dass er empfangen wurde. Das ist nur mit Versand Nachnahme mit Rückschein möglich.

Genauso verhält es sich bei LoRaWAN, mit den im JSON eingebetteten Werten zum Versand, weil damit nur bestätigt wird, dass der Downlink erfolgreich versendet wurde. Das heisst noch lange nicht, dass er beim Gerät auch angekommen ist. Möchte man sicher sein, dass Downlink am Gerät angekommen ist, dann kann man den Downlink "mit Bestätigung" versenden. Das Gerät quittiert dann den Empfang mit einem Uplink.
978f8bbf-cfeb-43fb-ad04-c8738f3dabbd-image.png
Eine Minimierung des Akkuverbrauchs?
Als wenn man durch den Empfang von Downlinks und deren Verarbeitung keinen Akkuverbrauch hätte, im Gegenteil, durch das ständige Umkonfigurieren wird man den Akkuverbrauch mehr erhöhen, als durch Intervalländerungen einzusparen wäre.
Beste Messauflösung? Bei einer Zisterne?
Ist deine Zisterne dynamisch wie ein junges Wiesel? Intervalle von 20/15 von mir aus 10 Minuten, sollte für jeden UseCase ausreichend sein.
Du muss wissen welchen Intervall das Gerät als letztes empfangen hat?
Es wird wohl der sein, den du hingeschickt hast. Nicht nur dafür, sondern auch zur Berechnung des Flows (plus/minus Liter/Minute) setzten wir ein Script ein, welches den aktuellen Stand, mit dem vorherigen, im Verhältnis zwischen den beiden Timestamps setzt. Damit hat man den aktuellen Intervall, selbst wenn mal ein Paket verloren geht.
Außerdem:
Die Fair Use Policey von TTN besagt, dass Downlinks auf ein absolutes Minimum zu begrenzen und nur aus gutem Grund eingesetzt werden sollen. Kein guter Grund ist es die Lebensdauer einer 20€ Batterie um ein Tage verlängern zu wollen. Es gibt einen Grund warum die maximale Anzahl der Downlinks eines Geräts auf 10 DL in 24 Stunden begrenzt ist, nämlich damit alle etwas von diesem kostenfreien Netzwerk haben und nicht einzelne es benutzen, als wären sie die alleinigen Eigentümer.
Nachtrag, weil gefragt wurde:
Nein LoRaWAN ist nicht auf 10 Downlinks am Tag beschränkt, dies ist erstmal bei der Community Version von TTN in den Fair Use Policeys festgelegt und bei der "Bezahlversion" anders geregelt.
Wenn man einen eigenen LNS betreibt, wie z.B.- Chirpstack, ist man nur durch die gesetzliche Regelung begrenzt (1% Duty-Cycle und das ist bei 36 Sekunden "Sendezeit" in einer Stunde (3600 Sek.) und 60ms pro Paket im SF7 schon einiges, was da möglich ist.

@bahnuhr
Ich denke ich hab ne verlässliche Identifizierung gefunden. Die baue ich aber erst heute abend oder morgen ein. Und die Tagesschau sortiere ich dann nach datum.