Jedenfalls bekommst du unterm Shelly Adapter keine eigenen Topics integriert.
Hallo
So etwas hatte ich mir schon gedacht.
Mittlerweile habe ich auch schon einiges versucht und hatte das vermutet, da alle auch ungewöhnliche Sachen nicht funktioniert haben.
Schade aber dann muss ich eben den Normalen MQTT nehmen, funktioniert ja.
Den Aufwand andere Leute für mein kleines Problem zu beschäftigen ist es nicht wert, wenn das nicht ginge schon aber so nein.
DANKE und Grüße aus dem Sauerland
der Shelly Pro Dimmer 2PM wird seit Version 7.0.0 Shelly Adapter unterstützt.
Ich verstehe aber auch nicht so ganz was du mit einem Script für einen I4 auf dem Dimmer machst?
Der 2PM läuft ja auch mit dem IOB.
Es ist das Script das auf Tastendruck einen Datenpunkt im ioB hochzählt und der Counter lässt sich vom ioB auch verändern.
Mit dem Tastendruck steuere ich meine Aussenbeleuchtung.
1xTasten Lampe ein und nach 5min. wieder aus. Ein Weiterer Tastendrucksteuert die Lampe auf Dauer ein. wenn nmoch mal betätigt wird geht die Lampe wieder aus.
Das macht ein Script im ioB der 2PM fragt nur den Tastendruck ab denn für so etwas ist die Latenzzeit zwischen 2PM und ioB zu hoch.
Das Script läuft ja auch mit dem ioB-MQTT die topics werden als Datenpunkte dargestellt und lassen sich verändern sowol vom ioB wie auch von 2PM.
Binde ich den 2PM unter den Shelly-MQTT ein, so sind die Datenpunkte nicht zu sehen.
Das Script läuft aber sauber durch.
Was muss verändert werden damit die Toppics auch unter Shelly-MQTT auftauchen.
Der Script war für 2xI4 und 5xDimmer2 gescgrieben. ich möchte den auf die Pro umdupsen dann habe ich weniger Geräte und eine bessere Übersicht und Platzausnutzung.
Ich habe hier wahrscheinlich ein Verstäntniss Problem.
Bei einem "ProDimmer2PM" möchte ich die Anmbindung an den ioBroker über Shelly-MQTT machen.
Auf dem 2PM läuft ein Scripte :
// Script für den SHELLY i4 Taster-Anschluss
// Tastendruck SW1-SW4 auswerten 0-2 und diese dem MQTT übergeben
// Zählerbeeinflussung vom MQTT den Tastenzählern zuweisen
// --------------------------------------------------------------
//Variabeln deffinieren
let CONFIG = {
device_id: "",
device_mac: "",
device_model: "",
fw_ver: "",
topic_prefix: "",
wifi_ip: "",
};
let Taste = [0,0,0,0]; //Tate SW1 - SW4
let T_Name = ["Nr:1","Nr:2","Nr:3","Nr:4"]; //Name der Taste im MQTT
function isConfigReady() {
for (let key in CONFIG) {
if (CONFIG[key] === "") return false;
}
return true;
}
Shelly.call("Shelly.GetDeviceInfo", null, function (info) {
CONFIG.device_id = info.id;
CONFIG.device_mac = info.mac;
CONFIG.device_model = info.model;
CONFIG.fw_ver = info.fw_id;
});
//Read ip from status
Shelly.call("WiFi.GetStatus", null, function (status) {
if (status.status === "got ip") {
CONFIG.wifi_ip = status.sta_ip;
}
});
//Monitor ip changes
Shelly.addStatusHandler(function (status) {
if (status.component === "wifi" && status.delta.status === "got ip") {
CONFIG.wifi_ip = status.delta.sta_ip;
}
});
//Read mqtt topic prefix
Shelly.call("MQTT.GetConfig", null, function (config) {
CONFIG.topic_prefix = config.topic_prefix;
});
// Eingänge abfragen und Tastendruck von 0 - 2 zählen
Shelly.addEventHandler
(
function (event)
// Event aktivieren
{
if(event.name==="input" && event.info.state === true)
{
let id = event.info.id; //id = Welcher Eingang
if (id > -1 && id < 4) //SW1 - SW3
{
Taste[id] = Taste[id] + 1;
if (Taste[id] === 3)
{
Taste[id] = 0;
}
print(CONFIG.topic_prefix,"/Taste/",T_Name[id],JSON.stringify(Taste[id]));
MQTT.publish(CONFIG.topic_prefix + "/Taste/"+T_Name[id], JSON.stringify(Taste[id]));
}
}
}
)
// Announcen die MQTT ankommen bearbeiten
function announceHandler(topic, message)
{
let kanal = 0;
//print("topic = ",topic," message = ",message);
kanal = JSON.parse(topic.slice(topic.length - 1,topic.length)) -1;
if (message !== "0" && message !== "1" && message !== "2") return;
Taste[kanal] = JSON.parse(message);
MQTT.publish(CONFIG.topic_prefix + "/Taste/"+T_Name[kanal], message);
}
// Announcen im MQTT anmelden
function subscribeToTopics()
{
MQTT.subscribe(CONFIG.topic_prefix + "/Taste/command_Nr_1", announceHandler);
MQTT.subscribe(CONFIG.topic_prefix + "/Taste/command_Nr_2", announceHandler);
MQTT.subscribe(CONFIG.topic_prefix + "/Taste/command_Nr_3", announceHandler);
MQTT.subscribe(CONFIG.topic_prefix + "/Taste/command_Nr_4", announceHandler);
}
//Start a timer that checks if all fields in CONFIG are populated
let configReadyTimer;
function connectToMQTT() {
configReadyTimer = Timer.set(3000, true, function () {
if (!isConfigReady()) return;
if (!MQTT.isConnected()) return;
subscribeToTopics();
Timer.clear(configReadyTimer);
});
}
connectToMQTT();
MQTT.setDisconnectHandler(function () {
connectToMQTT();
});Das Scripte funktioniert auch wenn ich den 2PM mittels "ioBroker MQTT" einbinde (Also über Port 1883)
Mache ich das Gleiche über den Shellyadapter-MQTT (Port 1882) so kann ich Datenpunkte nicht sehen.
Geht das gar nicht oder muss ich da am Script etwas verändern ?
mfG F.B.
Ich habe bisher nur von Bremsen gehört. Aber wo keine Bremsen drin sind, können keine versagen, da hört man dann auch nichts von.
Das mit den Bremsen hat mir nun keine Ruhe gelassen.
Mein Stöbern im Internet brachte zu Tage das die Meisten Bremsen verbaut haben wie z.B hier bei Becker zu sehen.
Aber das ist nicht überall so.
Beim Becker ist ein Planetengetriebe verbaut und das ist nur unter bestimmten Bedingungen selbsthemend/selbstbremsend.
Somit könnte das sein.
Die bei denen das Problem existiert sind Jarolift oder Homepilot (Was ich damals verbaut habe weis ich nicht mehr genau).
Die beiden haben Planetengetriebe.
Ich werde mal die Shelly raus bauen und Fibaro wieder rein, mal sehen ob das Problem weiterhin besteht.
Ein Hoher Anlaufstrom ist bei den Rohrmotoren auf alle Fälle zu erwarten denn Masse muss wert mal beschleunigt werden und das bedarf Energie.
Grüße Frank
Du meinst ja Abschaltung, denke ich. Nur nebenbei gefragt. Wenn irgend eine vermutete Störung einen Impuls zum abfallen eines Relais führen sollte, wieso nicht zum Einschalten des zweiten Relais?
Wie alt sind die Motore? Sind es alle, oder immer die gleichen mit dem Problem. Was, wenn die Bremsen Probleme machen?
Natürlich abschalten.
Welches Relais ein aus usw. schaltet kann man von Aussen nicht sagen.
Die Motoren sind ca.20 Jahre alt.
Sie haben vorher mit Fibaro FGR-223 störungsfrei gelaufen.
Nach dem ich von z-Wave auf Shelly umgestiegen bin, begannen die Probleme.
Das mit den Bremsen kann ich nicht sagen aber das könnte natürlich sein.
Sind da bei allen Bremsen verbaut oder selbsthemmende Getriebe?
Das Problem tritt auch bei 2 Neu eingebauten Rademacher-Antrieben auf.
Gibt es da einen Parameter der den Anlauf überbrückt?
Die "Obstacle detection" währe eine Erklärung gewesen aber die habe ich deaktiviert.
Die Taster sind nicht zufällig hinter den Shellys angeschlossen?
Nein, der ist wie vorgegeben angeschlossen.
Anschlussfahler kannst du definitiv ausschließen.
Die laufen ja auch zu 80% störungsfrei nur ab und an tritt der Fehler auf.
Hast du eventuell bei "Obstacle detection" einen (zu kleinen) Wert eingetragen?
Nein, das war auch meine Vermutung zuerst, habe es dann rausgenommen.
Ich vermute eine Beeinflussung durch Spannungsspitzen.
Ein VDR verringert den Einschaltstrom nicht. Das macht ein NTC-Widerstand (Einschaltstrombegrenzer).
Oh Sch.. natürlich NTC hatte ich verbaselt meinte ich aber.
Ich habe mal nachgesehen, Ihr meintet der "2PM" würde neu Booten, aber das ist es nicht, grade habe ich es noch mal versucht und danach stand der Uptime immer noch auf : 5984446Sec.
Der scheint also nicht neu zu booten.
Meinst du eine RC würde das Problem verringern ?
Das würde dann aber nicht den Rush (Anlaufstrom) verringern sondern nur den Kontakt besser schützen.
Was vermutest du denn als Ursache ?
Ich hatte schon mal an einen VDR zwischen den N-Netz zu N-2PN Anschluss gedacht, das würde den Anlaufstrom verringern.
Könnte aber die Callibrierung stören.
Ich habe hier mehrere Shelly Plus 2PM verbaut mit Herkömmlichen Rolladentastern.
Die Rolladenmotoren haben Elektromische Endanschalter und schalten somit selbstständig aus.
Auf den 2PM ist die Firmware 1.4.4 und gesteuert werden die mit ioBroker über Shelly-Instanz.
Normalerweise laufen die auch einwandfrei nur ab und an fahren sie nicht rauf oder fahren nicht runter (Programmgesteuert).
Versuche ich die betreffende Rollade per Hand zu steuern, so höhre ich das Relais anziehen und die Rollade zuckt kurtz.
Nach einigen Versuchen per Taster (mit Wartezeit zwischen den Versuchen)funktionieren die dann auf ein mal wieder.
Ich vermute das der Einschaltrush der Motoren zu einer Anschaltung führt (Kann man da einen Fehler sehen oder bekommt man da eine Meldung).
Wo kann ich dieses Verhindern oder muss ich das per z.B. VDR verhindern (Was Probleme bei der Callibrierung erzeugen könnte)?
Error
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
Hallo
Ist das die 2.2.4 Version die den Fehler erzeugt?
Was genau macht die und was nicht, lohnt es sich von 2.1.8 auf die 2.2.4 zu wechseln?
Die 2.1.8 ist die, Die bei mir funktioniert und Alle Anderen waren ein Desaster.
Etwas mehr als das "Error" und "Reboot Befehl fehlgeschlagen" währen sehr Nett.
mfg
F.B.
Meine 8 Stück laufen seit März.2024 mit der FW2.1.8 wieder wie gewohnt ohne Probleme und seit dem habe ich noch keine Akku laden müssen.
Alle Akku8s sind noch auf 99%.
Alle Neueren FW machten teils Große Probleme, Erreichbarkeit, ausfälle (nur mit Reset behebbar), Akku innerhalb einiger Tage unter 70% (Danach keine Funktion mehr) usw.
Das alles kannst du Hier nachlesen, ich war da kein Einzelfall.
In den Wichtigen Räumen habe ich die TRV raus geworfen und durch BOSCH (zigbee) ersetzt, währe nach jetzigem Stand gar nicht nötig gewesen aber der WAF bestand darauf nach dem das Badezimmer einmal kalt war und ich nicht da war um zu helfen.
Ich hoffe du hast da bessere Ergebnisse als ich. Berichte mal ob das bei dir läuft.
Möglich das es an meinem Netz liegt, Fritz 7490AX mit 1200AX Repeatern (Alle am Kabel hängend).
Grüße aus dem Sauerland
Hi Berges,
erstmal schön, dass s klappt bei dir mit den Werten aus MQTT!
Ich steuere bei meinen TRVs nicht die Taget-Temperatur, sondern gleich die Ventilposition auf diesem Topic:
Hallo Martin
Ja funktioniert hatte das.
Mittlerweile bin ich wieder auf Firmware 2.1.8 da die höheren Versionen immer abgestürzt sind.
Langfristig werde ich die Dinger raus werfen, ich habe auch noch Anderes zu tun als mich mit den Shelly TRV zu beschäftigen.
Meine 24 Thermostate laufen jetzt schon seit einiger Zeit zu 50% mit "Bosch SmartHome Thermostat II" über zigbee3.0 das funktioniert Prima, selbst das Steuern über externen Temperaturgeber war überhaupt kein Problem.
Meine Odysse begann mit Devolo (z-Wave) ging weiter mit Eurothronic Spirit (z-Wave) dann Shelly TRV und das Ende könnte Bosch Thermostat II sein.
Alle die Vorherigen Geräte hatten Macken, regelten miserabel oder haben das Netzwerk gestört.
Bis Dato habe ich so viel Zeit und Geld in die Buggy Geräte Investiert das ich kotz...... könnte.
Ich habe hier einiges am laufen > 250 SmartHome Geräte "z-Wave", "Zigbee 3.0" oder "Wlan" (Shelly oder ESP32 Eigenbau) nur die Thermostate zickten rum.
Grüße Frank
ich nutze keinen ioBroker, sondern nur node-red als Steuersystem.
So sieht der Teil vom flow aus:
Hallo Martner
Jetzt habe ich Heute mal den einen TRV vom Shelly-MQTT auf den ioBroker-MQTT zurück gestellt.
Da kommt jetzt der Info wie bei dir. auch ich drösel da alles raus was ich haben möchte.
Nur mit dem Setzen der Temperatur habe ich keinen Erfolg.
Wenn ich den command so beschreibe {"target_t": 20} passiert nichts.
Das müsste nach allem was ich gelesen habe so eigentlich richtig sein ?!
Die Dinger sind aber auch Problematisch (um es mal vorsichtig zu formulieren) , alles Andere läuft bei mir.
Aber 9 Stück in die Tonne hauen dazu bin ich zu geizig.
Ich frage für das ram_free nicht regelmässig den Status ab, sondern hole mir den Wert aus den mqtt-Meldungen, die der TRV ja ohnehin schickt.
Hallo Martin
Das ist Interessant, welches Objekt im ioBroker beinhaltet den das Json ?
Ich habe mir jetzt mal alle angesehen und finde da nichts.
Möglicherweise bin ich aber da etwas Blind.
Ich benutze den Shelly MQTT.
Wie machst du das ?
Das würde "das" Problem lösen oder verringern.
So hatte ich das in Prinzip abgefragt (nur der Endscheidende Part).
Am 7.3.2024 habe ich meine 9 TRV auf 2.2.3 am laufen.
Ich steuere alles über MQTT.
Alle TRV laufen nur als Regel-/Stellglieder, also minimale TRV Funktionen.
Bis jetzt sind alle bei 99% Batterie und auch die Abstürze sind weg.
Die von martner erwähnten ram_free Probleme konnte ich noch nicht feststellen.
Ich hoffe das die Version jetzt bei mir das Ende aller Probleme bedeutet.
Hoffentlich gilt das auch für die Anderen die Die TRV im Einsatz haben.
Was mir bei all dem aufgefallen ist, wenn ich zu viel und zu schnell hintereinander "/status" Abfragen sende, so kommt der TRV aus dem Tackt und er verstellt z.B den Sollwert von vorher 19 auf 24°C.
Ob sich noch andere Sachen verstellen ?
Wenn ich das gesehen habe, habe ich den TRV rebootet, kallibriert und neue Temperatur vorgegeben.
Das konnte ich bei meinem Rumprobieren einige Male feststellen jedoch nicht immer sondern nur ab und an mal.
Ich habe meine Routine (Status abfrage und wenn ram_free unter 20000 dann /reboot) deaktiviert um dieses Problem nicht zu bekommen.
Ein Möglicher Fehler währe hier ein Input-.Buffer overflow.
Ich auch, das Update hat ohne Probleme funktioniert.
Verbesserungen ?
Was soll sich den geändert haben ?
aragorn kannst du es bitte erklären. §933a ABGB ist wie es scheint ja österreichisches Recht, wo die Gewährleistung 10 Jahre beträgt.
Da habe ich mich vertag, ich habe da etwas durcheinander gebracht !
Das ist Östereichisches Baurecht !
Hier in Deutschland sieht es so aus :
http://www.bmj.de/DE/themen/kauf…ekauf_node.html
Ich bin aber kein Jurist und somit hoffe ich das Das jetzt richtig ist.
Unternehmen und Moral sind ein Antonym
Na ja aber da haben wir noch den § 933a ABGB ob der greift ?
Aber erst mal hoffen.
Das der Momentane TRV so seine Probleme hat, ist ja bekannt.
Das es einen Neuen geben wird 3Q/2024 ist Interessant.
Kann eigentlich nur Besser werden.
Toll währe es wenn man die Alten (Bei mit 9 Stück) umrüsten könnte.
Die Dinger öffnen und die Platine tauschen ist zwar etwas knifflig aber machbar.
Wenn einer Kontakt zu den Leuten hat, könnte man ja mal das anregen.
Da die "Alten" Geräte Macken haben sind sie eigentlich zumindest Moralisch in der Pflicht.
