Beiträge von Sixtus Freebyte

Ich werde hier echt noch völlig verrückt und sehe Geister ...

5 Shelly H&T im Gebäude, alle vor ca. 20 Tagen auf MQTT umkonfiguriert, desgleichen nochmal 5 DW.

Der Mosquitto-Server (eine VM Instanz auf meiner Workstation) lief bis vor 5 Tagen durch und dann - lief der Mosquitto halt 2 Tage nicht bis ich ihn neu angetreten habe.

Alle Shellies sind dann wieder am Mosquitto angelandet, bis auf sämtliche Batteriebetriebenen H&T und DW Sensoren - die sich selbst nach 3 Tagen nicht mehr gemeldet haben.

Gerade eben habe ich den H&T hinter mir im Büro mal kurz per Knopfdruck aktiviert, schon melden sich alle anderen H&T via MQTT am Mosquitto an und als ich den DW an der Bürotür mal mit einer aufgebogenen Büroklammer zwecks Schalterdruck aktiviert habe, melden sich zumindest 2 weitere DW per MQTT.

Kann zumindest jemand bestätigen, dass die Batterie-Shellies DW und H&T mit dem "senden" aufhören, wenn ihnen der MQTT oder ColoT-Server fehlt (dh. keiner dort antwortet)?

Bernd

Zitat

Info, wollte in Zukunft auch sowas bauen..

Aus welcher HA kommen denn diese netten Grafiken?

Bernd

Zitat

Die verdienen nix am Verkauf, daher die Ablehnung

Da muss man schon irgendwo in der tiefsten Provinz auf die Suche gehen um einen Handwerker zu finden der am Verkauf des Installationsmaterial noch ernsthaft was verdienen kann oder will.

Die Handwerker schlagen auf den EK ihre Kosten für Einkauf, Lagerung, Verwahrung, Transport, Versicherung und Gewährleistung auf - das muss jeder machen.

"Mein" Elektriker rechnet bei gestelltem Material ganz normal die Arbeitszeit für den Gesellen voll und den Lehrling halb ab, das sind für den Einbau von 2x 3EM und Kaffeeklatsch ca. 1h und irgendwas um die 100 EUR netto.

Der Chef ist froh, dass er irgendwo eine Stunde Leerlauf gefüllt hat und die Kollegen vor Ort haben was dazugelernt und sich über den Kaffee gefreut.

Friede, Froide, Eierkuchen

Bernd

Zitat

Ja und funktioniert bei Bewegung, die Sonne bewegt sich nur zu langsam für Aktion.

Wenn ich den Einsatzzweck des TO richtig gelesen habe, sollte da hinreichend Bewegung auf dem Sofa sein um den MOT zur Übermittlung einer Motion und damit auch parallel der Lichtstärke zu bewegen.

Mal eine ganz irre Frage zur aktuellen Firmware und MQTT: ich habe heuer 30 PlugS (kann man ja scripten) installiert und auch das Problem gehabt, dass die Orginal-Firmware 2019irgendwas v1.9 nicht erkennen möchte, dass es Updates gibt.

Ich habe dann direkt die Firmware 1.11.7 eingespielt und festgestellt, dass im Bereich MQTT die Eingabe des MQTT Präfixes fehlt, dafür ein MQTT "Last Will" konfigurierbar ist.

Spiele ich aber zuerst 1.11.4-DNSfix ein und mache dann über den Shelly selbst das Update auf 1.11.7, dann ist die MQTT-Konfiguration so wie gewohnt.

Hat jemand eine Idee, was da los ist (oder gabs das hier schonmal)? Aus einer Stichprobe von 3 Shelly PlugS haben alle 3 dieses Verhalten gezeigt.

Bernd

Zitat

Ihr seht es ja. Da sind schon einige Geräte im Netzwerk. Die laufen auch soweit. Nur die Shellys sind sporadisch mal "dann weg".

Meisstens sind sie da, irren aber als Geister herum weil sie kein WLAN finden. Da gibts den Punkt "WiFi Client AP Roaming", wenn da ein Häkchenfeld ist bitte mal setzen.

