Du denkst an den JTAG Test…
Ja genau. Hast du dazu Equipment und schon einmal genutzt?
Beiträge von eiche
-
-
Es darf vermutet werden, dass der Chip einen Pin besitzt, über welchen der Zugriff auf seine Interna, zumindest Speicher, per anderer Pins möglich wird.
Dazu müsste entweder eine klammernde Fassung aufgesetzt oder der Chip ausgelötet ... werden.
Solches möchte ich Thomas nicht wirklich zumuten.
Außerdem sind hierzu vertiefte Kenntnisse über den Chip erforderlich.
-
Da aber der enabled Status im nichtflüchtigen Speicher abgelegt sein muss, könnte dessen Lokation vielleicht gefunden und geändert werden.
Das wäre vermutlich eine Detektivarbeit und ggf. zu aufwändig, aber vielleicht nicht unmöglich.
Die Entwickler werden eine solche Arbeit nicht tun wollen, weshalb einer solchen Äußerung in ihrer Absolutheit nicht vertraut werden muss.
-
Ok, ich meinte die Nutzung von Tastern. Inzwischen habe ich dies in #13 ergänzt.
-
Ob die Nutzung von Tastern statt Schaltern bereits per Actions gelingt, müsste ich erst testen, wozu ich derzeit keine Gelegenheit habe.
Mit einem relativ kleinen und einfachen Skript geht so etwas selbstverständlich.
Falls dies per Actions gelingen kann, wären für jeden von zwei Tastern zwei Actions erforderlich, beide mit unterschiedlichen zusätzlichen und komplementären Bedingungen.
Prinzip für einen Taster zum öffnen:
Wenn kurzer Tastendruck und Rollladen derzeit öffnet => anhalten
Wenn kurzer Tastendruck und Rollladen derzeit steht => öffnen
Btw, in einer Leerdose lassen sich auf diese Weise Taster zum steuern zweier Rollladenantriebe unterbringen oder es stehen noch zwei Taster für beliebige andere Funktionen zur Verfügung. Ich halte dies für bestechend.
-
Ihr seht, dass ist schon aufwändig
Nö
Selbstverständlich ist mir bekannt, dass du weißt, was du codest.
Ich habe deine Skripte nun nicht analysiert. Trotzdem die Fragen:
- Ist es erforderlich, dass nach dem Booten alle Skripte zugleich gestartet werden?
- Könnten nicht zunächst zwei Skripte laufen? Das Konfigurationsskript könnte dann beendet und stattdessen ein Skript oder mehrere andere Skripte gestartet werden. Wir beide wissen, dass du ähnliches bereits gecodet hast.
Wie du siehst, halte ich deine Einwände für (zunächst) nicht ganz überzeugend, sorry.
-
und nicht wie z.B. bei einem Taster die Wippe für runter/hoch so lange drücken will, bis die Stellung erreicht ist
Wie Schubbie bereits mitteilte, ein solange drücken, wie der Rollladen bewegt werden soll ist
- nicht erforderlich und
- eher unbequem und
- weniger ergonomisch als das Anhalten per erneutem Tastendruck.
Das möchten wir halt gern so, weil das überall im Haus so ist.
Es ist verständlich, eine gewohnte Handhabung beibehalten zu wollen. Dann wirst du aber den Vergleich mit der reinen Tasterhandhabung nicht erleben können. Deshalb und wegen der Bedienvorteile per Taster empfehle ich so wie Schubbie auch, an einer Stelle die Taster zusammen mit einem Shelly i4 zu installieren. Vermutlich werdet ihr feststellen, dass die Tasternutzung recht intuitiv ist und evtl. diese sogar bevorzugen.
-
Ich kann solche Screenshots nicht gut verstehend lesen. Deshalb meine Fragen.
- Welcher Shelly soll einschalten? Der 3 EM selbst?
- Hast du eine Szene, die bedingt ausschaltet, wenn eingeschaltet ist?
-
Kann man da noch ein Delay einbauen, dass der Prozessor im Fehlerfall nicht ausgelastet wäre
Ja klar. Man kann einfach einen Timer erstellen, der bspw. alle 100 ms den Status abfragt und bei Erhalt der Konfiguration den Timer löscht. Das ist sehr einfach zu implementieren.
Um es konkreter zu beantworten.
Code// Michaels Fehler while(v.endpoin === undefined){}; // Die erwähnte Timer Sequenz mit dem Schreibfehler let Th = Timer.set(100, true, function() { if(v.endpoin !== undefined) Timer.clear(Th); });Der Timer pollt schlicht die Existenz eines gültigen Eintrags und beendet sich, wenn der Eintrag vorliegt.
Ich habe den Timer-Code noch etwas schlanker gestaltet.
... und inzwischen noch ein wenig robuster, für den Fall dass v.endpoint mit null initialisiert wurde.Sorry, war unsinnig ...
-
Interessant. Dazu habe ich folgende Fragen/Vermutungen/Vorschläge.
- Du speicherst die Konfiguration in einer non-executable Skript Datei? Oder vielleicht doch im KVS?
- Warum lässt du diese nicht einfach per Aufruf get_file() in v laden und lässt dies periodisch wiederholen?
- Hast du mal darüber nachgedacht, die Konfigurationsfdatei executable zu machen und bspw. eine Kommunikationsfunktion "get_config()" darin unterzubringen, die per Methode "Script.Eval" aufgerufen wird und einfach das Konfigurationsobjekt als Resultat liefert?
- Alternativ zu 3. könnte das Konfigurationsskript mit seinem Start ein Event auslösen, welches vom EventHandler deines Arbeitsskripts empfangen und die übertragenen Konfigurationseinträge in v gespeichert werden.
- Dass an entscheidenden Stellen v auf Gültigkeit geprüft werden kann und der Robustheit wegen auch sollte, versteht sich eigentlich von selbst, oder?
Trotz alledem ist das Firmware Feature wie wir wissen zumindest nicht hinreichend implementiert, was aber inzwischen müßig ist, dies wiederholend festzustellen.
-
In another context (Node-RED, Arduino IDE) I found this note. A workaround could be to send the following message after a reconnect.
topic: shellytype-MACaddress/online
payload: true
I haven't tested it yet.
When I reboot the Shelly via Web UI, then I immediately receive the message online false via MQTT and online true about 2 seconds later. This is probably only possible with a good WiFi connection.
-
The smart control app is not very reliable.
You should use the Web UI instead.
-
Ich glaube, dass die Funktion dieses Dings dokumentiert ist.
-
Ich nutze in diesem Zusammenhang kein Bluetooth Gerät.
Kann ich damit z.B. ein Script schreiben, mit dem ich den Shelly schalte, wenn ein bestimmtes Bluetooth-Gerät (z.B. Smartphone) in Reichweite kommt?
Vermutlich geht auch solches. Aber zunächst wird ein Skript benötigt, welches ein Bluetooth Gerät erkennen kann und dessen Nachrichten in das WLAN überträgt.
Es gibt auf github ein bereits dafür geeignetes Skript, in welchem man für eigene Zwecke nur den Konfigurationsteil ändern bzw. anpassen muss.
Dieses Skript macht den Shelly Plus 1 zu Gateway Bluetooth --> WLAN, aber afaik nur für ein Bluetooth Gerät. Für bspw. 3 solcher Geräte kann man das Skript dreimal speichern, anpassen und starten. Ob dies auch in einem einzigen Skript gelingt, weiß ich mangels Erfahrung nicht.
Das Skript: https://github.com/ALLTERCO/shell…ther-devices.js
Was bedeutet RPC in diesem Fall genau?
RPC = Remote Procedure Call ist in der Dokumentation recht ausführlich beschrieben. Wenn man das Prinzip einmal verstanden hat, ist es relativ leicht anzuwenden.
Afaik muss man zum konfigurieren eines Shelly Blu Gerätes die App verwenden. Vermutlich kann man damit auf dem Blu Gerät die gewünschten RPC eintragen.
-
I've read the documentation again. Then I tested LWT with a Shelly Plus Plug S. As broker I used test.mosquitto.org:1883.
When I plugged in the Shelly, after a short time of 2 or 3 seconds I received the online message with the payload "true".
When I unplugged the Shelly, after about 90 seconds I received the online message with the payload “false”.
I suspect that this will work reliably if the supply is lost.
Occasionally the value "false" was displayed when trying with an unreliable connection.
I suspect that the cause of this behavior is due to a better or worse connection and cannot be eliminated.
Btw, on my Shelly Plus Plug S the topic looks like “shellytype-MACaddress/online” without the word “status”. It should be the same in your Shelly.
-
Ich schaute mir die MQTT Kommunikation per Firmware noch genauer an.
Wenn man in der MQTT-Konfiguration das Prefix ändert, dann gelingt die MQTT-Kommunikation unter Verwendung dieses Prefix.
Bsp.: Prefix = "mein/prefix"
Damit lautet das Topic, mit welchem man einen RPC Kanal des Shelly nutzen kann "mein/prefix/rpc"
Die Antwort des Shelly beinhaltet in der Payload als "src"-Wert trotzdem den von der Firmware vorgegebenen Prefix, welcher mit der MQTT Client Id übereinstimmt.
Dies tut er auch dann noch, wenn man diese Client Id ändert. Man kann somit den "src"-Wert in einer MQTT-Antwort nicht ändern. Dies erscheint mir als nicht konsequent.
Das muss dich nicht weiter stören, es kann aber verwirren, wenn man mit diesen Konfigurationseinträgen experimentiert.
-
Heißt, wenn ein Durchgang da ist, ist der Reed okay?
Nein. Der Reed-Schalter ist dann ok, wenn er mal aus und mal ein ist. Wenn er also mal Durchgang hat und mal nicht.
Für einen Test kannst du mal Wasser fließen lassen.
Deine teilweise eingekreiste grün hinterlegte Anzeige sagt vermutlich nur etwas über einen von dir zu konfigurierenden mathematischen Ausdruck aus.
Dieser Ausdruck steht ja darunter.
Da ich (mal wieder) so etwas nicht habe, kann ich leider nicht mehr dazu sagen.
-
Willst du IP Adressen sparen?
Hast du so viele Geräte, dass dein Vorrat an IP Adressen knapp wird?
Es ist selbstverständlich deine Sache, wenn du unbedingt Bluetooth verwenden willst. Ich verstehe aber nicht warum?
-
Ich habe keine solche Ausstattung, mit welcher ich dies alles testen könnte, daher meine leicht kritische Frage:
Gelingt so etwas nicht per Actions?
Actions hätten den Vorteil, dass sie lokal verarbeitet werden, also das ganze Cloud-Gedöns nicht brauchen. Und was lokal arbeitet, arbeitet i.d.R. zuverlässiger.
Zusatzbemerkung:
Ich täte so etwas mit einem Shelly Pro 3EM und einem lokal arbeitenden Skript lösen. Das ist allen anderen Lösungen an Funktionssicherheit überlegen. Ok, die meisten mögen keine Skripte. Das ändert aber nichts an deren Überlegenheit.
Und ein eigenes Smart Center kann alles besser und zuverlässiger als diese Cloud. UnfluxDB, Grafana, ...
-
Do you know the script method MQTT.isConnected() or the using of a MQTT got connection handler - registration via MQTT.setConnectHandler(...)?
Perhaps those can fix the issue.
