Value Node an Dimmer mit ramp_time und on_time funktioniert erst beim zweiten Event

[hobbyquaker]

Sicher dass der pm2 Prozessname "node-red" ist? Schau mal mit "pm2 list" nach.

[der-pw]

Doch, da bin ich mir ausnahmsweise sicher.

Code: Alles auswählen

patrick@node-red:~$ sudo pm2 list
┌─────┬─────────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┬──────────┬──────────┐
│ id  │ name        │ namespace   │ version │ mode    │ pid      │ uptime │ ↺    │ status    │ cpu      │ mem      │ user     │ watching │
├─────┼─────────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤
│ 0   │ node-red    │ default     │ N/A     │ fork    │ 7103     │ 112m   │ 13   │ online    

[hobbyquaker]

Hmm... Dann zeig mal den "logging" Teil aus Deiner settings.js. Sollte ungefähr so aussehen:

Code: Alles auswählen

...
logging: {
	console: {
		level: "debug",
...

Ansonsten kannst auch einfach mal Node-RED im Vordergrund (ohne pm2) starten um zu sehen ob es dann auf stdout loggt und pm2 als mögliche Ursache auszuschließen. Anderer Gedanke der mir grade kommt weil ich sehe dass Du pm2 mit sudo startest - hast du auch das pm2 logs mit sudo aufgerufen? Wenn das nicht der gleiche User bei beiden Aufrufen ist kann er das Log nicht finden.

[der-pw]

Oh man, wenn man zu doof ist, und die settings-Datei im Benutzer-Home editiert udn nicht im Root-Home.
Danke trotzdem für deine Geduld.

Ich hänge dir mal den Stripdown, ab dem ersten Event an.

Wie du siehst wird es scheinbar richtig übertragen, an "papa111202:1"
ON_TIME 5
RAMP_TIME 3
LEVEL 0.6

https://pastebin.com/raw/5NRwvkzv

[hobbyquaker]

Mein Eindruck ist dass node-red-contrib-ccu hier fehlerfrei arbeitet. Kann Dein Problem auch nicht nachvollziehen mit verschiedenen eQ-3 Dimmern. Insofern würde ich das Problem eher in der HB-Dimmer Firmware vermuten, die scheint sich an der Stelle anders zu verhalten als die eQ-3 Firmware.

Edit: grad gesehen Du hattest das Problem auch mit eQ-3 Dimmern - ich teste das hier noch mal. Interessant wäre auch ob Du das z.B. mit dem Homematic-Manager reproduzieren kannst.

[der-pw]

Genau, nachdem es mit zwei AskSin-Dimmern nicht lief habe ich den WW-DW Dimmer welcher original ist zum Testen herangezogen.

Ich kann es mir so langsam auch nicht mehr erklären.
Mit dem hm-rega Adapter unter iOBroker läuft die Sache,
und wenn ich eingangs geschrieben habe, dass es im Homematic-Manager läuft, habe ich ihn wohl falsch bedient.
Ich hatte die Parameter einzeln per "setValue" übergeben.

Mache ich aber folgenden Request:

Code: Alles auswählen

putParamset [
  "papa111202:1",
  "VALUES",
  {
    "INHIBIT": false,
    "INSTALL_TEST": false,
    "LEVEL": 1,
    "OLD_LEVEL": false,
    "ON_TIME": 5,
    "RAMP_STOP": false,
    "RAMP_TIME": 5
  }
]

Schießt der Dimmer auf 100% und spielt mit der CCU Telegram-PingPong

Code: Alles auswählen

22:45:11	HM-RCV-50 BidCoS-RF	Fl_Dim_Spiegel	-23	10	211	7.1%	RESPONSE	RPTEN
22:45:11	Fl_Dim_Spiegel	HM-RCV-50 BidCoS-RF	-75	15	211	6.3%	INFO	BIDIRPTENWKMEUP
22:45:10	HM-RCV-50 BidCoS-RF	Fl_Dim_Spiegel	-23	10	210	7.1%	RESPONSE	RPTEN
22:45:10	Fl_Dim_Spiegel	HM-RCV-50 BidCoS-RF	-74	15	210	6.3%	INFO	BIDIRPTENWKMEUP
22:45:10	HM-RCV-50 BidCoS-RF	Fl_Dim_Spiegel	-23	11	126	7.1%	ACTION	BIDIRPTEN
22:45:10	Fl_Dim_Spiegel	HM-RCV-50 BidCoS-RF	-76	15	117	6.2%	RESPONSE	RPTEN
22:45:09	HM-RCV-50 BidCoS-RF	Fl_Dim_Spiegel	-23	14	117	7.0%	ACTION	BIDIRPTEN
22:45:09	Fl_Dim_Spiegel	HM-RCV-50 BidCoS-RF	-74	15	108	6.1%	RESPONSE	RPTEN
22:45:09	HM-RCV-50 BidCoS-RF	Fl_Dim_Spiegel	-23	14	108	6.9%	ACTION	BIDIRPTEN
22:45:09	Fl_Dim_Spiegel	HM-RCV-50 BidCoS-RF	-74	15	99	6.1%	RESPONSE	RPTEN
22:45:09	HM-RCV-50 BidCoS-RF	Fl_Dim_Spiegel	-23	14	99	6.9%	ACTION	BIDIRPTEN
22:45:09	Fl_Dim_Spiegel	HM-RCV-50 BidCoS-RF	-76	15	90	6.0%	RESPONSE	RPTEN
22:45:09	HM-RCV-50 BidCoS-RF	Fl_Dim_Spiegel	-23	11	90	6.8%	ACTION	BIDIRPTEN

Hatte auch schon gedacht, dass was an meiner Konfiguration kaputt ist.
Eine frische Raspberrymatic mit nur einem angelernten Dimmer spinnt aber auch schon rum.

Fassen wir mal zusammen:
an Debmatic liegt es nicht
an Raspberrymatic auch nicht
node-red resp. node-red-contrib-ccu arbeiten Fehlerfrei
hm-rpc unter iOBroker machts

Dann werde ich mir wohl in iOBroker ein Script bauen, das aus node-red per MQTT die Daten Device/Channel/ramp_time/on_time/level bekommt und weiterverarbeitet. Sind drei Geräte mit moderaten Schaltzyklen.
Wenn es die Arbeit mal wieder zulässt, nehme ich mal nen Pi mit dort hin und teste unter "störungsfreier" Umgebung.