[curlymo]

I noticed that we have implemented a Quigg screen protocol in the latest nightly but the wiki page is missing. @wo_rasp, were you the one that made this protocol? And could you maybe create the wiki page for it?

[wo_rasp]

Yes.
Actually there is no QUIGG screen device, the protocol implements the dim functionality of the GT 7000 remote control.
The existing dimmable quigg devices do not support a "dimlevel", nor does the GT 7000, thus the existing dimmer functionality and the dimmer GUI interface are not useable.
As the UP/DOWN function of the screen protocol mimics exactly the behaviour of the GT 7000 and the quigg switches, switch/dimm functionality do not interfere with each other and the GUI is working as well.
I would prefer to call the protocols quigg_gt_7000 and quigg_gt_7000_dim, in order to ensure that the user understands that it is an extension, however internally it still is a screen protocol.
Yes I will maintain the wiki page and propose to keep both protocols on one wiki page (AFAIK there are few quigg dimmable devices around).

[curlymo]

My idea would be to properly implement these protocols in the version after the next one. We would need two new device types for it:

1. A stateless up-down device type with these gui elements.

Code:

< | >

So an "down", "stop", "up" button. So the protocol also should be able to send these three codes. This also mimics the behavior of some screens (like S0mfy?)

2. A new screen like protocol but instead of up / down buttons, it should should on / off. So a user can send multiple "on's" and multiple "off's". As you are currently using the screen protocol for.

[wo_rasp]

My idea would be to properly implement these protocols in the version after the next one. We would need two new device types for it:

1. A stateless up-down device type with these gui elements.

Code:

< | >

So an "down", "stop", "up" button. So the protocol also should be able to send these three codes. This also mimics the behavior of some screens (like S0mfy?)

Up, MY, DOWN.
If a button is pressed an event should be fired, if the button remains pressed firing of events has to continue until the button is released. An additional set of buttons is required to mimic pressing two buttons simultaneously. (for example "UP&DOWN"). A JSON object should determine which elements are shown. I could envision some additional elements like

Code:

<<  < | >  >>  RESET  PROG

2. A new screen like protocol but instead of up / down buttons, it should should on / off. So a user can send multiple "on's" and multiple "off's". As you are currently using the screen protocol for.

Would it not be sufficient if the GUI populates JSON objects and the logic is handled by the protocol driver ?

[curlymo]

In regard to point two, can you describe that idea more.

[wo_rasp]

Well my idea is to have a generic interface with up to 7 button areas, and the text displayed within that button is dynamically taken from the JSON object.

The second step would be to handle the different mourse events on the GUI individually.

The third one would be about enumerating the different languages.

[curlymo]

Yes, but than of course all GUI elements should be dealt with this way.