Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Websocket does not provide information about scenes #24

Open
dmoibm opened this issue Feb 25, 2022 · 6 comments
Open

Websocket does not provide information about scenes #24

dmoibm opened this issue Feb 25, 2022 · 6 comments

Comments

@dmoibm
Copy link

dmoibm commented Feb 25, 2022

Unfortunately I don't get any events from scene buttons by websocket.
As a result, scene buttons are completely useless in mixed environments.
When can we expect this to change?

@hansfriedrich
Copy link

hansfriedrich commented Feb 27, 2022

As I noticed the events from the scene buttons are not published through the WebSocket. I think they are acutally designed to do their job within the system.
Maybe you can capture the load changes and check them against the endpoint GET api/scenes (maybe a cached copy). Not really a solution (especially for events that should not published via loads - I could imagine a lot of them), but maybe it can help in some manner.

@dmoibm
Copy link
Author

dmoibm commented Feb 28, 2022

@hansfriedrich: Thanks for the tip. Unfortunately, GET api/scenes doesn't work as expected. Although I have a scene device with 4 buttons and I have defined 3 scenes in the system, GET api/scenes always returns

{
    "data": [],
    "status": "success"
}

Possibly GET apt/jobs might help. But the result is very difficult to understand.
And for a real smart home it is allways better to get clear messages.

@woodworm
Copy link
Member

woodworm commented Mar 7, 2022

If you want to control several loads together, this must be described in a job.
There are two ways to do this, depending on the uscase.

Create a job lik this to set three loads to a defined value:

POST api/jobs
{
  "target_states": [
     {"load": 1, "bri": 10000},
     {"load": 2, "bri": 0},
     {"load": 3, "bri": 5000}
  ]
}

To call this job use:

GET api/jobs/<id>/run

Create a job like this to control three loads:

POST api/jobs
{
  "button_ctrl": "loads": [1, 2, 3]
}

dim up all loads:

GET api/jobs/<id>/ctrl/press/up 

stop dimming:

GET api/jobs/<id>/ctrl/release/up 

all off:

GET api/jobs/<id>/ctrl/click/down

all on:

GET api/jobs/<id>/ctrl/click/up

To call a job with a scene-smartbutton the following sequence is necessary.

  1. POST /api/smartbuttons/program {"on": true, "timeout": 60, "button_type": "scene", "owner": "user"}
  2. GET /api/smartbuttons/notify
  3. press blinking button
  4. PATCH /api/smartbuttons/<<smartbutton_id>> {"job": <<job_id>>}

To control a job with a groupctrl-smartbutton the following sequence is necessary.

  1. POST /api/smartbuttons/program {"on": true, "timeout": 60, "button_type": "groupctrl", "owner": "user"}
  2. GET /api/smartbuttons/notify
  3. press blinking button
  4. PATCH /api/smartbuttons/<<smartbutton_id>> {"job": <<job_id>>}

@woodworm
Copy link
Member

woodworm commented Mar 7, 2022

api/scenes or api/groupctrls is intended for an APP (user interface) to describe a control element (e.g. button).
It is up to you what kind of properties you want to store in such an object.

Example of how to create a scene object:

POST api/scenes
{
  "job": 42,
  "name": "Watch TV",
  "icon" : "tv.png",
  "color": "blue",
  "favorite": true 
}

@dmoibm
Copy link
Author

dmoibm commented Mar 8, 2022

@woodworm: Thanks for the explanations. Scene buttons are smartbuttons. But how do I get events from scene buttons (smartbutton input_type=2) on websocket interface?

@woodworm
Copy link
Member

woodworm commented Mar 8, 2022

Unfortunately, there is no final solution for this use case in the current market version.
The future solution would be:

  1. upload a script (e.g. my_script.py)
  2. create a job POST api/jobs {"scripts": ["my_script.py"]}
  3. associate the job with a smartbutton

However, we could already offer support in advance. For this, you have to write a e-mail to our customercare center with the note "API request at woodworm".

@woodworm woodworm transferred this issue from Feller-AG/wiser-tutorial May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants