Beiträge von JuergenAC

Zum einen ist es ein schlechter Programmierstil Variablen mit gleichen Namen zu vergeben, wie Befehle, fixe Begriffe etc.

Bsp url: url

Dann rufe doch mal im Browser die Adresse mit einer beliebigen huminity auf.
Da du http get verwendest ist das kein Problem.
Dann kannst du sehen ob dein Server / Gegenstelle die Anfrage überhaupt verarbeiten kann.

Meinst Du sowas:

function FuncShellyCall(body_string_v) {
  Shelly.call(
    "HTTP.POST",
    { url: server_url_c,
      content_type: "application/x-www-form-urlencoded",
      ssl_ca: "*",
      timeout: 20,
      body: body_string_v,
    },
    function (result, err_code, err_message) {
      if (err_code !== 0) print(err_message);
      console.log("Pushed result", JSON.stringify(result));
    }
  );
}

server_url_c ist die Serveradresse:
https://www.domain.de/cgi/script.pl

body_string_v ist die Payload:
also dass, was hinter obigem Script steht.

OK, sieht schlüssig aus.

Danke Dir, werde das mal testen.

Also, der unten stehende (einfache) Code der function funktioniert seit Monaten einwandfrei.
Auch mit dem Passwort habe ich keine Probleme. Hier im Quelltext ist "passwort" ein Dummy.

function FuncLoadDataCHB() {
 //Systemwerte laden und zuordnen
 unixtime_v = Shelly.getComponentStatus("sys").unixtime;
 // hole von ShellyPlus1PM (IP: 192.168.2.9) BKW max_act_power 
 // aus https://www.smarthome-forum.eu/thread/26462-auslesen-von-apower-von-einer-andern-shelly/
 Shelly.call('http.get', {
   url: 'http://admin:passwort@192.168.2.9/rpc/em1.getstatus?id=0'
   },
   function(response) {
    let res = JSON.parse(response.body)
    max_act_power_bkw_v = res.act_power;
   }
  );
  // Basis Shelly: Energiemesser CH A (EM1:1)
 avg_voltage_v = Shelly.getComponentStatus("EM1:1").voltage;
 avg_current_v = Shelly.getComponentStatus("EM1:1").current;
 max_act_power_hs_v = Shelly.getComponentStatus("EM1:1").act_power;
 max_aprt_power_v = Shelly.getComponentStatus("EM1:1").aprt_power;
 // Hausleistungswert mit BKW-Wert korrigieren
 max_act_power_v = max_act_power_hs_v + max_act_power_bkw_v;
 // nur zum Debug: print("SumPower:"+max_act_power_v+" HausPower:"+max_act_power_hs_v+" BKWPower:"+max_act_power_bkw_v );
 // Systemwerte einbinden
 system_v = 'timestamp='+unixtime_v+'&shellyname='+shellyname_c+'&shellytyp='+shellytyp_c;
 channel_v = 'channel_name='+channel_name_b_c+'&channel=B';
 power_v = 'max_act_power='+max_act_power_v+'&max_aprt_power='+max_aprt_power_v;
 voltage_v = '&avg_voltage='+avg_voltage_v;
 current_v = '&avg_current='+avg_current_v;
 // String verketten
 bs2_v = system_v+'&'+channel_v+'&'+power_v+'&'+voltage_v+'&'+current_v;
 return bs2_v;
}

Ein Pro 50 EM holt die Leistungsdaten aus einem Plus 1 PM und verrechnet die.

Die Stringverkettungen sind hier nicht weiter von Belang, die Benötige ich zum Aufruf eines Webservers.

Es geht mir hier NUR um den Shelly.Call, den ich gerne absichern möchte, mit dem TRY den Du empfiehlst.

 try {
   Shelly.call('http.get', {
     url: 'http://admin:passwort@192.168.2.9/rpc/em1.getstatus?id=0'
     },
     function(response) {
      let res = JSON.parse(response.body)
      max_act_power_bkw_v = res.act_power;
	  throw "vaild";
     }
    );
   } catch (e) {
     if (e != "valid") {
      max_act_power_bkw_v = 0;	 
	 }
    }
   };

Hallo HighFive