Für Smartphones gibts "WLAN-Analyzer" und die mal in die Nähe eines Shellies bringen zum zu sehen ob da überhaupt noch Signal ist (und wenn der Shelly dann hinter einem Schalter verbaut ist, nochmal ordentlich Abziehen)

Cloud? Nie genutzt weil im Zweifel nicht debuggbar ("Geht nicht? Es klemmt irgendwo. Und wo? Kann man nicht ermitteln sondern nur Raten")

Ich war lange ein Fan des Shelly CoLoT-Protokolls, weil es ein abgespeckter Bastard des RFC 7252 ist. Wenn man sich das CoAP-Protokoll in RFC 7252 genauer anschaut, vermisst man gewisse Features die man eigentlich erwartet hätte, wenn das Protokoll wirklich ernsthaft auf IoT ausgelegt wäre (zB. eine gewisse Leichtigkeit - kein Wunder, dass die Shellies da einen Fork hingelegt haben).

Nach langem überlegen hab ich dann Colot überall rausgeschmissen und bin auf MQTT mit einem separaten Server umgestiegen wo die ganzen HA-Systeme nur noch Clients sind.

Und siehe da: selbst vermeintlich störrische Shellies (wie DW, H&T, Motion) liefern sporadisch, aber regelmässig, am Mosquitto (MQTT Server) ihre Daten ab die dann irgendwann von der HA abgegriffen werden.

Zitat

Habe versucht ohne 5Ghz-Wlan auszukomnen, ohne Erfolg.

Die Shellies (zumindest die "alten") können nur 2.4GHz, und das ist auch gut so - je höher die Frequenz desto schlechter verbreitet sich das Signal durch Mauern und um Mauern herum. Eigentlich müsste man die ins alte 400MHz-Band verbannen, aber das gibts ja nimmer für WLAN.

Zitat

Aber wenn ich transiente Überspannungen unterdrücken möchte, würde ich das keinem Shelly überlassen! Dafür gibt es bessere und schnellere Komponenten…

Dito. Vorallem weil ein wirksamer ÜS-Schutz seinen Platz auf der Platine braucht. Ausgenommen natürlich Einweg-Konstruktionen.

Wenn ich an die Gewitter 1987/88/89 hier in meiner Gegend denke - da war alles drin bis Elmsfeuer am Switch (naja, ich hatte eine aufgewickelte 50m Rolle Ethernetkabel temporär als Verlängerung genutzt und der Blitz schlug recht nahe dazu ein - dumm geplant).

Zum Glück bin ich Hochspannungsfest, meine Frau danach auch

Bernd

Zitat

Die DS18B20 Sensoren sind wohl die einfachste Möglichkeit. Allerdings kann ich nicht abschätzen, wie schnell die anspringen, wenn sie mit Abstand zum Rohr verlegt sind.

Hängt vom Schwellwert ab und der wiederum von der allgemeinen Temperatur im Haus. Kann man dadurch kompensieren, dass ein Fühler in der Nähe des Rohrs und ein anderer Fühler (an den UNI gehen ja 3x 1wire dran) weiter weg ist. Dann Differenz bilden und diese Temperatur als Schwellwert nehmen. Mit sowas bekommt man das System recht feinfühlig. Alternativ halt sagen "Wenns 80°C sind, ist der Kamin an".

Zu einer anderen Frage von Dir: Löchle im Rohr und Sensor reinschrauben ist dem Feuerstättenbeschauer egal solange es halbwegs dicht ist.

Wenn Du Wert auf schnelle Reaktion legst, dann brauchst Du einen Sensor der im oberen Drittel des Abgasstroms im Rohr misst (wie es die Schornsteinfeger bzw. Heizungsbauer auch machen) - bis die Rohrwand wärmer wird, dauert es relativ lange. Du hast also auch bei der PT100 Variante Verzögerungen und kommst um eine Differenzmessung nicht herum (Klimawandel, 50°C im Schatten selbst am Nordpol usw,)

