openhabforum.de

mad-mike hat geschrieben: ↑19. Feb 2023 02:10 Hat das Gerät denn eine art Überschuss Regelung schon mit integriert oder wird das mit einer Rule gelöst?

Der KEMO ist nur ein Regler, die Intelligenz muss man in einer Rule bauen

mad-mike hat geschrieben: ↑19. Feb 2023 02:56 Kann ich auch einen 2000 Watt Dimmer nehmen, um einen 2000watt heizstab zu regeln?

LCN hat auch einen Hochleistungs Dimmer wo 2 Ausgänge hat und jeweils 2kw gedimmt werden können. Phasen Anschnitt und ohmsche Last ? Spricht da was gegen?

Mir fällt nichts ein, was dagegen spricht. Ich habe damals den KEMO als erstes gefunden, Preis Leistungs Verhältnis hat auch gepasst. Aufpassen muss man nur, wenn man Motoren regeln möchte, nicht jeder Leistungsregler kann mit Motoren umgehen.

Grundsätzlich sollte das egal sein. Ein Dimmer ist ein Dimmer

der Heizstab ist eine Ohmsche Last, quasi kein induktiver Anteil, Phasenanschnitt sollte also in Ordnung gehen. Dimmer in dieser Größenordnung müssen auch extra entstört sein (die kleinen auch, aber bei denen ist es einfacher).
Es könnte noch interessant sein, welche Leistung dann tatsächlich aufgenommen wird, und ob der Dimmer diese auch wirklich ohne Schaden zu nehmen dauerhaft abgeben kann - ich kenne das Problem nur aus der Veranstaltungstechnik, Halogenscheinwerfer ziehen beim kalten Einschalten gerne mal den doppelten Strom, sprich, man sollte tunlichst an einem 2 kW Dimmer Ausgang maximal einen 1 kW Strahler anschließen oder dafür sorgen, dass der Strahler niemals kalt auf 100% gefahren wird (dafür gibt es extra Einstellungen zum Vorheizen der Lampen - mit entsprechendem Mehrverbrauch).

Den Kaltwiderstand des Heizstabs kannst Du leicht messen, indem Du ihn im ausgeschalteten Zustand mit einem Ohmmeter misst.
Den Warmwiderstand kann man experimentell auch bestimmen, dazu muss der Heizstab aber zunächst etwas heizen, um anschließend möglichst schnell gemessen zu werden, alternativ misst man Strom und Spannung und errechnet mit den beiden Größen den Widerstand, aber Obacht, wegen der Wechselspannung sind das nur Näherungswerte.

Voraussetzung ist natürlich, dass sich - vielleicht abgesehen von einer Sicherheitsabschaltung (Varistor oder Bimetall) - keine weiteren Einrichtungen im Stromkreis befinden.

EmptySoft hat geschrieben: ↑16. Feb 2023 15:13 Der D1 mini dient nur als PWM Treiber

Hallo,
beim Experimentieren mit dem Wemos D1 mini und MQTT sind mir noch einige Dinge aufgefallen, die Fragen aufwerfen.
Folgende Konfiguration habe ich:

Code: Alles auswählen

UID: mqtt:topic:01144906ea:M420
label: M420_ESPEasy
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:01144906ea
location: Test
channels:
  - id: m420_status
    channelTypeUID: mqtt:string
    label: Status DIO
    description: null
    configuration:
      stateTopic: M420/PWM_1/pwmout
  - id: test_switch
    channelTypeUID: mqtt:switch
    label: Relais
    description: null
    configuration:
      stateTopic: M420/PWM_1/pwmout
      commandTopic: M420/PWM_1/pwmout/cmd
      off: GPIO,14,0
      on: GPIO,14,1

Das funktioniert soweit ABER:

1. Der MQTT.fx gibt mir beim Beobachten diese Info auf dem cmd-Topic:

Code: Alles auswählen

*** PAYLOAD IS NOT VALID JSON DATA *** 

