indilib / indi

INDI Core Library Repository
https://www.indilib.org
GNU Lesser General Public License v2.1
377 stars 394 forks source link

Problem with TELESCOPE_TRACK_STATE property update (simulator) #2129

Closed atoy40 closed 1 month ago

atoy40 commented 1 month ago

Describe the bug

When a client set the TELESCOPE_TRACK_STATE switch property to a new value (sendNewSwitch), others clients don't receive the update notification.

Reproduce

I used Kstars to launch the INDI server with simulator drivers, and use the kstars INDI window to on/off telescope tracking this is a very simple client that track this property:

#include <basedevice.h>
#include <baseclient.h>
#include <iostream>

class MyClient : public INDI::BaseClient {
    public:
        MyClient() {
            watchDevice("Telescope Simulator", [this](INDI::BaseDevice device) {
                std::cout << "Telescope" << std::endl;

                device.watchProperty("TELESCOPE_TRACK_STATE", [this](INDI::Property prop) {
                    std::cout << prop.getName() << std::endl;
                }, INDI::BaseDevice::WATCH_UPDATE);
            });

        };
        ~MyClient() = default;
};

int main(int argc, char **argv) {
    MyClient myClient;
    myClient.setServer("localhost", 7624);
    myClient.connectServer();

    std::cin.ignore();
}

If I changed TELESCOPE_TRACK_STATE with another switch type property (for example TELESCOPE_PARK), no problem at all, updates are fired.

I also notice if I changed the track state through the Ekos telescope tab, it's not reflected to the Kstars INDI window.

Desktop (please complete the following information):

Thanks. Anthony.

atoy40 commented 1 month ago

After some investigation, it seems to come from this line : https://github.com/indilib/indi/blob/b5a6eab9e12c8ba822aa45f0b0468f7f848ba617/libs/indibase/inditelescope.cpp#L1418 where the reset() must be replace by an apply() call.

here is a PR : https://github.com/indilib/indi/pull/2130

Anthony.

knro commented 1 month ago

Thank you for the fix. This was indeed a regression from 2.1.0