Wenn es einfach nur um einen Status "Da produziert irgendwas Wärme" geht, ist später eher Dein Problem zu erkennen, wann der Kamin aus ist: bis das Gesamtsystem merkbar abgekühlt ist, vergehen je nach Isolation mehrere Stunden.

Wärmefühler könnten der verkehrte Ansatz sein, das wäre eher ein Fall für ein Anemometer (Flügelrad, Hitzedraht etc.): sobald in der Brennkammer Wärme entsteht oder versiegt, ändert sich die Geschwindigkeit der Rauchgase - und das sehr schnell und gleichmässig über die gesamte Strecke des Abgasrohrs (störende Nebeneffekte: Sturmböen und Storchnestbau auf dem Kamin).

Und das Schlusswort zu Latenzen und Verzögerungen: Bitte bedenken, dass Deine HA unter Umständen einen Sensor nur sporadisch abfragt bzw. Push-Meldungen auch gerne mal für später in die Warteschlange einreiht.

Bernd

PS: Dass ich den DS erwähnt habe, liegt einfach daran dass davon hier genug herumliegen und ich auch paar UNIs auf Lager habe - da versuche ich latürnich zuerst das zu verbauen, was vorhanden ist.

Zitat

Ist ein Tick von mir, dass ich alles möglichst einheitlich habe und ich habe mit MQTT und Node Red angefangen, daher würde ich gerne auch die Shellies per MQTT in Homeassistent testen. Klingt schwachsinnig, aber jeder hat seinen Tick

Nachdem ich nun 3x alle 30 Shellies incl. der Batteriebetriebenen Geräte draussen in der Kälte neu durchkonfiguriert habe, ist Dein"Tick" mit MQTT schon wieder vollkommen nachvollziebar: Statt den MQTT Server der HA zu nutzen installiert man sowas wie Mosquitto separat und klemmt die Shellies auf diesen Server - die wechselnden oder auszuprobierenden HA-Systeme sind dann MQTT Clients und ob und wie dann openHAB, HomeAssistant oder nodeIO auf dem Bus lauschen oder Befehle senden kann einem Egal sein.

Zumal man mit Tools wie MQTT Explorer (div. Betriebssysteme) direkt die Nachrichten verfolgen kann.

Bis Vorgestern war ich noch ein Fan von ColoT, aber die Debuggbarkeit und Portabliität lässt gegenüber einem "Alt-Protokoll" sehr zu wünschen übrig (oder anders herum: ein unabhängiger ColoT Broker mit gescheitem Logging würde viel Stress bei der Einbindung von HA Systemen ersparen).

Bernd

Zitat

Ich meinte sowas einfaches:

Hm.. Dunkle Photodiode, könnte irgendeine Spannung proportional zur Wärme im Erfassungsbereich abgeben.

Habe mal 2 zum Basteln bestellt.

Löst aber nicht direkt das Problem des TO, was ich mal mit den bisherigen Lösungsvorschlägen zusammenfassen möchte:

1) PT100 in der Version "kann mit Kabel schonmal 350°C ab" und dahinter ein Messverstärker.

2) DS18B20 1-Wire in angemessenem Abstand (Max Temp = 150°C) und direkt an den Shelly anschliessen.

3) Der zuvor genannte Flammenwächter, der braucht aber halt auch Abstand zur Hitze und muss genau da montiert werden, wo es die Ehefrau stört.

Schwierig ...

Bernd

Zitat

Also sind wir jetzt wieder beim Flammwächter gelandet - hab ich zwar schon mal vorgeschlagen ist aber abgelehnt worden.

Nach der Beschreibung von DIYROLLY könnte sowas wie AM312 (SR501, SR505, SR602) mit "Flammwächter" gemeint sein. Eigentlich sind das fertige Bewegungssensoren, die man aber auch als Flammwächter missbrauchen kann.

Problem ist: das sind pyroelektrische Sensoren (Erklärung hier und dort) - im Grundprinzip Piezokristalle wie im "elektronischen Feuerzeug", da erkennt man schon vage dass so ein PIR-Sensor keine absoluten Temperaturen sondern nur Temperaturänderungen ausliefern kann.

