Beiträge von wing350

Zitat von kochan

Habe jetz genau die selbe idee dazu gehabt.

Haben uns eine Oase Aquarius Universal Premium 4000 gekauft.

Zuhause habe ich noch einen Shelly Dimmer 2 liegen.

Alternative habe ich gesehen, dass dieser Drehzahlregler auch dazu genutzt wird um den Fluss des Wassers zu beinflussen.

Aber ist halt eine Steckdose .....

Der Drehzahlregler im Link funktioniert nicht mit der Oase-Pumpe. Habe ich gerade probiert.

Der Shellydimmer2 wird jetzt im Sommer schnell zu heiß, so dass er selber bei ~100°C abschaltet. Dann läuft die Pumpe u.U. nur 5 Minuten.

In derr kühleren Jahreszeit gehts durchaus mit dem Dimmer2. Der wird dann max. 85°C bei mir warm (Chiptemperatur). Ich habe aber sicheheitshalber in FHEM eine Schaltung realisiert, die die Pumpe bei >90° abschaltet und bei <50°C wieder einschaltet.

Jetzt im Sommer habe nehme ich einen shelly1 zum Schalte und verzichte auf die Regulierung bzw. aktiviere ich einen Bypass zu unserem Wasserfall, der sonst zu stark ist.

Insgesamt muss man aber korrekterweise sagen, dass bei diesen Motoren nur ein Frequenzumrichter richtig hilft, der ist aber wesentlich teurer als eine kleinere Pumpe.

Wireguard als VPN-Lösung ist auch ohne komplexe Nutzungsszenarien wie bei Schubbie eine absolut tolle Sache.

1. AVM baut das Protokoll in die nächste stabile FW-Version ein. Ich benutze es schon länger in der Laborversion und es läuft sauber, stabil und ist kinderleicht einzurichten. Ich habe deswegen bereits meine VM mit WG-Server abgeschaltet und die WG-Lösung auf der QNAP ebenfalls.

2. Man kann nach Bedarf über einen Flow in Automate den VPN-Tunnel einschalten, wenn man das heimische WLAN verlässt und bei Rückkehr ausschalten. Das heißt, man ist im Mobilnetz und fremdem WLANs immer sicher über VPN verbunden. Das ist vor allem gut, wenn man zuhause AdGuard oder einen pihole am Laufen hat.

3. Es spricht nichts dagegen, den WG-Tunnel ständig (auch im heimischen Netzwerek) eingeschaltet zu lassen. Man kann in der WG-App ggf. einzelne oder mehrere Apps auswählen, die nicht über dern Tunnel Laufen sollen. Der einzige Nachteil ist ein nächtlicher IP-Zwangswechsel, der ein einmaliges Aus- und wieder Einschalten des Tunnels erfordert. Das kann man aber auch über einen Flow in Automate abfangen.

4. Meine Erfahrungen mit dem Fritzbox-Wireguard zeigen, dass der Tunnel bisher jeden Wechsel zwischen Mobilfunk und verschiedenen WLANS bedenkenlos mitmacht.

Zitat von slcr

hast du zufällig irgendwo mehr infos zu deinem setup, der genutzten Pumpe etc?
Ich suche aktuell genau sowas und das wäre definitiv das Zünglein an der Waage das mich zu einer Oase Pumpe locken würde

Ich habe leider kein Datenblatt der Pumpe mehr. Es hieß jedoch in der Bedienungsanleitung, man solle die Pumpe nicht mit irgendeinem Dimmer steuern, sondern nur mir einer Steuerung von Oase selbst (Ein Schelm, wer Böses dabei denkt).

Ich benutze also seit über einem Jahr einen Shelly-Dimmer 1 und habe die Pumpe auf 33% ^= 46 W gedimmt (ich habe einen 1,2m hohen Wasserfall zu speisen) und schalte die Pumpe mit einem Timer (fhem) 40min ein und 20 min aus. Der Timer gilt natürlich auch für die UVC-Lampe (11W), die nur an sein darf, wenn auch Wasser durch den Filter fließt. Das Ganze läuft auch den ganzen Winter durch, weil ich die Pumpe im Teich und den Filter nicht rausnehmen bzw. entleeren kann. Dim-type= trailing edge. Calibration habe ich nicht durchgeführt. Ohne Dimmer zieht die Pumpe ca. 65W.

Hoffentlich hilft das.

Viel Glück!

Dieses Verhalten kann ich mir nicht erklären! Ist das wohl ein Garantiefall oder liegt es an der 0.93 beta?. Ich bin der Meinung, dass der Fehler in der alten Betaversion nicht vorhanden war.

Also ich habe 2 SW2.5 im Roller-Betrieb. Einer davon hat die Beta-FW, der andere nicht. Die senden beide ca. alle 30sec per MQTT ihre Daten an den MQTT-Broker. Der mit der Beta-FW hat 47°C, der andere 59°C.