Unexpected character ('G' (code 71)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')
 at [Source: java.io.StringReader@26709a5b; line: 1, column: 2]

Der GPIO 14 schaltet, das sehe ich im status-Topic (OH und MQTT.fx) und auf der Weboberfläche. Diesen "Schönheitsfehler" könnte ich verschmerzen.

2. Wie übergibst man das PWM-Kommando an das cmd-Topic?
Wenn ich im Channel bei "on"

PWM,14,200

eintrage, bekomme ich keinerlei Statusrückmeldung dazu.
Mache ich da etwas falsch?

Besten Dank!

Wie sieht denn die vollständige Payload des Status Topic aus?
Wie lautet der vollständige zu sendende Befehl?

ESPEasy wird ja seinem Namen insofern nicht gerecht, als dass es nicht ausreicht, zu wissen, dass ESPEasy installiert ist, man muss auch genaue Kenntnis der eingerichteten Module und deren Konfiguration haben.
Ganz grundsätzlich:

Code: Alles auswählen

UID: mqtt:topic:01144906ea:M420
label: M420_ESPEasy
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:01144906ea
location: Test
channels:
  - id: test_switch
    channelTypeUID: mqtt:switch
    label: Relais
    description: null
    configuration:
      stateTopic: M420/PWM_1/pwmout
      commandTopic: M420/PWM_1/pwmout/cmd
      formatBeforePublish: GPIO,14,%s
      transformationPattern: JSONPATH:$.GPIO[14].value //muss noch geklärt werden!
      off: 0
      on: 1

über das stateTopic empfängt openHAB den neuen Status, und zwar als gültiges JSON. JSONPATH hangelt sich im JSON zum eigentlichen Wert entlang, der innerhalb des JSON fix entweeder 0 oder 1 ist (weshalb auch genau diese beiden Symbole als on und off definiert sind)
Wird ein Befehl gesendet, so wird aus ON eine 1 und auch OFF eine 0. Bevor nun einer dieser beiden Werte als Payload versendet wird, wird die Payload noch formatiert, und zwar wird die Zeichenfolge GPIO,14, vorangestellt. der resultierende String wird als Payload ins commandTopic geschrieben.

Die Anzeige in MQTT.fx (PAYLOAD IS NOT VALID JSON DATA) könnte eventuell daher rühren, dass Du anforderst, die Payload als JSON zu decodieren. Wenn die Payload nun aber kein gültiges JSON enthält (sic!) beschwert sich MQTT.fx darüber.

Folgende Grundeinstellungen habe ich vorgenommen:
Wemos-Name: M420
GPIO 14 Name: PWM_1
GPIO 14 Value-Name: pwmout
Dadurch ergibt sich (zeigt MQTT.fx auch an) ein status-Topic: M420/PWM_1/pwmout
Das Command-Topic lt. Datenblatt: M420/PWM_1/pwmout/cmd
Das zu sendende Kommando (https://espeasy.readthedocs.io/en/lates ... #p000-page für GPIO 14:

Code: Alles auswählen

GPIO,14,0
GPIO,14,1

Das funktioniert ohne Probleme, auch der Toggle-Befehl

Code: Alles auswählen

GPIOtoggle,14

funktioniert.
Als Status zeigt mir MQTT.fx und auch OH 0 oder 1 an.
Was nicht mit einer Statusmeldung quittiert wird, ist der PWM-Befehl. In MQTT.fx sehe ich nicht einmal ein Command-Topic-Ergebnis.

Code: Alles auswählen

PWM,14,32
PWM,14,0

Darauf reagiert der Wemos gar nicht.

Gerade sehe ich, das es für den GPIO noch die Möglichkeit gibt, den Switch-Typ zu ändern.
Ich habe ihn auf Dimmer gestellt und siehe da, in MQTT.fx taucht noch ein neues Topic auf

M420/status

Mit dem Inhalt

Code: Alles auswählen

{
  "log" : "GPIO: 14 duty: 32",
  "plugin" : 1,
  "pin" : 14,
  "mode" : "PWM",
  "state" : 32
}

Code: Alles auswählen

{
  "log" : "GPIO: 14 duty: 0",
  "plugin" : 1,
  "pin" : 14,
  "mode" : "PWM",
  "state" : 0
}

Das ist schon mal ein Fortschritt. Trotzdem gibt es noch die Fehlermeldung, was mir sagt, das ich evtl. noch ein paar
Syntaxfehler in meiner Konfiguration habe.

Vielen Dank für die Hilfe!

Das sieht doch schon ganz gut aus!

Code: Alles auswählen

UID: mqtt:topic:01144906ea:M420
label: M420_ESPEasy
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:01144906ea
location: Test
channels:
  - id: test_dimmer
    channelTypeUID: mqtt:dimmer
    label: Dimmer
    description: null
    configuration:
      stateTopic: M420/PWM_1/status
      commandTopic: M420/PWM_1/pwmout/cmd
      formatBeforePublish: PWM,14,%s
      transformationPattern: JSONPATH:$.state
      min: 0
      max: 100

Beim Maximalwert musst Du schauen, ob die 100 korrekt ist, oder ob ESPEasy hier einen anderen Maximalwert verwendet, z.B. 255.
Wie sieht es denn aus, wenn Du den Befehl über MQTT.fx absetzt?
Passt da die Formatierung mit PWM,14,x (x = Dimmwert als Integer zwischen 0 und 100)?

mein ESP Thing

Code: Alles auswählen

///// ESP_9 Boiler Heizstab /////
 Thing mqtt:topic:ESP_Easy_9 "ESP_Easy_9 Boiler" @ "Badezimmer" {
  Channels:
   Type number : LED_Number "LED Number (D2/4)"        [ commandTopic="ESP_Easy_9/PWM/4" ]
  }

mein ESP Item

Code: Alles auswählen

/// ESP-9 Bad Boiler
Number ESP_BadBoiler_Number "ESP BadBoiler PWM [%d]"
 {
 channel="mqtt:topic:ESP_Easy_9:LED_Number"
 }

und in der Rule

Code: Alles auswählen

ESP_BadBoiler_Number.sendCommand(var_BoilerPowerPwm)

Auf den ESP komme ich gerade nicht hin ...

udo1toni hat geschrieben: ↑19. Feb 2023 19:52 Beim Maximalwert musst Du schauen, ob die 100 korrekt ist, oder ob ESPEasy hier einen anderen Maximalwert verwendet, z.B. 255.
Wie sieht es denn aus, wenn Du den Befehl über MQTT.fx absetzt?
Passt da die Formatierung mit PWM,14,x (x = Dimmwert als Integer zwischen 0 und 100)?

Habe heute wenig Zeit, habe das jetzt mit einem Dimmer-Item umgesetzt. Man kann über das Status-Topic schön sehen, wie der Wemos arbeitet.
Auf OH-Seite ist jetzt alles klar, bis auf die Meldung in MQTT.fx. Aber die ist für die Funktion uninteressant.

Laut Datenblatt meine ich gelesen zu haben, das der PWM-Wert zwischen 0 und 1023 liegt.
Ich glaube, das ich den tatsächlichen Max-Wert am Besten experimentell ermittele. Wobei @EmptySoft den Leistungsregler M240 mit
256 Stufen angegeben hat.

Ich werde mit wohl mal einen "Prüfstand" mit Tauchsieder und Zangenamperemeter aufbauen.
Ich berichte dann von den Ergebnissen.
Besten Dank!!!

openhabforum.de

Mini-PV und Leistungsregelungen/Begrenzungen für Bestandsgeräte

Re: Mini-PV und Leistungsregelungen/Begrenzungen für Bestandsgeräte

Re: Mini-PV und Leistungsregelungen/Begrenzungen für Bestandsgeräte

Re: Mini-PV und Leistungsregelungen/Begrenzungen für Bestandsgeräte

Re: Mini-PV und Leistungsregelungen/Begrenzungen für Bestandsgeräte

Re: Mini-PV und Leistungsregelungen/Begrenzungen für Bestandsgeräte

Re: Mini-PV und Leistungsregelungen/Begrenzungen für Bestandsgeräte

Re: Mini-PV und Leistungsregelungen/Begrenzungen für Bestandsgeräte

Re: Mini-PV und Leistungsregelungen/Begrenzungen für Bestandsgeräte

Re: Mini-PV und Leistungsregelungen/Begrenzungen für Bestandsgeräte

Re: Mini-PV und Leistungsregelungen/Begrenzungen für Bestandsgeräte