Als Flammwächter in einer Gas/Ölheizung ist das vollkommen in Ordnung, weil so eine Flamme mit 1-5Hz moduliert und ein entsprechendes ΔT erzeugt.

Wäre also auch ein Kandidat für das Vorhaben des TO: Solange der Kamin lustig flackert, wird auch ein konventioneller Bewegungssensor getriggert.

Für Restwärme etc.. würde ich dann doch eher auf Bolometer ausweichen - defacto auch nur "miniatur NTCs" und wieder der Zirkus mitt Messverstärker oder Auswerteelektronik.

Bernd

Zitat

[...]

Den Eindruck hatte ich damals von OpenHAB auch und hab deshalb nach etlichen verbrannten Wochen Zeit sowohl OpenHAB als auch ioBroker "ad Acta" gelegt und stattdessen HomeAssistant installiert. Da hatte ich in unter einer Stunde entsprechende Ergebnisse

Ich bin aus dem Alter raus, wo man sich Tage (und Nächte) um die Ohren schlagen will bevor man Ergebnisse hat. Für mich muss Software einfach und Intuitiv sein und da ist HomeAssistant meines Erachtens den anderen freien Systemen (OpenHAB, ioBroker, FHEM..) um Lichtjahre voraus.

IP-Symcom kenne ich nicht, aber 150 Euro für ein Stück Software ist ja auch keine gigantische Summe wenn es deine Anforderungen erfüllt

Bei HomeAssistant hat mich etwas irritiert, dass die "Plain Linux" Installation mehr oder weniger in einer chroot Umgebung läuft, das ist recht ungewöhnlich. So ganz einfach "Installieren und loslegen" habe ich bei aktuellen HA Systemen bislang nur bei openHAB und IP Symcon gesehen. Bei fertigen Containern muss man sich darauf verlassen, dass die Ersteller dafür sorgen dass das Innenleben regelmässig gepatcht wird (wobei das natürlich bei einer lokalen HA jetzt nicht so das riesige Sicherheitsrisiko ist).

Aktuell schwanke ich noch zwischen Symcon und HomeAssistant. Ich glaube, ich schmeiss erstmal eine separate Mosquitto Instanz ins Netz und stelle die Shellies drauf um, dann ist es erstmal egal wer da als HA lauscht.

Symcon hat halt den Charme, dass sie bezahlten Support anbieten - das wäre hilfreich, wenn die Firma mal meinen Leidensweg in Geld vom Kunden umsetzen möchte

Danke für die Hilfe!

Bernd

Zitat

Das sind einfache Module für 3-5V (ggf. mehr) mit LM393 Komparator und Ausgang (Arduino, RasPi)

Die Diode reagiert auf ne bestimmte Wellenlänge.

Sind schon viele diverse Module getestet worden.

Der UNI hat ja 3,3V DC für Sensoren

Ah, danke für die Aufklärung! Hast Du dafür ein Stichwort für die Suche?

Bernd

Zitat

Was willst du uns eigentlich erzählen?

"Uns".... Es wäre mir neu, dass Du in irgendeiner Form legitimiert oder sonstwie priviligiert wärest für das gesamte Forum zu sprechen.

Aber immerhin hast Du mit diesem Posting noch ein Fleisskärtchen auf dem Weg für das Signet "Shelly-Gott" geleistet.

Ich sehe schon wie das ausgeht: Langjährige Blubberteilnehmer wie Du steigen auf und werden von den Moderatoren geschont, rationale Kräfte wie ich werden herausgeekelt, dann kommt der Status "Sufu-Forum" mit Postings "BENUTZE GEFÄLLIGST DIE SUFU - DA FINDEST DU ALLES" und am Schluss wird (ähnlich wie in jedem Verein) gejammert, dass der Nachwuchs fehlt.

Ich war der Nachwuchs - Glückwunsch, Idiot.

Zitat

Nebenbei erlangt er die bahnbrechend neue Erkenntnis, dass eine Community-Driven-Anwendung zwar gratis ist, aber – oh Schreck – die Doku und die Anwenderfreundlichkeit nicht so gut ist, wie bei einer Bezahlsoftware (500€). Wer hätte das gedacht…