Wenn der Datenverkehr ausschließlich per MQTT läuft, ist es doch egal, wie oft ein Client, welcher Art auch immer, sich Daten vom Broker holt. Damit wird doch der Datenverkehr des Shelly mit dem Broker gar nicht berührt, sofern ich nicht irgendwelche Befehle an den Shelly sende.

Bei mir funktioniert ein Reset des Usereadings 'relay_0_energy_total' einwandfrei:

setreading <device> relay_0_energy_total 0

Allerdings mache ich die weiteren Berechnungen in eigenen Userreadings. Der Plug S hat ja keinen eigenen Wertespeicher wie der EM.

Zitat von Robert_M.

Hallo wing350,

Leider kann ich persönlich aus deiner Fehlerbeschreibung nicht erlesen was genau dein Problem ist.

Kannst du bitte genauer beschreiben worauf du hinaus willst?

Was ist dein Problem genau? Mein Pro4PM ließ sich ganz normal in meine Shelly Cloud App auf Android hinzufügen.

Zitat von 66er

Für Probleme beim Einbinden in die Shelly Cloud App gibt es einen Lexikoneintrag.

Den findet man entweder über die Suche oder durch Lesen der Einsteigertipps ( B2 ).

Moin,

ich will ja nicht unhöflich sein, aber wer lesen kann, ist klar im Vorteil :

Ich habe das Problem im Bereich "Shelly Home App" gestellt. Und in dieser App lässt sich der Pro4PM z.Z. nicht einbinden.

Also klares Problem und mit der ShellyCloud habe ich nichts am Hut.

In der neuen Android-Version soll man per Auswahlliste und Daten des WLAN Geräte manuell verbinden können. Zumindest beim ShellyPro4PM (der auch auf der Liste steht) funktioniert das nicht.

Leider hat bisher keiner eine MQTT2_Device-Template für den Sehelly pro 4PM geschrieben und wegen der neuen Befehls- und Status-Strukturen habe ich mich da auch nur rudimentär eingearbeitet.

Alles, was ich i.A. brauche, ist, die Schaltkanäle in 4 jeweils einzelnen Geräten an-/ausschalten zu können, um sie auch von meiner Frau problemlos in FHEM-Native schalten zu lassen.

Dazu habe ich den Shelly automatisch von FHEM importieren lassen und keine Template dazu ausgewählt. Dann habe ich 'attr SetList' gesetzt:

on1:noArg Terrasse/rpc {"method":"Switch.Set", "params":{"id":0,"on":true}}
off1:noArg Terrasse/rpc {"method":"Switch.Set", "params":{"id":0,"on":false}}
on2:noArg Terrasse/rpc {"method":"Switch.Set", "params":{"id":1,"on":true}}
off2:noArg Terrasse/rpc {"method":"Switch.Set", "params":{"id":1,"on":false}}
on3:noArg Terrasse/rpc {"method":"Switch.Set", "params":{"id":2,"on":true}}
off3:noArg Terrasse/rpc {"method":"Switch.Set", "params":{"id":2,"on":false}}
on4:noArg Terrasse/rpc {"method":"Switch.Set", "params":{"id":3,"on":true}}
off4:noArg Terrasse/rpc {"method":"Switch.Set", "params":{"id":3,"on":false}}

Das Wort 'Terasse' ist natürlich durch den entsprechenden Topic-Namen zu ersetzen.

Danach habe ich 4 MSwitch-Devices angelegt, die die Funktion eines Dummy u. eines Notify kombinieren.

Das auslösende Gerät: MSwitch_self

Keine Trigger

zu schaltendes Gerät: <Name des Shellypro 4 PM4>

Befehle:

CMD1: Aus der Dropdown-Liste 'on1' wählen #bzw. on2,on3,on4

CMD2: dto. 'off1' #bzw. off2,off3,off4

attr <Name des MSwitch_Device> setList on off

attr <Name des MSwitch_Device> webCmd on:off

Dann erscheinen in der obersten Gerätezeile die Befehle 'on' und 'off' und das Lämpchen, mit dem man auch schalten kann.

Dies ist erstmal nur eine Möglichkeit, auf die Schnelle den Shelly pro 4PM einsatzfähig zu machen.

Zitat von Seven of Nine

er ist über MQTT (RPC) r steuerbar, über mosquitto_pub z.B. klappt das problemlos mit folgendem Kommando

Code

mosquitto_pub -h localhost -p 1883 -u admin -P admin -t home/wohnzimmer/rpc  -m '{"id":124, "src":"user_1", "method":"Switch.Set", "params":{"id":3,"on":true}}'

Das kann ich leider nicht nachvollziehen. Ich habe kein mosquitto, sondern arbeite mit dem MQTT-Explorer. Wenn ich dort unter dem passenden Topic den json-String publiziere, wird er mir zwar als event angezeigt, aber am status und in der Realität ändert sich nichts. Ich kann mir nicht vorstellen, dass das am MQTT-Explorer liegen soll.

