Sure. I assume you mean the latest 4.1.0.890, but I don’t see a Beta release for 4.1.1. The list jumps from 4.1.751 to 4.2.0.849. ??
Ok, I found a release version 4.1.0.890. Looking in the wrong list before. Want me to use it?
Sorry, that is all a typo mess.
What I meant was:
- In 4.4.1 beta, connect to the switch and attempt to set state, observe failure (presumably)
- In the 4.4.0 release, do the same and… ???
I’ll be using 4.4.0.1339 release and 4.4.1361 (the latest) Beta. Okay?
Yes, perfect, ty
Doing it manually, no failures (switches can be turned on and off) on either version although I get ASCOM DigitalLoggers WPS Driver not installed on v1339. I don’t see the simulator in the Switches list.
I can hang by the computer if you want to try anything.
I wonder if something is wrong with my computer. When I use DL’s web interface from my house computer, it responds immediately with change of state. When I use it on my observatory computer, it takes 38 seconds to change the state in the UI. But I know the state was changed instantaneously because I can refresh the UI immediately and it is changed. So the acknowledgement that the switch was changed takes that long. I wonder what could be going on there?
Apologies, I am in and out today.
This is what SGPro is seeing… it retries for 30 sec and gives up.
I don’t know what is wrong with the DL power unit not sending an ack in a timely manner to either SGP or the DL web UI ONLY within the observatory computer. The DL web UI works fine on other computers over the WiFi network - no apparent delays. So I made a direct Ethernet connection from the DL unit to the observatory computer and the delay in the DL web UI appears to go away. The DL UI must be getting the ack.
Testing with SGP all required switches turned on but the error messages still appear. Now, however, I can immediately click “yes” to the time out box and the sequence proceeds normally with devices connected. Before, I had to let time elapse.
At the conclusion of end-action, the devices were not disconnected before turning off. This wreaks havoc with my AP V2 mount driver and hangs SGP. It does not seem to be a problem with other devices.
I used your latest Beta, v1361.
Hi Ken,
I imagine you’re pretty tired of this by now. If a fix could be made to turn off devices before power, the switches would be totally useful to me. I can just ignore the error messages or leave them alone and they’ll go away.
Thanks,
Kent
It’s totally fine and this fix has already been made. I’ve tested it extensively, but not with DigitalLoggers and the problem may be there. Can you share logs of that run where the ordering was ignored?
Do you mean that in V1361 the devices should disconnect before power off? Is that the ordering you’re referring to?
In any case, here’s a log from a run I just made that shows the problem:
Yes, 1361 has considerable changes to ensure that switches are the absolute last thing. Unfortunately these changes come with some complexity in monitoring possible long running tasks. We’ll figure it out.
Ok… Thx for the logs. I found the issue you describe and the path that causes the desired order to be ignored. I’ll release a new beta today.
Lot’s of stuff in this thread and I do truly appreciate you taking the time to report it. But, because there is a bunch of stuff going on here, hoping we can reset and just redescribe / relist active remaining issues you are seeing.
I’m not sure I can do much about the 38 seconds required for a switch to reflect its actual state, but I will increase the timeout to 60 sec I think…
Aside from the gear disconnect ordering you see anything else not performing the way yoy expect it to?
I don’t see any other issues at this point, but I’ll use your new beta and see how things go. BTW, since I am now directly connected, I don’t see that 38 second delay. The DL UI shows the state change immediately. The weird delay was only on my observatory computer using WiFi. All other computers using WiFi were fine. You should get a response much more immediately now? What is the lag you’re now seeing?
Thanks very much for all the hard work!
To be clear when I say I am “seeing” this, I mean to say that I am “seeing” in your logs as l dont have any compatible equipment for test.
It’s no problem, I appreciate you taking to the time to describe things that aren’t always easy to convey. The beta was delayed yesterday due to some unrelated preparatory changes that are going into 4.4.1.
Beta is building now…
I meant if there were any timing differences you could see in the last log compared to the older logs.
I downloaded your latest beta. It works fine with my simplified test sequence. The error messages that 30 seconds have elapsed come up immediately, as before. Not a problem as the sequence continues. Just wondering why they come up so quickly. Everything turns off nominally. Yay! I’m always forgetting to switch off the observatory devices and this’ll remedy that. Thanks!
Oh that’s interesting… I didn’t know that you see the warning immediately-ish. That sounds like a bug to me. Does this happen on manually setting the switch, having the sequence set it or for both? To be clear, I’m asking which methods display the error immediately and not if it displays the error at all.