Nebenbei: Die Software kostet 500€ in der "Unlimited" Variante, die kleinste Lizenz 150€ und ist dort auf 250 Variablen beschränkt. Im Prinzip ist dort eine "Variable" jeder Kanal den so ein Shelly ausspuckt und der überwacht werden soll, da kann man zB. beim 3EM schon massiv kürzen.

Deinen zweiten Halbsatz verstehe ich nicht.

"Anwenderfreundlichkeit" bemisst sich an dem, was beim Anwender ankommt und nicht an den feuchten Träumen der Entwickler, mit ihrem Tool die Welt zu beglücken.

Für "Anwenderfreundlichkeit" brauche ich keinen Sack voller Geld sondern lediglich die Überlegung "Was erwartet der Anwender an dieser Stelle, wie eine Eingabe funktionieren soll" und weil Support immer irgendwelche Kosten verursacht: "Wie strukturiere ich das UI dass die Eingaben genau dort verlangt wo sie der Anwender erwartet?"

Und da sind wir schon beim Support und der Doku: Die "wahnsinnig teure kommerzielle, böse anwendung" kommt mit wenig Doku, dafür mit einem schlagkräftigen Interface daher weil der kostengünstigste Support bei einer "Bezahlsoftware" immer jener ist, der nicht geleistet werden muss - bei Community-Driven-Anwendung haben selbst die Evangelisten bei einem unwartbaren Schrott irgendwann keine Lust mehr (das sehe ich an der Forenausdünnung der gängigen OSS HA).

Bei "Doku" muss ich mir nur openHAB anschauen: eine kleine Community entwickelt das Produkt im Galopp nach ihren eigenen Interessen an der Masse der Anwender vorbei wärend die leistungswilligen Pfleger der Doku mangels Kommunikation mit den Entwicklern schon vor Monaten abgesprungen sind und auch keiner mehr so recht nachkommt.

Seen that, done that.

Dann doch lieber 150€

Bernd

Zitat

Bist du denn damit bis jetzt zu frieden

Für mich hört sich das auch nicht ganz einfach an, aber ich bin auch nicht vom Fach. Halt mehr Anwender

Deine Frage finde ich total spannend weil sie zur Frage führt "Was will man eigentlich am Ende bewirken?"

Mittlerweile bin ich zur Erkenntnis gekommen, dass ich eigentlich "nur" einen fetten Datenlogger mit Visualisierung und angehängter Eventbearbeitung ("Heizung an wenn ...") benötige - und das erledigt "IP Symcron" insofern sehr gut, weil es den Ball sehr flach hält und die Grundbedürfnisse (zb. den Objektbaum per Drag & Drop zu strukturieren) sehr gut erfüllt und man sich nur an wenige Eigenarten gewöhnen muss.

Das mag auch daran liegen, dass die Vorgängerversionen noch klassische Windows-Programme waren, deren Features der Benutzeroberfläche nun ins Web transportiert werden mussten - und da kann man als Entwickler halt nur an Komfort retten was zu retten ist (und das ist ihnen wirklich gut gelungen - ohne dass ich jemals die Vorgängerversion genutzt habe).

Für hübsche Frontends mit Wettervorhersage, Menstruationskalender und Beleuchtungsszenen ist IP Symcron sicherlich nutzbar (ggf. durch Plugin-Erweiterung, habe da was im Store gesehen), brauche ich aber aber nicht.

Die einzige Automatisierung, die ich nun dem Symcron beigebracht habe, ist "Wenn der DW Sensor aufgeht und es Dunkel ist, dann schalte für 40 Sekunden das Licht in der Ecke ein" damit ich den eigentlichen Lichtschalter finde (den ich nicht immer nutzen möchte), meisstens langt das um den Flur zu verlassen.

Ansonsten muss ich schauen, ob Symcon meine längerfristige Anwendung wird.

Bernd

Zitat

Wenn es Flammenwächter sein soll.

Es gibt einfache Module die das per IR "messen".

Der geht direkt am UNI?