Du verlinkst weiter oben "TRY / CATCH. Erklärung".

Der Link führt aber zu einem Tutorial von JAVA und nicht zu JAVASCRIPT!

Der richtige Link nur zur Vollständigkeit halber ist https://www.w3schools.com/js/js_errors.asp
Ist aber auch hier zu finden: https://wiki.selfhtml.org/wiki/JavaScrip…ehlerbehandlung

Ein Error Handling zum Abfragen anderer Shellys im Netzwerk halte ich für sehr wichtig, auch weil bei mir manchmal zu viel Trafik im Netz ist und das eine oder andere IP Paket verloren gehen kann.

Mir bleibt dennoch die Frage, ob dich das Error-Handling richtig verstanden und umgesetzt habe

// hole von ShellyPlus1PM (IP: 192.168.2.12) BKW max_act_power 
 // aus https://www.smarthome-forum.eu/thread/26462-auslesen-von-apower-von-einer-andern-shelly/
 // aus https://shelly-forum.com/thread/27195-too-many-calls-in-progress/
 try {
   Shelly.call('http.get', {
     url: 'http://admin:passwort@192.168.2.9/rpc/em1.getstatus?id=0'
     },
     function(response) {
      let res = JSON.parse(response.body)
      max_act_power_bkw_v = res.act_power;
	  throw "vaild";
     }
    );
   } catch (e) {
     if (e != "valid") {
      max_act_power_bkw_v = 0;	 
	 }
    }
   };

Der obige Script-Teil läuft auf einem Pro 50EM und muss zur Korrektur von Leistungsdaten, den Actual Power des BKW holen.

Es ist absolut wichtig einen Validen Wert in der Variable max_act_power_bkw_v zu haben, auch wenn der nur "0" ist.

Verbesserungen?

Danke und Grüße

Jürgen

Hallo,

ich schlage mich gerade mit http_endpoints rum.

In diesem Threat von User @_[Deleted]_ Einfache Script Beispiele

habe ich den HTTP Endpoint getestet.

Ich muss aber den Shelly per Passwort ansprechend, weil die alle per Authentifikation geschützt sind.

Ich bekomme dann aber einen 401er vom shelly.
Ich habe dann den Shelly Support angeschrieben und der antwortete, dass das auch so gar nicht geht, weil man

Zitat

"Grundsätzlich sind aus Sicherheitsgründen nicht alle Endpunkte des Shellys für eine einfache Authentifizierung ausgelegt.
Ein Relais ein oder ausschalten wäre z.b. darüber möglich.
Um entsprechend den Endpunkt eines Scriptes aufzurufen müssen Sie sich entsprechend per digest Auth Authentifizieren.
https://shelly-api-docs.shelly.cloud/gen2/General/Authentication"

Auf Rückfrage dann spezifischer

Zitat

"Wenn die Authentifizierung abgeschaltet ist gibt es entsprechend auch keine Authentifizierungsabfrage und alle Endpunkte sind offen zugänglich.
Wenn Sie diese aktivieren gibt es einige Endpunkte wie das Schalten eines Relais welches über die unsichere Basic Authenfizierung möglich sind. Alle anderen Endpunkte wie z.b. einen Webserver eines Scriptes sind nicht für die Basic Authentifizierung zugänglich sondern benötigen entsprechenden Aufruf über die Sichere Digest Authentifizierung!"

Könnte bitte mal einer von Euch das Original Script (aus dem Threat) testen? Mal mit und mal ohne Passwort.
Ohne PW geht es bei mir.

Danke

Jürgen

auch wenn der Threat schon was älter ist, möchte ich mich kurz anhängen.

Ich habe die Quellen von eiche genommen und für meine Zwecke abgeändert.

Das funktioniert so wie es auch eiche erklärt und dargestellt hat.

Mein Problem ist, dass ich die Shellys alle Passwort schützen muss.
Damit kann ich zB http://192.168.0.25/script/2/data nicht ausführen.
Versuche mit http://admin:PASSWORT@192.168.0.25/script/2/data funktionieren nicht und der Shelly quittiert den Aufruf mit nem 401er.

Natürlich wurde auch
dataURL = 'http://admin:PASSWORT@'+localip+dataep('data',data);
angepasst.