Asche auf mein Haupt: Im Topic war das 'event' zu viel!

Nun geht es.

Alle 23 shellies (1,1pm, Dimmer 1, 2.5, RGBW2) mit 20210415-125832/v1.10.3-g23074d0 upgedated.

Keine Auffälligkeiten!

Zitat von alsk1

Wo sitzt dein Repeater wenn Du im Garten 72mbit/s bei den Shellies hast (Top Verbindung)?

Im Schuppen an der Hauswand sitzt ein Fritz-600-Repeater (62 Mb/s zur FB) in einem IP65-Gehäuse. Die Shellies sitzen ca. 20m entfernt hinter einer 50cm dicken Steigabione ebenfalls in einem IP65-Gehäuse auf einer Hutschiene.

Direkt zur FB hätten sie 10m Entfernung mehr, aber zusätzlich 3-Scheiben-Fenster und eine 10mm-Glasschiebewand. Deswegen der Repeater, der nur durch 2 Mauern von der FB getrennt ist.

Gerade sehe ich, dass der RGBW2, der wieder mit der 1.9 er FW arbeitet, sich dummerweise mal wieder umgemeldet hat, aber die FW hat ja kein Roaming.

Mit der ganz schnöden FB 7590 und 2 Fritz-Repeatern im Mesh-Verbund hatte ich, was meine "Garten"-Shellies betrifft, immer wieder unerwünschte AP-Wechsel, die meist mit einer schlechteren RSSI einhergingen u.U. bis zum völligen Abriss.

Mit der neuen AP-Roaming-Funktion habe ich keinerlei negative AP-Wechsel mehr gehabt. Alle Garten-Shellies bleiben schön beim Garten-AP. und haben eine stabile Verbindung mit 72 MBit/s.

Bis auf das Gezicke mit der RGBW2-FW im Monochrom-Modus bin ich richtig zufrieden momentan.

Mit der neuen FW  20210319-122304/v.1.10-Dimmer1-gfd4cc10 scheint das Problem mit den Dimmern behoben zu sein.

Alle 9 Dimmer 1 scheinen jetzt ordentlich zu funktionieren!

1 Dimmer 1 behauptet im WebUI, die FW 1.10.0 drauf zu haben, zeigt aber keinen Menupunkt fürs AP-Roaming und keine neuen Einträge bei den Developer-Settings. Funktioniert aber sonst normal.

Nachtrag: Hat sich erledigt!

Shelly 1, 1pm und 2.5 und plug-S scheinen mit der FW 1.10.0 korrekt zu funktionieren.

Dimmer 1 (SHDM-1)

Ich habe 9 Dimmer im System. 3 davon funktionierten nach dem Upgrade normal. Bei den anderen 6 war es zappenduster. Die Leuchten reagierten weder auf die Taster noch auf Softwaresteuerung, wobei die WebUI die Schalt- und Dimmvorgänge ordnungsgemäß anzeigte. Nur die Leistungsanzeige zeigte natürlich nichts.

Irgendwann schalteten die Dimmer nach einem sehr langen Tastendruck ein, ließen sich aber weder dimmen noch ausschalten.

Ich habe dann alle wieder auf die FW 1.9.4. zurückgesetzt und alles war wieder in Ordnung. Nach einem erneuten Upgrade auf 1.10. funktioniertten dann 4 wieder normal, aber 2 zickten wieder auf die selbe Weise wie vorher. Das ließ sich auch bei einem dritten Upgradeversuch wieder reproduzieren.

Wenn du den besagten Touchschalter (mit WLAN-Unterstützung) statt des Tasters in die obige Schaltung einbaust, kannst du den Shelly schalten, aber nicht mit dem Schalter dimmen!

Dimmen könntest du ihn dann nur über das WLAN, in dem sich der Shelly befindet.

Elektrisch und sicherheitstechnisch ist das aber eine Konstruktion, auf die ich mich nicht verlassen würde.

Sicherer ist der Tausch des Touchschalters in einen mechanischen 3-fach-Taster, der die 3 Shellys auch bei einem WLAN-Ausfall steuern kann. Wenn du sowieso damit in einem Klemmkasten unterwegs bist, kannst du ja die Shellies auf Dauerstrom legen (Achtung: alles mit der selben Phase!).

Das war die Entscheidung, vor der ich im Sommer auch stand. Man wird das Risiko eingehen müssen.

Eine UVC-Lampe darf man meines Wissens auch n i c h t über den Dimmer laufen lassen. Mit einem Shelly 1pm ging es auch nicht zu schalten. Das tut jetzt ein einfacher Shelly1, der gleichzeitig von fhem aus mit der Pumpe geschaltet wird ( wichtig wegen der Kühlung der Lampe durch das fließende Wasser).