Kurzes Zwischenfazit: Ich habe mir heuer eine Demolizenz für IP Symcon besorgt, ein plattes Debian 11 ohne alles in einer VM aufgesetzt und via "apt" Repository das Produkt nachgezogen.

Was ich recht sympatisch fand (und in der Kurzanleitung zur Installation hinreichend beschrieben) verzichtet das System in der Grundausstattung auf jegliche User/Passwortverwaltung weil davon ausgegangen wird dass es erstmal lokal läuft (was man aber recht fein granuliert später nachtragen kann).

Als Plugins einen MQTT Server und die Shelly Integration nachgezogen und dann erstmal den Shellies MQTT beigebracht.

Autodiscovery existiert, ist aber schrottig: bei MQTT muss man jeden Channel einzeln anfassen wärend sich die Shelly-Integration an der kryptischen ID festbeisst statt die konfigurierten MQTT Präfixe der Shellies zu nutzen.

Macht aber nix, denn das Konzept der UI ist (hüstel) brachial einfach: Alles was irgendwie konfiguriert wird, bekommt eine 5stellige ID die in einem Objektbaum geklemmt wird.

Also einfach mit rechter Maustaste "Objekt hinzufügen" -> "Instanz" -> "Shelly 3EM", dort gleich einen passenden Namen wie "Wallbox" vergeben, schon hängt es am Baum und danach mit "Objekt bearbeiten" noch das "MQTT Topic" eintragen (das schreib ich vom MQTT Explorer ab).

Wenn alles stimmt, aktualisiert sich die zugehörige Spalte (sowas wie "Last seen") im aufgeklappten Objekt und alles ist gut.

Jetzt muss man den "Variablen" unter dem jeweiligen Objekt nur noch sagen, ob der Verlauf gespeichert werden soll ("Persistenz"), das macht natürlich nur für wenige Sachen einen Sinn.

Und schon kann man sich alles incl. Werte direkt im Objektbaum anschauen.

Dafür habe ich (Download, Installation, grundlegende Einarbeitung, Shellies auf MQTT umstellen, bisserl hin und her testen/probieren) 3 Stunden gebraucht, das ist vergleichsweise sehr wenig.

Dann noch bisserl aufräumen, sortieren und anordnen (die Objekte im Baum kann man via D&D verschieben und via Kategorieordner strukturieren), dann noch schnell paar Grafiken fürs Monitoring gebaut (selbst sowas wie "Zeige mir die Leistung der Phasen L1-L3 zusammen mit dem cosPhi L1-L3 gemeinsam an" geht völlig problemlos weil das System dann für den Powerfaktor abfragt, welche Grenzwerte gelten und dann die Werte recht Unfallfrei in die Grafik bringt).

Trigger sind einfach, man muss sich nur daran gewöhnen dass das dann am Zielobjekt "klebt" und dort nachträglich editiert werden kann.

Globale Variable für die Summe L1-L3 mach ich dann morgen.

Zitat

Ob mein Sandförmchen schöner ist möchte ich nicht beurteilen.

Aber soviel Bullshit wie in dem zitierten Beitrag habe ich noch nicht gelesen.

Aus Deinem Munde ist das für mich ein Kompliment - Danke dafür!

Bernd

Zitat

Bei einem Dimmer 2 schaltet sich der Dimmer mit dem Hinweis über Temperatur ab. Kalibrierung mehrfach durchgeführt auf Trailing Edge ei

eingestellt. Angeschlossen ist ein 200 VA LED Trafo mit 24 V. Dahinter in ungefähr 5 m Entfernung ein Leuchtband mit einer Leistung von circa 95 VA. Hat jemand eine Idee woran es liegen könnte?

Verstehe ich das richtig: Shelly Dimmer 2 -> Trafo -> LED Leuchtband?

Wie jenne72 schrub: Trafo muss explizit Dimmbar sein und auch das ist keine Garantie, dass es mit Shelly/Paulmann/Sonstige Dimmer geht.

Eigentlich geht das so: Trafo -> Shelly Dimmer 2 -> LED Leuchtband.

Kannst Du das umbauen?

Bernd