Hallo zusammen
Die neueste Version von OpenDtu führt wohl Änderungen an der API ein, so dass der Adapter nicht mehr alle Daten abholen kann
Ich habe das an „yield day“ bemerkt
Leider half bisher auch die Rückkehr zur Version 24.1.26 nicht (mit der funktionierte es vorher noch)
Edit: mit der alten Version geht es wieder....
Ich hab auch ein GitHub issue dazu erstellt…
https://github.com/o0shojo0o/ioBroker.opendtu/issues/129
@dasbo1975 evtl. ist das ein verwandtes Problem, d.h. es würde prinzipiell erst mit der nächsten Version gehen. https://forum.iobroker.net/topic/68694/temperaturwert-in-iot-adapter-alexa-geräte/14
@IdleBit
ich sehe im Log eine Warn-meldung, die vermutlich fehlerhaft ist:
State value to set for "opendtu.0.112483748174.power_control.current_limit_absolute" has value "-1" less than min "0"
Mein Inverter steht auf "100%", insofern ist da -1 vermutlich richtig. (das ist auch noch der default)
update: nach firmware update auf 23.7.22 kommen da richtige Werte.... lag wohl an meinem Modell das erst jetzt unterstützt wird (HMS-400)
@da_woody hab nun auch gefunden, was das Problem für den MQTT Explorer und andere Analyse Tools zu sein scheint: der Shelly adapter gleicht den Client mit den eingetragenen Shelly’s ab und lässt den Explorer daher nicht rein…
@lemonbiter
Ich habe sehr gute Erfahrungen mit diesem Taster gemacht (nicht billig aber eben ohne Batterie)
GIRA + Senic Friends of Hue Smart Switch | Kompatibel mit Philips Hue & Tado | Made in Germany | Kabelloser Homekit Lichtschalter & Dimmer | Keine Batterien, kein Aufladen | 1x Schalter in Weiß
https://amzn.eu/cCtnnFl
Dem Shelly würde ich auf Tastendruck eine konkrete Position durchgeben… also ein minimal blockly: wenn State = True steuere Shelly Position xx
Dem Shelly bei Tastendruck einfach „auf“ oder „ab“ sagen geht aber auch.
Vermutlich braucht man nicht mal ein blockly sondern kann die je zwei states per Regel verbinden….
@thomas-braun noch funktioniert diese Einstellung leider nicht so richtig: https://github.com/tbnobody/OpenDTU/issues/1397 wir testen noch ob die neueste Änderung nun wirkt. 
@garfonso ich habe den zweiten alias-DP auf "detected" ergänzt, weil ich den ursprünglichen noch in scripts verwende und daher noch nicht ändern wollte.
und ansonsten sieht es so aus: (ich verwende den alias-manager)
auch wenn ich einen mit "flood" (für diese Regex des devices modul "/^state(.alarm)?.flood$｜^sensor(.alarm)?.flood/") ergänze klappt es nicht
und ich habe noch weiter probiert:
so sieht das aus, wenn der devices-adapter den alias anlegt:
was dabei auffällt ist, dass typ und icon nicht zusammenpassen...
der alias selber ist auch leicht anders:
und anscheinend hat die role des channels was damit zu tun:
sieht für mich aus wie mehrere Bugs....
Nachtrag:
wenn man sich Zeile 572 von https://github.com/ioBroker/ioBroker.type-detector/blob/master/index.js ansieht wird das klar.
@Bluefox warum wird denn für den Feuer- und Wasser-Alarm der Channel zusätzlich geprüft, und dann noch auf "sensor.alarm.flood" statt auf "floodalarm"?
siehe: https://github.com/ioBroker/ioBroker.type-detector/issues/38
warum das Icon nicht richtig ist und ich so viele ACTUALS sehe, wären dann wohl zwei andere Bugs...
@ollimaloche den total.yieldday kenne ich, aber den meine ich nicht. der ac.phase_1.yieldday und yieldtotal wird nicht mehr aktualisiert seit der 24.2.12
@homoran weil es nicht das erste mal wäre, dass eine Firma ihre Geschäftsinteressen ändert und einer auf ihrer ursprünglichen Strategie aufgebauten Open-Source-Community den Boden unter den Füssen weg zieht. (z.B. Oracle oder RedHat haben da ja schon Beispiele geliefert)
Ich denke, man kann man sich da schon mal fragen, ob und welche Risiken bestehen, wenn solche Posts wie der oben verlinkte auftauchen...
@mico ich empfehle den erstmal ins wlan zu hängen und die 1.7 Firmware drauf zu machen
Ich glaub die ist zwar noch Beta funktioniert aber viel besser für Zigbee als die 1.6.2
Z.b kann man damit das pairing per Web gui machen
Und soweit ich mich erinnere ging auch der Switch zu zigbee damit per Web gui
Ps
Bei mir ging dann Zigbee2mqtt erst nach Anpassung des converter files weil die Model Nummer nicht gepasst hat
@delphinis die Shelly sind anscheinend keine besonders guten Router.... 
ich sehe kein Gerät das darüber verbinden würde.
und ich bin da auch anscheinend nicht der Einzige: https://github.com/ioBroker/ioBroker.zigbee/issues/2525
@delphinis ich mit Hue Lampen gute Erfahrung als Router gemacht
Aktuell probiere ich aus ob die Shelly 1pm 4gen auch gute Zigbee Router sind…
@falke69 dastranskribieren abschalten kann man auch:
einfach in der Zeile 61
aus
const transcribe = true;
const transcribe = false;
machen....
vielleicht mache ich auch später noch eine Version bei der man das mit einem button in einem datenpunkt ein und ausschalten kann.... mal sehen...
EDIT: neue version damit hochgeladen.
aber eigentlich sollte das Erzeugen einer Ressource und deren Keys im Portal von Azure über den Link, den ich in der Anleitung angegeben habe, nicht so schwer sein:
https://portal.azure.com/#view/Microsoft_Azure_ProjectOxford/CognitiveServicesHub/~/SpeechServices
Man muss ein Abonement anlegen und dann darin die Ressource erstellen, dann kann man den Key abrufen.
@falke69 du musst da natürlich deinen eigenen Azure Key einsetzen. anscheinend hast du vorher eine version erwischt, in der ich versehentlich meinen key nicht gelöscht hatte....
und ja, ich muss die fehlermeldung für diesen Fall besser machen. so ist da deine ganze audio datei drin....
EDIT:
neue Version mit besserem logging hochgeladen
@beowolf wenn die Einstellungsübernahme noch aktiv ist, dürfte es mittels der SOAP Commandos / Actions über den tr64 Adapter an die Box gehen, wenn nicht bleibt vermutlich nur, per script direkt mit dem Repeater zu sprechen. Das ist mit SOAP dann aber etwas kniffliger, wenn man nicht zufällig einen entsprechenden .lua einstieg in diese Konfiguration findet...
@falke69 habe eine neue Version hoch geladen, die einen neuen Datenpunkt auf macht, in dem dann der lokale Pfad zur Wav Datei steht. im Blockly kann man darauf zugreifen und das file versenden.....
@falke69 sieht eigentlich alles richtig aus. du bekommst als transkript der nachricht tatsächlich "The." zurück. Was sollte das denn sein? und welche Sprache wird da üblicherweise drauf gesprochen?
nimm mal die neue version, die ich gerade hochgeladen habe, die ist etwas robuster und gibt mehr mitteilungen im debug mode.
@falke69 ja, da sollte das Transkript drin sein (nicht das audio file), aber auch nur, wenn der Call zu Azure cognitive services funktioniert hat. was sagt denn das javascript log?
@falke69 senden des audio wav files per email geht.... telegram habe ich nicht. aber vermutlich muss man da auch nur den pfad an der richtigen Stelle im Aufruf einsetzen.
per email ist das so:
sendTo('email.1', 'send', { text: 'Neue AB Nachricht im Anhang', to: 'test@test.de', subject: 'Neue AB Nachricht',
attachments:[ { path: tempFilePath, cid: 'message.wav' },],} );
EDIT:
scheint ziemlich leicht zu sein, die Wav auch per telegram zu senden, wenn man die o.e. Zeilen gegen die folgenden tauscht:
sendTo('telegram.0', 'send', {
text: tempFilePath,
caption: 'Neue AB Nachricht',
user: 'yourUserName1,yourUserName2',
});
https://github.com/iobroker-community-adapters/ioBroker.telegram/blob/master/docs/en/README.md#usage
aber wie gesagt, Telegram hab ich nicht....
EDIT 2 :
das sendTranscipt.js ist eigentlich ein eher simples blockly....
das müsstest du mit dem telegram-blockly leicht ergänzen können:
https://github.com/chris299/IOBrokerFritzboxTAMHandling/blob/main/sendTranskript_blockly.xml
