Ah yes, I get it. I am currently using a powerful laptop to record videos at full bandwidth.
I have not found a simple solution to additionally be able to control from a smartphone without using the Internet.
From what I remember Ekos Live connects to the server, but does not create the server itself, although now I can see several different projects ;)
Thanks for the quick answer, I understand that many implementations of similar solutions are also troublesome to maintain.


Hi Jasem, Hi everyone!

Today I want to share my idea with you and know if it will be useful to you.

Who needs it for?
Sometimes when observing, especially without the use of a camera, it is necessary to move the mount slightly or to improve the sharpness using, for example, the Bahtinov mask .
This is where the control becomes problematic when the eyesight is directed to the eyepiece lens.
In Ekos, you can use, for example, "Mount Control", but looking through the eyepiece, it is difficult to manipulate the mouse on the screen and hit the appropriate button.

The idea is a wireless / wired handheld controller that could be a smartphone.
The application is a simple website using Vue.Js 3.0 that can be hosted anywhere.
Following the Plug & Play principle, I put a simple web server in the KStars project itself on port 1080, which displays this page.

Locally (you can test quickly):
Open a browser and go to http://localhost:1080 on the same device as running KStars with the "ManagerWebSocket" branch.

On a remote device that is on the same network as the computer and KStars, type http://<ADDRESS_IP_KSTARS>:1080/ in the browser.

Connect your phone via USB to the computer with KStars and select USB Tethering in your phone's settings.
Now you can access the website by typing http://<ADRES_IP_KSTAR>:1080/ in your browser

How it works?
On port 1081, communication takes place via the WebSocket protocol using the Json format.
The appropriate Json structure specifying the module, function, and arguments is sent to port 1081, then the function is searched for and executed.
If the function returns a type, it is returned in the same structure.

For example, if we want to call a function:
// Adjust focuser offset, relative or absolute
void adjustFocusOffset(int value, bool useAbsoluteOffset);
Which is in the "Focus" class, just send a text message with the structure and example values of the function argument:
    ekos: {
        focus: {
             adjustFocusOffset: [100, false]
And that's it. The focus will be shifted.

Modules are upgradeable over time, currently "mount" and "focus" are used.
See kstars/ekos/managerwebsocket.cpp
            /* ... */
            auto args = QJsonDocument::fromJson(message.toLatin1()).toVariant().toMap()["ekos"].toMap();
            if (args.count() == 0)

            QVariantMap result;

            s_invokeModule(m_manager->mountModule(), "mount", args, result); // mount
            s_invokeModule(m_manager->focusModule(), "focus", args, result); // focus
            /* ... */

            if (!result.isEmpty())
                QVariantMap resultMap;
                resultMap["ekos"] = result;
            /* ... */
To call the function, the "QMetaMethod::invoke" mechanism is used, which allows calling every function in the class (if it is correctly implemented).

What do you think about it?
The code is written, I decided to clean it today and share it.
I personally use it. If you like it and you have any suggestions on what I can improve, I can take care of it.

KStars feature/ManagerWebSocket


256MB should be enough. However, for testing, it's worth increasing if you hear that they've been doing something with buffers.

Please confirm that everything is fine for the newest INDI / INDI-3rdParty builds with the old library.

LD_PRELOAD=/path_to_library/libASICamera2.so.1.16 indiserver indi_asi_ccd


Yes, I mean 1.17.
I am not getting detailed information from ZWO, I am trying to establish cooperation with them. I am working on the libASICamera2Boost library. Unfortunately, each camera has a different implementation and it's hard for me to keep developing without the original library source.

In original library (1.17), there are probably larger double buffers used for communication with the camera.
The usbfs_memory_mb value should be at least '6 x Resolution'. For now, these are guesses, I need to analyze the library more.
Anyway, to rule out a memory problem, I suggest temporarily increasing the usbfs_memory_mb value and testing indi with different ZWO libraries.
For example:

sudo sh -c 'echo 512 > /sys/module/usbcore/parameters/usbfs_memory_mb'
# test for biggest camera
# sudo sh -c 'echo 1024 > /sys/module/usbcore/parameters/usbfs_memory_mb'

# Test different versions of the ZWO library.
LD_PRELOAD=/path_to_library/libASICamera2.so.1.16 indiserver indi_asi_ccd
LD_PRELOAD=/path_to_library/libASICamera2.so.1.17 indiserver indi_asi_ccd


In the latest SDK, the problem with damaged frames during long exposure is fixed.
Probably it required more library modification and maybe something got corrupted.
I still offer cooperation for ZWO, unfortunately without success.


This can actually be a problem for a specific camera.
Each camera has its own implementation of receiving data.

For example, Jasem keeps mentioning to me that he has no problems running 2 cameras at once.
Of course it is, the ASI178MM and ASI120MM-Mini cameras have a similar communication implementation, in a cooperative global variable. So you can't run them all at once.
The ASI178MC and ASI120MC cameras can already be run together, they have completely different communication implementations.


Please rebuild the indi and pyindi-client from git.


Paweł Soja replied to the topic 'Problem importing PyIndi' in the forum. 2 years ago

I added a build test for PyIndi.
If @geehalel accepts the changes, I will also add unit tests.


Paweł Soja replied to the topic 'Problem importing PyIndi' in the forum. 2 years ago

Thanks, I think I can support pyindi, monitor the status, and suggest an easier way to write in python (using INDI Library).
All upgrades are backwards compatible for C++, but I can see there are problems with swig - to be taken care of.


Paweł Soja replied to the topic 'Problem importing PyIndi' in the forum. 2 years ago

Cases where people will write exotic macros here and there that will probably continue break swig (without even considering the static binary dependency for the client)

The macro is not exotic and it was never a problem. The error was in using a macro without a proper include in pyindi-client.
Most of the problems with PyIndi are related to the work on the INDI Library to keep the interface in the future without rebuilding dependencies.
Also, high-level functions that facilitate the development process are implemented.

I am currently creating automatic builds for Linux / MacOS. If you like, I can add additional tests for pyindi-client.



I'm coming back after a break.
I thought that we would be able to solve the problems in the original library with ZWO, unfortunately in short I got the answer "most of the users is not so critical about the speed on PI".

So I will continue to develop the boost library. I will take a look at the problems that were mentioned on the forum.

There is low speed writing to the card on the Raspberry PI and it will be difficult to get around this problem. The solution is to introduce:
- compression before saving to the memory card
- saving a short recording - using the version with a large amount of RAM
- sending directly over the network and saving to another computer

I also got "Asus Tinker Edge R" for testing, where most problems can be solved.

After all, there is still a problem with long exposure, if my library solves the problem, I'll be glad my work isn't wasted.