Hallo,

suche eine IP Kamera:

• MUSS für die iobroker VIS und ebenso für AVM Livebildwiedergabe am DECT Telefon geeignet sein
• zus. http Stream zur Wiedergabe auf einem Enigma2 Receiver wäre top!
• kleinste Bauform
• Spannungsversorgung über 230 V oder auch über Klingeltrafo
• kein Audio nötig
• vorzugsweise für den Aussenbereich
• keine externe Cloudlösung

Bisher habe ich auch hier im Forum keine passende Lösung gefunden.
Je nach Bauforum möchte ich diese entweder Unterputz über der Klingel anbringen oder an der Türleibung so klein wie möglich an 230V anklemmen. Bei beiden Möglichkeiten sollte diese so klein wie möglich sein und dennoch Problemlos auf einer VIS vom iobroker angezeigt und am AVM DECT Telefon an einer 7590 angezeigt werden können.

Welche Lösung wäre hier zu empfehlen?

Hallo,

ich nutze einige Sonoffs und Shellys sowie ESP8266 über MQTT.
Irgendwann funktioniert aber das gesamte MQTT Netzwerk nicht mehr. Nur nach einem Neustart reagieren die Schalter wieder ordnungsgemäß.
Vorher sehe ich im Log folgende Eintrage:

tt.0	2019-08-10 22:39:58.917	info	Client [DVES_686B7B] publishOnSubscribe send all known states
mqtt.0	2019-08-10 22:39:58.917	info	Client [DVES_686B7B] subscribes on "cmnd/sonoffs/#" with regex /^mqtt\.0\.cmnd\.sonoffs\..*/
mqtt.0	2019-08-10 22:39:58.917	info	Client [DVES_686B7B] subscribes on "cmnd/sonoffs/#" with regex /^cmnd\.sonoffs\..*/
mqtt.0	2019-08-10 22:39:58.917	info	Client [DVES_686B7B] publishOnSubscribe send all known states
mqtt.0	2019-08-10 22:39:58.917	info	Client [DVES_686B7B] subscribes on "cmnd/Sonoff.Garage/#" with regex /^mqtt\.0\.cmnd\.Sonoff\.Garage\..*/
mqtt.0	2019-08-10 22:39:58.916	info	Client [DVES_686B7B] subscribes on "cmnd/Sonoff.Garage/#" with regex /^cmnd\.Sonoff\.Garage\..*/
mqtt.0	2019-08-10 22:39:58.830	info	Client [DVES_12925B] connection closed: Error: Invalid messageId
mqtt.0	2019-08-10 22:39:58.822	info	Client [DVES_686B7B] connected with secret 1565469598816_701
mqtt.0	2019-08-10 22:39:58.818	info	Client [DVES_12925B] publishOnSubscribe send all known states
mqtt.0	2019-08-10 22:39:58.818	info	Client [DVES_12925B] subscribes on "cmnd/DVES_12925B_fb/#" with regex /^mqtt\.0\.cmnd\.DVES_12925B_fb\..*/
mqtt.0	2019-08-10 22:39:58.818	info	Client [DVES_12925B] subscribes on "cmnd/DVES_12925B_fb/#" with regex /^cmnd\.DVES_12925B_fb\..*/
mqtt.0	2019-08-10 22:39:58.818	info	Client [DVES_12925B] publishOnSubscribe send all known states

Die wiederholen sich sekündlich im Loop. Kann mir jemand nen Tipp geben wo der Fehler liegt und wie ich den abstellen kann?

@da_woody sagte in Schalten und kontrollieren:

? update wird manuell gemacht!

Wenn man ab einer gewissen Anzahl von Shellys und Tasmotas im Netzwerk mit einem Update manuell "stundenlang" beschäftigt ist, nutzt man die Funktion des automatischen Updates vom Shelly Adapter gerne.

@martinp sagte in Schalten und kontrollieren:

@actionbyte Ob Geräte erreichbar sind, kann man mit dem Ping-Adapter auf Netzwerk-Ebene testen.

Hatte ich auch schon probiert, aber egal ob mit Radar/ping oder tr064 ist das Ergebnis ernüchternd, außer ich müsste den Ping-Intervall sehr kurz setzen weil die Devices manchmal nur 1-2 mal per Ping nicht antworten.
Wenn ich ausgerechnet dann Schalten möchte klappt das eben nicht.
Die Kontrolöle ob tatsächlich geschaltet wurde und es beim Fehlverusch nochmal zu probieren finde ich da eleganter.

@paul53 sagte in Schalten und kontrollieren:

