Support for multiple API commands in one MQTT request #642
Comments
|
FULL LOGS ARE MANDATORY and the 2 duplicates auto-reconnect feature request: #570 |
|
Sorry, its because I explained what happening I didn't copy fully logs, As for duplicate I didn't notice sorry because of issue titles. |
|
It works as intended: I didn't design this part, but I understand what it was about. Both the UI and mqtt use the API server, and this behavior is enforced by the UI because we don't want the user to be stuck on the instance he just stopped. Hence, it switches to instance 0 which cannot be deleted or stopped. The question is, do you really need to stop the entire instance? You can easily enable/disable all components of all instances using: HyperHDR's components -> All instances (global) or disable led/grabber in a given instance. Or just start it back up after stopping it and switch back to it. |
|
The issue with using |
Please explain which and how single commands (not multiple as it is not supported by MQTT, same behaviuor as JSON POST requests) behave differently when passed using MQTT and run via RPC, as I am not sure I understand this part. In code the command is simply forwarded from MQTT to API handler. |
|
After more tests it seems yes both works the same way they both switch back to instance 0 before each command, Because I was testing by running the command on my browser HTTP link with curl or mqtt they switch back to instance 0 If this is how it's works normally then sorry for reporting it as an issue. |
|
As explained, switching to instance zero is normal, there are also multiply fuses in many parts of the code that prevents the json API from executing API commands for instances that have been stopped/removed, as in some situations an api vs core state mismatch may occur asynchronously and may lead to application crash. |
|
Understood, then it seems using MQTT it's impossible to control other instances components and effects since it always switch back to default instance, I guess.
I don't understand what you mean here by saying |
|
Post your full json api sequence you are sending via MQTT. |
|
I send 2 payloads {
"command" : "instance",
"subcommand" : "switchTo",
"instance" : 1
}Then turn off led {
"command":"componentstate",
"componentstate":
{
"component":"LEDDEVICE",
"state": false
}
} |
|
Thanks. I'll test it later and let you know next week. The instance switching should happen only when you stop or delete the instance. If confirmed, I'll probably implement accepting JsonArray with multiply requests /JsonObjects at once (with the same restriction as with passing multiply json commands via GET request) should solve it, which I planned some time ago. |
|
The connection is reset after each command, so it behaves exactly like sending json via POST without maintaining the session. GET multi-commands are an exception here because from the beginning it was developed with different assumptions, but it has been described. I'm currently working on enabling multiple commands to be executed simultaneously in MQTT. I think it should be ready soon, I'll let you know. |
awawa-dev
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug report, debug log and your config file (FULL LOGS ARE MANDATORY)
Context:
I'm was making HA integration that can communicate with HyperHDR through MQTT but I bumped into some critical bugs.
I need to uncheck and check the MQTT Enable to reconnect.Steps to reproduce
HyperHDR's componentscommand with MQTT.What is expected?
The selected index LED Turn off
What is actually happening?
-- The instance 0 what turned off.
--
In the logs before it reports the led turned off, It switch back to instance 0 all the time.More-info
So it seems that sending MQTT command always switch back to instance 0 and reports in the logs before each command:
Another issue don't know if I should say bug or feature but when the MQTT Server drops HyperHDR Doesn't reconnect to MQTT.
System
I also tested this in the the last build https://github.com/awawa-dev/HyperHDR/actions/runs/6091102810
HyperHDR Server:
HyperHDR Server OS:
The text was updated successfully, but these errors were encountered: