Open grobotka opened 3 weeks ago
Wow, that's a very interesting question. What do you need this register access (REG_C_TEST...) for? I'm asking this because this type of access can be very dangerous, and there may be a simpler solution available.
We have it in our roadmap that you can set the color generically for all LEDs in our system.
I use this function to configure devices, which saves me from running around the house with a magnet in my hand. For example, creating a scene is done according to the scheme:
(...) prepare programming mode (smartbuttons/program) start blinking smart buttons (smartbutton/notify) press the scene button (REG_C_TEST_ButtonxPressDuration) get smartbutton (smartbuttons/{id}) (...)
It works very well with all devices for over a year. Now I'm adding support for thermostats, unfortunately the lack of a button press simulation prevents automatic binding a thermostat to HVAC group.
Regarding colors, this is very good news. So we have to wait for the ready implementation.
Does that mean you need this procedure for commissioning Wiser systems?
If there were a single service for this, such as:
POST http://192.168.0.232/api/smartbuttons {"device": <device_id>, "channel": <input_channel_index>, "job": "optional <job_id>"}
would you use this instead of:
POST /api/smartbuttons/program
GET /api/smartbuttons/notify
PATCH /api/smartbuttons/<id> {"job": "<job_id>"}
?
And of course, a similar approach could be applied for hvac-groups.
Yes, exactly. The same also applies to extension device (Nebenstelle) magnet-binding. It would be great to have dedicated commands for these functions.
I noticed that the simulation of pressing the button (REG_C_TEST_ButtonxPressDuration) does not work for the thermostat. Could this function be added, please?
And there is no way to change the LED color for heating/cooling indication. Why limit the settings to brightness only? Is it possible you will add this in the future?