Jemand eine Idee?

Habe da mal versucht draus schlau zu werden.

Muss man bei den Shelly X wirklich diesen Konfigurator nutzen (ShellyXDashboard) nutzen?
Ich hätte gedacht, wie bei allen anderen Shelly, einschalten per WIFI-AP verbinden, Shelly einrichten, Script aufspielen, fertig.

Dann verstehe ich nicht, warum die keinen Analog In, I2C, SPI, etc als zB gemultiplexte Pins am Shelly-X-MOD1-H8 zur Verfügung gestellt haben.
Damit hätte ich direkt tolle Anwendungsmöglichkeiten. Jetzt nur ein paar Inputs oder Outputs.

Oder habe ich da grundsätzlich was falsch verstanden. Die Anleitungen sind ja auch noch recht Buggie.

Thomas, dass war ein fliegender Aufbau und ich habe mir keine Mühe gegeben, die Schirmklemmen der Tastköpfe „schön“ anzuschließen.

Es geht aber nicht um die Spikes auf der gelben Linie, sondern den bis auf Null in der roten Linie. Auf der war auch der trigger gesetzt.

So, ich habe mal die Schaltung von Thomas thgoebel im Labor getestet.

Mit einem billigen Fenster Reedkontakt, so wie ich ihn am Gaszähler installiert habe, und einem Shelly Plus Uni FW V1.44.

Wenn man mit dem Magneten sehr langsam am Reedkontakt vorbei führt, passiert ab und an unten stehendes Verhalten:
(Gelb ist an Count-Pin, Rot am Reedkontakt)

Zoom:

Da kann man gut erkennen, dass der Reedkontakt zweimal schaltet. Einmal ganz kurz und dann nach 35us dann richtig.

Dieses ab und an doppelt pulsen bekommt der Plus Uni mit und zählt dann unregelmäßig zu viel.

Werde die Schaltung nun am lebenden Objekt testen.

Wenn ich mich richtig erinnere, hat der Hoymiles zwar 4 Strings, aber die Abregelung auf 800 Watt wird proportional auf die vier MPPTs verteilt und nicht einzeln pro String.

Ich habe den preiswerten Türkontakt Reed-Kontakt von Shellyparts eingesetzt. Habe auch Versuche mit dem Abus gemacht, der ging aber noch schlechter.

Problem ist, dass der Plus Uni unregelmäßig, also kein konstanten Offset, mehr zählt, also sich der Gaszähler dreht.
Habe dann zuerst gedacht, dass das 5 m Kabel zum Shelly zu lang ist und es zu unangenehmen Schwingungen kommt.

Habe dann bei mir im Labor einen Versuchsaufbau gemacht, der wie folgt aussah:

Plus Uni mit Netzteil, gleich langem Kabel und gleichem Türsensor verdrahtet.

Funktionsgenerator mit einem Print Relais verschaltet und den Sensor so angeordnet, dass das magnetische Feld der Relaispule in Richtung des Sensors zeigt.

Den Funktionsgenerator auf 10 Hz geschaltet und den Uni geresetet.

Das ganz ne halbe Stunde laufen lassen.

Und siehe da: der Uni zeigte exakt den Count an, den ich für eine halbe Stunde 10 Hz ausgerechnet habe.

Der Messfehler muss von der Anbindung am Gaszähler kommen.

Also Durchgangsprüfer am adaptierten Sensor angeschlossen und darauf warten, dass der Brenner Gas zieht.

Alle 10 der letzten Stelle gibt es ein Signal. Ich vermute, dass dieses langsame Schalten im Schaltmoment Schwingungen erzeugt.

Geplant ist eine Monoflop Digitalschaltung zwischen dem Sensor und dem Shelly.

Zitat

Sag mal woher kommst'n du?

Aachen.

Ab das ist nicht das Problem. Das Problem ist, dass der Heizungsraum im Keller ist und die Signale durch einen Lichtschacht kommen müssen.

Zitat

Vielleicht hat dein Modem/Router einen Push-Service

Äh, bei jedem IP Paket wird die öffentliche IP Adresse mit geliefert. Die speichere ich auch jedesmal mit in eine Datei.

