Beiträge von Berges01

Whity

Im Normalfall nutze ich auch den Shelly-Adapter oder MQTT je nach dem.

Bei Matter wollte ich mal testen wie Gut oder Schlecht das klappt, (Objekte, Reaktionsgeschwindigkeit, Reichweite usw.) .

Dabei ist mir das aufgefallen das nur wenige brauchbare Objekte da sind.

Aber wenn ich alle Objekte frei schalte erhalte ich eine unüberschaubare Menge an Infos die ich nicht oder nur unzureichend zuordnen kann.

Gibt es eigentlich eine Info welche Werte (Rein/Raus) bei welchem Shelly per Matter übertragen werden und wofür sie Gut sind?

(Sarkasmus EIN) Was die Info betrifft scheint es wie Immer zu sein das Teil reift beim Kunden und rausfinden was geht oder nicht muss er auch. (Sarkasmus aus)

Eventuell habe ich aber auch die Richtige Infoseite noch nicht gefunden.

Hallo

Ich habe versucht den Matter Adapter im ioBroker mit einem "Shelly 1PM Gen3" zu verbinden. Nach dem ich den Shelly erfolgreich eingebunden habe, ist mir aufgefallen das die Werte Spannung, Strom, Frequenz usw. nich angezeigt werden. Schaut hier:

Liegt es daran, das Shelly oder das der ioBroker das "Problem" ist?

Nebenbei es sind nach Freigabe von Anderen Daten noch wesentlich mehr Objekte da, diese sind aber für den Normalen Betrieb Irrelevant und werden nur bei Bedarf angezeigt.

Im ioBroker Forum wurde vermutet das Das noch nicht unterstützt wird.

Grüße aus dem Sauerland

Zitat von Whity

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

Zitat von Whity

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.

Zitat von Krauskopp

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

Zitat von Krauskopp

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.

Zitat von Krauskopp

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.

Zitat von SeRef

Hast du eventuell bei "Obstacle detection" einen (zu kleinen) Wert eingetragen?

Nein, das war auch meine Vermutung zuerst, habe es dann rausgenommen.

Zitat von thgoebel

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)?

Zitat von PitchControl

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.

Paradoxx87

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

Zitat von martner

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

Zitat von martner

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.

Zitat von martner

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 ?

Zitat von Flutschi

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.