Q Light Controller+

Hi,

i am currently experimenting with an ESP32, sending WebSocket to QLC+ via WiFi.

When toying with the Websocket API, i noticed a few things:

0) You can crash QLC+ by sending malformed websocket requests (see below) or hammering the server.

1) There is absolutely no documentation of features. I am currently scraping the websocket text messages QLC web applet hands over to itself via Websocket from wireshark dumps and am sifting through the comments on websocket.js class and the measly doubleslashed stuff on the API Test page.

2) [s]The handovers are not making sense at all. The assignment of the display value to the slider means that i have to write a function that sends not only a dmx value, but also a corresponding display value. For values under 100, that means i have to suffix every number with a zero, lest i crash QLC+. Why does that value (which is miraculously almost identical to the DMX value) have to be sent via Websocket anyway?
Disregard that, it's the reply from the server.

quite irate, compensating with Gin Tonic,

Highpersonix

Ok, after toying with it some more, i found the following behaviour:

1) ESP32 sends http GET, Server replies with "switching protocols", ESP32 sends command (in this case, a slider 1 gets vales 0-255 ascending one per second), slider moves in QLC main, DMX changes, but no reply to the ESP32.

2) Open web applet localhost:9999, Server starts replying to the ESP32 with "1|SLIDER|$value|$label"

What does the web applet do to cause the server to start replying?

greetz

Highpersonix

Further toying with the web applet results in:

curl http://localhost:9999/ -o/dev/null

two replies per request sent by the ESP32

curl http://localhost:9999/ -o/dev/null

three replies per request

....and so on, until you restart QLC+ completely. I cannot find the bug in QLC that causes this behaviour, nor am i sure whether or not it's intentional (see: lack of documentation).

Greetz

Highpersonix

You could find webaccess code in the link below. Maybe is a good start to learn how the websocket api works.
https://github.com/mcallegari/qlcplus/t ... access/res

I am looking for documentation, not a few remarks behind slashes in someone else's code. Code which then may or may not work as intended, see above. That's why i'm here, of course i looked at the source code, it does not work, i don't know why. Assuming that anyone can reverse engineer everything is pretentious.

Highpersonix wrote: ↑Thu Mar 29, 2018 8:18 am I am looking for documentation, not a few remarks behind slashes in someone else's code. Code which then may or may not work as intended, see above. That's why i'm here, of course i looked at the source code, it does not work, i don't know why. Assuming that anyone can reverse engineer everything is pretentious.

Dude, you really have no idea of what "reverse engineering" means...
This is an open source project, entirely based on volounteering, so please excuse us if we're not as professional as you are, though we don't drink gin tonic to compensate.

I don't really understand what are these "slashes" you keep talking about.
Open the Web API Test page (which is self-documented btw) with a browser, and open it with a text editor.
I don't think it requires a genious or reverse engineering to understand that is sent on a websocket in the form So, what is your whole point in this thread ?
If you're here just to throw shit at someone else's work, then I'll keep on ignoring you as I did until now.

Ok, this may have come across as a bit too harsh, sorry. By reverse engineering i mean sifting through the code and finding out what's responsible for this behaviour:

I am sending a Websocket TXT(1|$_n) to a running instance of QLC+ --web from an ESP32. It is connected to qlcserver:9999/qlcplusWS
The value is rising and results in the slider assigned on the virtual console rising, dmx output works. There is no feedback from the server to the ESP32 that it actually has received the command.

I am now opening qlcserver:9999 in a browser window. The slider on the browser mirrored console moves accordingly, suddenly the server starts sending feedback to *all* connected websocket instances (ESP32, webapplet) in the form of (1|SLIDER|$_n_label|$_n).

when i restart the qlc+ --web, the feedback messages disappear until i open the web applet again. After testing a lot, i found out that calling qlcserver:9999 with a web GET (curl,wget) triggers the feedback. This extends to the point where multiple calls lead to the message getting sent out repeatedly. (1|$_n) gets a reply of (1|SLIDER|$_n_label|$_n) (1|SLIDER|$_n_label|$_n).

Is this intentional?

I suspect you're opening a new websocket connection every time you invoke curl/wget.
This is like opening several web browsers at the same time, each one with its own websocket channel.
In that case, that is intentional, as multiple connections are allowed.

In general, a websocket channel works like "a session". You should open it once, perform several actions, then close it.
Probably curl/wget don't properly close a websocket channel once they're done.