Ich hab ALLES auf v6 außer die Shellys... Die habe ich per NAT64 zwar auch schon im Betrieb (ioBroker ist ebenfalls v6 only) aber es wäre schon super auf NAT64 verzichten zu können - zumal das auch eigene v6 Internet Clouds erlauben würde.
Beiträge von chris929
-
-
Ich hab eben mal testweise für die Jungs vom ioBroker den 1PM Plus und 1 Plus ins Netz gehangen - eigentlich weil ich euphorisch die neuen Geräte testen wollte als alter Shelly Fan
Was haben die Dev's bei Shelly denn bitte geraucht als die "die Dinger" entwickelt haben?
"Mehr CPU", "Mehr Schnittstellen"--> dafür unsicher, auf kosten der Lebensdauer und "sinnfrei" bei den defaultsettings - toller tausch
Achtung: "Rant-Alarm" Bitte die "Rants" mit Humor nehmen - bin nach wie vor ein Fan von Shelly, muss aber mal jemanden "aufwecken"... Da ich weiß, dass Shelly selbst auch hier ins Forum schaut, hoffe ich, dass man dringend nochmal einiges überarbeitet.
So sind die Geräte für "Beginner" nicht nutzbar und mehr noch: Nicht zu empfehlen!
Ich werde die Geräte so nicht in mein Netz integrieren sondern abwarten, ob sich da tatsächlich was zum guten ändert.
Wenn die Geräte für den Schaltkasten genau so auf den Markt kommen wie die aktuellen "Plus" Geräte, dann wird die niemand verbauen - Da werden rucki zucki zig. Häuser "übernommen" und der Name Shelly landet dann oft im TV (mehr dazu unten)...
Komplett andere API
Die Definition einer API ist, dass diese immer abwärtskompatibel ist. Wenn man neue Features will, kann man eine API erweitern, muss aber IMMER dafür sorgen, dass die Abfragen auf die bisherigen Schnittstellen auch identische Antworten liefern (Uptime, Status etc.). Meiner Meinung nach war da bei Shelly jemand "faul" und dachte sich "Ach ich fang neu an - ist einfacher als zu erweitern und mein Stackoverflow sample sieht eh anders aus"
Geht gar nicht - so kriegt man externe Entwickler definitiv nicht dazu die Produkte zu implementieren und so wird Shelly nie über einen bestimmten Punkt raus wachsen können - mehr als Schade... Hoffentlich geht's da definitiv nochmal zurück ans Reißbrett...
Die "Default Settings" machen bei MQTT keinen Sinn
MQTT (wenigstens ist CoAP endlich tot denn es gibt die Option nicht mehr) hat per default den "General Status" auf "off" gesetzt.
Wer, der bei klarem verstand ist, würde sowas als Standard wollen? Besonders unerfahrene User (und das sollen lt. Werbespots ja 99% sein) möchten da ihren Server eintragen und dann "muss das alles laufen"TM... Die Frau aus dem "Werbespot" hat keine Lust "advanced" Settings zu aktivieren - das muss simpler gehen - keep it simple guys.
Auch hier: Meiner Meinung nach Schlampig gearbeitet - nochmal zurück ans Reißbrett...
Temperaturentwicklung
In meinem Test habe ich jeweils 4x 1PlusPM gegen 4x 1PM laufen lassen (ohne load) - damit man auch nen fairen Vergleich hat und nicht 1 defektes Gerät Werte verschlechtert.
Die 1"Plus"PM laufen im Schnitt zwischen 3 und 8! grad heißer.
Die werden normalerweise hinter Dosen verbaut (ohne Belüftung) - da machen 3 grad im gut belüfteten Raum ne Menge aus (tippe mal gute 10-13grad hinter der Dose mehr, teste ich aber fairerweise noch).
Selbst wenn die Geräte einiges aushalten, sollen die im Idealfall über Jahrzehnte laufen.
Dauerhaft statt z.B. 65 grad mit dann vermutlich 75 grad laufen ist für die Elektronik nicht gesund.
Auch wenn die lt. Datenblatt mehr "verträgt" ist Temperatur immer ein Problem bei elektronischen Bauteilen und jedes Grad senkt die Lebensdauer signifikant Mehr Power auf Kosten der Umgebungsvariablen ist ein schlechter Tausch...
AP-Modus bleibt aktiv obwohl man den Shelly ins eigene WLAN hängt
Hier ist als IT-Security Mensch meine ALARMGLOCKE angegangen - Nochmal: AAAAAAALAAAAAAAARM!!!Hat mal jemand über die Folgen so eines Settings nachgedacht?
Die Klagen die daraus folgen können?
Liebe Shelly Dev's: Wenn jemand Settings im Client-Mode einträgt, dann MUSS MUSS MUSS der AP-Mode sofort deaktiviert werden!
Ihr bridged sonst ein öffentliches "open" WLAN mit einem hochsicherheits IoT-Netz - das kann seeeeeehr teuer werden.
Selbst wenn das in meiner Version ein "bug" war - Nein und nochmal nein - darf niemals passieren!
So - genug geranted
Ich bin nach wie vor ein extremer Shelly Fan wie jeder wissen sollte, sonst hätte ich nicht mein ganzes Haus mit insgesamt knapp 300 Sensoren ausgestattet. Aber diese "Plus" line kommt mir nicht ins Haus
Schade - denn die Ankündigung sah super aus - ich hoffe einfach, dass das ein versehen war, jetzt schnell und zielgerichtet einiges geändert wird und die BETA beim nächsten mal so lange dauert, dass das finale Produkt auch sicher nutzbar ist.
Das Video dazu folgt dann wie gewohnt die Tage auf YouTube.
Wie sehr Ihr das? Habt ihr die Geräte im Einsatz? Oder durftet sogar testen? Sind einige meiner Kritikpunkte bereits adressiert worden?
Freue mich über Feedback
-
Hat irgendjemand schon etwas dazu gehört? Ich hatte Dimitar mal via Twitter "angefunkt" habe aber nie eine Antwort bekommen.
-
Ist alles privat (nur mein Haus + Garten + Garage). Ich hab halt jede Steckdose, jedes Licht innen und außen damit ausgestattet 😬😬 Dann noch jeder Raum dimmbar hier und da, mehrfachsteckdosen noch Plugs, hier und da ne Duo Birne, RGBWs, Rolläden und und und. Das addiert sich rucki Zucki - hab insgesamt fast 300 Devices verbaut
Ist aber ein super „Datenpool“ Vor allem mit n mal HT im Raum - könnte die zeigen, wie sich temp und feuchte im Raum verteilen wenn ich das Fenster öffne
Ja er hat nen AP aufgemacht - als wäre er resettet worden. Seitdem läuft er als wär nix gewesen - finde ich seeeeehr strange. Der ist ja in der Dose hinter der Steckdosenblende verbaut - und nach 10 Monaten bewegt sich da ja nix hoffe ich 😅
Ich behalte das mal im Auge - macht er das nochmal wird er getauscht. Wollte nur mal hören, ob da was bekannt ist oder jemand sowas schon mal hatte Hat dein i3 auch quasi 1x die Rückrolle gemacht?
-
Hallo zusammen,
eben ist mir ein Shelly 1PM im laufenden Betrieb komplett "ausgefallen" - hing nur mein Sky Reciever dran (relativ geringe load).
Kein Error in den Logs - alle Settings weg (hab die jetzt neu eingegeben und bisher merkt er sich die auch trotz reboot)...
Hat das schonmal jemand gesehen? Ein wenig spooky, dass ich so 0 Anhaltspunkte bekomme - gab keinen Stromausfall, Schwankung etc und nur einer von ca. 190 ist betroffen oO... Der lief jetzt knapp 10 Monate fehlerfrei.
-
Laut dem Facebook Banner gibt es am 15.09. was zu berichten ....
Nun ist dann die Frage was ist dabei:
- Die neue Cloud App ?
- Homekit für alle ?
- Mehr Alexa Features ?
- Shelly Smoke V2 ?
- Shelly Thermostat ?
- .... ?
Gerade wurde das Bild aktualisiert:
Könnte nach Shelly 1, Shelly 1 PM und Shelly 2,5 mit LAN Modul im Hutschienendesign aussehen
LG
AnF
Das sieht sehr nach einem Angriff auf KNX-Systeme aus
-
Hallo zusammen,
hat schon jemand was zur neuen Firmware für den Motion gehört?
Aktuell gibt es ja den Bug, der das Teil richtig durchknallen lässt wenn man die Web-UI mit einem Passwort sichert.
So ist das Gerät natürlich komplett unbrauchbar...
Es sollte ja eigentlich schon vor einiger Zeit ein Update kommen - lese aber irgendwie nix mehr darüber - hab ich was verpasst?
Grüße
-
Ich wollte auch niemandem was unterstellen - finde das Forum und die Leute hier super
Kann mir vorstellen, dass es viele Anfragen dazu gibt - hatte ich so noch nie drüber nachgedacht.
-
Sorry aber die Aussage "dann kauft euch was anderes" finde ich im Zusammenhang mit Smarthome-Geräten unnötig. Das "Smart" in Smarthome steht nicht für die Cloud eines Herstellers, dem ich meine Hausdaten nicht anvertrauen möchte (hier reden wir darüber, dass der Anbieter sogar Abläufe, Bewegungsprofile etc. aus den "Szenen" ableiten könnte). Nicht weil ich dem Hersteller selbst nicht vertraue (sonst würde ich die Produkte ja nicht kaufen) sondern weil ich glaube, dass jeder größere Anbieter von IoT-Geräten früher oder später geknackt wird.
Und dann steuert Väterchen Russland oder Genosse China plötzlich mein Haus...
Lokal entscheide ich, was ich wann an patches einspiele, wann ich Kommunikation nach außen erlaube und wann eben nicht.
Einen Shelly im heimischen, separat zonierten IoT-WLAN zu haben mit einer einzigen Anbindung in Richtung lokalem "Brain" (ioBroker o.ä.) um den von dort aus ebenfalls mit Szenen, Messaging etc. in Richtung Home-LAN sprechen zu lassen ist nicht nur absolut valide sondern auch exorbitant sicherer im Vergleich zu "lass den mal ins Internet reden" - mal abgesehen davon, dass ich in einem solchen System sogar Systeme verschiedener Hersteller koppeln kann, was vom jeweiligen Anbieter nie geplant war - und so kann der Shelly wenn ich die Gartenpumpe einschalte dem Gardena-Roboter signalisieren, jetzt nicht den Rasen zu mähen - zeig mir das mal per Cloud-App mit 3rd Party
Es ist 2021 - Wir sind über die Blauaugenphase "das geht schon gut" hinaus - IT-Security muss heute mehr können als nur ne App bereitzustellen - alles andere wäre naiv und fatal...
Sobald Shelly (oder Hersteller xyz) mir per Verschlüsselung (IPsec o.ä.) garantieren kann, dass selbst der Kanal in Richtung "Cloud" (auch nur ein anderer Server) vollumfänglich, abhörsicher und vorallem fälschungssicher dauerhaft von jedem Sensor genutzt werden kann, kommt die Cloud als Benefit wieder in Frage (aber auch nur, wenn die Daten im jeweiligen Land bleiben und eben nicht auf Azure, AWS oder GCP).
SSL zählt nicht (viel zu leicht manipulierbar) - mir wird immer schlecht wenn ich Sensoren durch ein Security-Audit jage (ist bei allen Herstellern desolat).
Solange es für die ESP's (die ja auch von Shelly genutzt werden) keinen IPsec-Stack o.ä. gibt hat sich das erledigt - darum ist die einzig sichere Variante aktuell: Shelly komplett isolieren und ausschließlich "Steuertraffic" in Richtung lokalem Controller erlauben - der spielt dann die Musik.
So nutze ich alle Benefits des Shelly (API, MQTT Befehle etc.) habe aber wenn mal ein Sensor "abhanden kommt" nicht direkt das gesamte System mit 200 Sensoren gekapert, sofern jeder Sensor auch eigene Secrets erhält, eigene private PSK's fürs WLAN usw. Dort kann ich dann Szenen anlegen, Geräteklassen koppeln - selbst weit über das hinaus was der Anbieter bereitstellt.
Eine Cloud für unkritische Bereiche zu nutzen ist Cool und Sinnvoll für den "Mainstream" - aber Leute zu "verurteilen" weil Sie sich um Sicherheit bemühen und das dann auch noch als Lexikonartikel zu pinnen finde ich ein falsches Signal. Denkt mal drüber nach ob ihr das nicht wieder "lösen" wollt.
Würde ich Shelly nicht bereits Hammergeil finden und als neues Mitglied über diesen Eintrag stolpern würde ich direkt wechseln und damit uns allen schaden. Denn wenn keiner mehr shelly's kauft, dann ist halt irgendwann auch die Cloud "aus"
Wie gesagt - nur meine 2ct.
-
Same here. The Sensor was updated, now blinks in all sorts of color, is unable to reset, randomly responds to ping, web interface not usable at all...
Really disappointed so far
The Motion is nothing but problems in my network unfortunately and that means that I will soon start looking for alternatives
-
das mit den Endpunkten hab ich oben beschrieben, weil hier immer mal wieder Unklarheiten herrschen, wann man das & benutzen kann um Parameter miteinander zu verknüpfen..
ich versuche es mal anders, eventuell wird es dann logischer.
Die API hat unterschiedliche Endpunkte. Beispiele dafür:
/status
/settings
/shelly
/settings/relay/0
/roller
Jeder dieser Endpunkte ist ein in sich geschlossener Bereich.. ich kann also nicht gleichzeitig eine Einstellung im Berech /settings und /settings/relay/0 ändern, indem ich sie über das & miteinander verknüpfe..
Aber:
In deinem Fall willst du 4 Einstellungen (nur 3 davon sind notwendig) gleichzeitig ändern. Diese liegen alle im selben Endpunkt /settings..
Daher funktioniert der Aufruf problemlos, man kann die Werte gleichzeitig übergeben.
http://192.168.178.220/settings?wifirecovery_reboot_enabled=1&coiot_enable=0&ap_roaming_enabled=1&ap_roaming_threshold=-70
wifirecovery_reboot_enabled=1 aktiviert den Soft-Reboot
coiot_enable=0 schaltet CoIoT aus
ap_roaming_enabled=1 aktiviert das Roaming
ap_roaming_threshold=-70 setzt den Schwellwert auf -70
1000000 Dank für die geniale Erklärung
-
-
Unterschiedliche API-Endpunkte lassen sich definitv nicht miteinander verknüpfen.. Da die aber in einem Endpunkt liegen geht das problemlos..
4) CORS ist von Hause aus deaktiviert, daher hab ich das mal weggelassen..
..../settings?wifirecovery_reboot_enabled=1&coiot_enable=0&ap_roaming_enabled=1&ap_roaming_threshold=-70Verstanden
Also müsste man für jeden "Baum" ne eigene Abfrage generieren, korrekt? -
Salve,
hat schon jemand von euch mit den API's rumgespielt und "API-Chaining" genutzt? Also mehrere Optionen in einem einzigen API Call?
Mit dem Update auf 1.10 müsste ich für knapp 160 Geräte in die WebUI - fällt also weg.
Hier im Forum sind so viele geniale Köpfe unterwegs - da hat doch bestimmt schon mal jemand experimentiert
Will per API-Call folgendes erreichen:
1.) CoIoT komplett deaktivieren - nur unnötiger Traffic wenn man eh ausschließlich MQTT nutzt
2.) Soft reboot when WiFi connection is lost aktivieren (Enable reboot setzen) - Kinderkrankheit mit der Shelly danach den AP-Modus öffnet ist ja jetzt gefixed, das Feature also sogar nutzbar
3.) Roaming bei RSSI -70dbm aktivieren - genial wenn man mal einen der zig AP's im Haus auf Wartung setzen muss
4.) Allow Cross-Origin Resource Sharing abschalten - bringt keinen Nutzen in meiner Umgebung und was man nicht nutzt sollte man abschalten
Könnte jetzt für jeden Befehl einzeln losrennen - wäre aber cool, die 4 Settings in einem einzigen Call loszuwerden - hat das schon mal jemand gemacht?
Grüße
Christian -
Hab mal meine unkritischen Teile des Hauses auf 1.10 geupdated - bin aber was updates angeht auch sehr vorsichtig geworden nach den ganzen Kinderkrankheiten der letzten 3-5 Updates
Bisher alles gut - mein AP hat ja ohnehin nie Probleme gemacht (ist halt Qualität, was Juniper da baut) - werde berichten, wie das in der nächsten Woche läuft
-
habe die OT-Plaudereien mal in ein separates Thema verschoben.
aus ein bisschen OT wurden ja doch schnell 20 Beträge die nichts mehr mit den FW-Release zu tun hatten.
Thementitel kann je nach Wunsch noch angepasst werden
-
das hört sich sehr interessant an
Kannst du mal ein Diagramm oder Aufzeichnungen posten
Oder deine Erfahrung/Ergebnisse mitteilen.....
Aber sicher - ich bastele mal was zum sharen
-
Vermutlich soll damit dokumentiert werden, wie man am effektivsten sein Haus mit Shellies heizt.
Dazu meine Frau:
Kann die Fußbodenheizung ja wieder raus - die Wände heizen ja mit genug Kupfer
Sind ja nicht nur die Shelly's - hab ja auch noch "ein wenig" LAN Kabel und Glas-Kabel (gut ohne Hitze) gezogen Das Holzhaus ist technisch gesehen inzwischen quasi ein Kupferhaus -
Die reine Menge kann man in einem entsprechenden Haus schon unterbringen. Ich bin bei mir auch bei über 100 Temp.-Messungen und bald 100 Shellys und da kommen sicher noch ein paar dazu.
Aber wenn man das Alles rein auf Shelly-Basis aufbaut, dann ist man entweder absolut "Shelly-hörig" oder man hat zu viel Geld.
Ca. 1.200€ allein für die AddOn's und Sensoren (falls die Sensoren auch über Allterco gekauft wurden) plus nochmal ca. 1.300€ für die Shelly 1PM.
Mit D1-Mini's bräuchte man nur 35 statt 92 Stück für 276 Temp.-Messungen und das Ganze gäbe es für die Hälfte des Preises. Wenn man sowieso ein übergeordnetes System (in diesem Fall ioBroker) einsetzt, dann ist die Technik letztendlich egal. Ob chris929 tatsächlich auch alle 92 Shelly 1PM als Aktoren benötigt weiß ich zwar nicht, aber wenn nicht wäre da evtl. noch Einiges an Einsparungen möglich.
Jepp - bin Shelly-positive War tatsächlich einer der größeren Posten beim Hausbau - ist aber echt geil
-