Habe aber irgendwo mal gelesen, dass die sich deutlich häufiger ändert als bei DSL Anschlüssen.

Habe das noch nicht getestet. Steht noch auf der todo Liste

Zitat

??? Netzwerk bedeuted verteilte Ressourcen. Daher ist der Ort vollkommen egal solange du auf irgendeiner Protokollebene für Erreichbarkeit sorgst.

Weiter oben stand „Mobilfunkmodem“ als Gateway. Die Verbindung ist meistens nur GPRS, ab und an 4G mit geringer Bandbreite. Und ich bin auch nicht sicher, ob DynDNS überhaupt gehen würde.

Also total unstabil für eine externe Regelung.

Danke Dir Detlef für die Extras aus der letzten Bestellung.

Von Weisshaupt gibt es solche Solar-Heizstäbe mit 1,5 Zoll Gewinde und in mehreren Leistungsklassen.

Ein interessantes Produkt, für Überschussanwendungen.

HighFive

Zitat

Du lässt dir gerne einen Bären aufbinden? Was du oben von dir gibst ist doch grober Unfug.

OK, bin offen für falsches Wissen.

zu MQTT: Was ich jetzt nochmal recherchiert habe
in https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Mqtt/ steht unter
Step 10: Generate periodic updates over MQTT using Shelly Script
das man anscheinend doch periodisch Daten per MQTT versenden kann.
Das hatte ich hier im Forum mehrfach mal anders gelesen.

zu HomeAssitent: Das kann ich natürlich auch auf einem RasPI installieren.
Da ist nur die Frage, an welchem Ort soll der sein?
Im Heizungskeller? Da käme ich von außen nicht gesichert dran, könnte aber Regelungen/Steuerungen ausführen lassen.
Bei mir im Büro? Da könnte ich keine Regelung bzw. Interaktion mit dem Heizungsraum von Außen gesichert durchführen.

HomeAssitent und alles was Cloud heißt, wo ich nicht Herr der Daten und Technik bin, ist für mich inakzeptabel.

MQTT ebenfalls nicht, weil das notifying nur nach Datenzustandsänderung erfolgt.

Ach jetzt sehe ich erst was ich falsch gelesen habe:

da steht "< 500ms erhöhte Crashneigung",

gelesen habe ich aber "> 500ms erhöhte Crashneigung".

Ich habe diverse Temperatursensoren an der Heizungsanlage, deren Temperaturverlauf <tagsüber> innerhalb eines Toleranzbandes liegen sollen.

Kann also nicht zu einem beliebigem Zeitpunkt folgendes machen:

if (actual_temp > max_temp OR actual_temp < min_temp) then do irgendwas ...

Ich kann mir auch keine Tabelle (array) im Shelly hinterlegen, die 2 * 1440 Werte aufnimmt (pro Minute ein Wert mit unterer und oberer Grenze)

Auf dem Webserver (in einer Datenbank-Tabelle) sind all die Dinge hinterlegt. Da hätte ich kein Problem. Komme dann aber nach der Auswertung nicht mehr zurück in den Heizungskeller. Da hängt ein Mobilfunkt Modem, mit ständig wechselnder IP (OK eine DynDNS habe ich mir zwar schon gebaut, aber noch nicht getestet und traue dem Braten aber auch nicht.)
Da wäre mir eine lokale Lösung im Heizungskeller deutlich lieber als über den Umweg Shellies -> Modem -> Webserver -> Datenbank -> Auswertescript -> Modem -> Shelly

HighFive

„Zyklisches Programm(Script) < 500ms erhöhte Crashneigung“

Genau das ist ja Abhängig von der CPU Geschwindigkeit und sicher auch noch von anderen Parametern.

Ich glaube die richtige Fragestellung wäre:

Sind in allen Shelly (ausser die aus Gen1) die gleiche CPU und gleiche CPU-Taktfrequenz verbaut?

Priamos

Ich weiß aus anderen Diskussionen, dass du da viel mit Tasmota gearbeitet hast. Habe aber persönliche Bedenken, dass ich damit klar komme. Aus Programmier Sicht schlage ich mich beruflich mit Assembler auf 8 Bitter und PERL auf Webservern rum. Dann eher privat mit Javacript.