"wiederhole solange" erzeugt eine Endlosschleife, die die Javascript-Instanz zum Absturz bringt. Verwende ein Intervall.

Ups, ich dachte die Pause verhindert die Endlosschleife. Aber das die nicht hilft hatte ich dann ja ebenso bemerkt.
OK ich veruche das mit dem Intervall wie @Paul53 vorgschlagen.

@actionbyte WLAN verbessern.

Ja, ist mir schon klar. Trotz 3 APs mit Lan-Brücke und einem 1 AP mit WLan Brücke verbinden sich einige ESPs/Shellys und div. andere manchmal mit dem weit entferntesten AP mit 1 Mbis/s anstatt den nächstgelegenen zu nehmen.
Ausserdem hatte ich auch schon den Fall das der ein oder andere Shelly genau dann ein FW-Update genommen hatte als ich diesen über Blockly schalten wollte.
Also kam mir die Idee mit der Kontrolle, auch wenn dies nur eine Absicherung sein kann.

Hallo,

wie kann ich ein Gerät nicht einfach nur schalten sondern danach noch kontrollieren ob Umschaltung erfolgt ist. Wenn nicht soll nach x-Sekunden erneut versucht werden zu schalten.
Wenn z.B. im schwachen WLAN Bereich ein Shelly geschaltet werden soll, dieser aber nicht reagiert, wird nur ein Fehler ausgegeben das Teilnehmer nicht erreichbar ist. Ich möchte in dem Fall solange versuchen den Shelly zu schalten bis eben die Umschaltung erfolgreich war.
Durch mein Blockly wird die Java-Instanz deaktiviert. Also nicht nachbauen, aber wie bekomme ich das hin?

@cinimod sagte in Echo Device Name mit zu langer History Aktualisierung:

Habe gerade meinen eigenen Vorschlag getestet ... geht tadellos. Natürlich kann man auch andere Geräte mit dem Raum verknüpfen, wenn man abgesehen vom "Licht" andere Geräte hat die in mehreren Räumen vorkommen.

Ich glaube das wäre ein Lösung wenn es mir "nur" um das Ansteuern von diversen Funktionen geht.
Aber ich zweifel daran das ich gezielte Antworten an den Echo senden kann von dem ich eine Anfrage an den IOB gestellt habe.
Hierzu benötige ich den Device Name, erstelle die Antwort und gebe diese über den zuvor ausgelesenen und gespeicherten DeviceName wieder aus.

@cinimod sagte in Echo Device Name mit zu langer History Aktualisierung:

EDIT: Kann bestätigen das es recht lange dauert, bis im History steht welcher Echo angesprochen wurde.

Ich denke das ist der History-Aktualisierungsintervall im Alexa Adapter.
Eigentlich sollte diese durch die aktiviert Pushverbindung kurz bzw in Echtzeit sein. Funktioniert aber bei mir mit dem History DPs unter Alexa2 nicht so wie gedacht.
Issue?

@djmarc75 sagte in Echo Device Name mit zu langer History Aktualisierung:

Rein zum Verständnis: Hast Du mit diesem DP ein Problem dass der nicht aktualisiert wird?

Ja.
Unter History wird nach dem Ansprechen von den Echos der DP "name" für EchoDeviceName erst nach längerer Wartezeit aktualisiert.
Der Umstand verhindert eine gezielte Ausgabe an den Echo von dem die Anfrage kam.

Hallo,

ich nutze in einigen Scripten den History Eintrag "Echo Device Name" im Alexa Adapter um herauszufinden zu welchem Echon gesprochen wurde um diverse Funktionen im entsprechendem Raum auszulösen. "Licht" ist nur ein Beispiel, in anderen Scripten weise ich eine erstellte Antwort dem Echo Gerät zu von dem die Anfrage gekommen ist.
Nun wurde der Aktualisierungsintervall höher gesetzt bzw. Amazon blockt User welche zu oft abfragen (so habe ich das verstanden).
Wie kann ich jetzt dennoch gezielt den DP "Echo Device Name" in den entsprechenden Scripten aktualisieren oder anders herausfinden von welchem Echo die Anfrage kam ohne Gefahr zu laufen geblockt zu werden?

@arteck Danke! Hab ich beim Einlegen der Batterie wohl übersehen.

Hallo,

ich habe ein Fyrtur Rollo über mein CC2531 am IOB ohne das Ikea Gateway anmelden können.
Nur der Tradfri Fernbedientaster E1766 meldet sich nicht wenn ich den anmelden möchte.
Hat das schon mal jemand hinbekommen?