Page 1 of 1
Digital Output Persistence
Posted: Tue Jul 21, 2020 2:37 am
by gjacquemin
Hello,
I'm controlling among others a
16x Isolated Solid State Relay Phidget
with the
JavaScript API. Everything's works fine, BUT each time I refresh my webpage, the relays goes off. As I read on the documentation, I understand that this is
persistence feature that was available in phidget21 but not in phidget22.
I do understand why you make this choice (predictable state with channel is attached), but that's very annoying in webpages where the user can open/close/reload easily the program.
My question: is it possible to enable the persistance or disable the reset state when channel is detached?
Thanks!
Re: Digital Output Persistence
Posted: Tue Jul 21, 2020 10:12 am
by Patrick
Hi,
It's not possible to have the Phidget retain it's state while closed. This may be something we look into supporting in the future, as it does make sense in certain scenarios.
For your case, I'd recommend writing a small server-side application which you keep running all the time alongside the Phidget network server, which manages the state of your devices. This could be as simple as just opening them, so that the network server always has an active client and doesn't close them when the web clients reload.
One step further would be something like a Node.JS application which manages the Phidgets server-side and serves it's own web view for clients. Really depends on the situation.
-Patrick
Re: Digital Output Persistence
Posted: Wed Jul 29, 2020 7:20 am
by philx1
Just to add, I think it's a good idea to add the option as some kind of configurable (maybe flash, or not - R/W cycle lifetime?) setting on a phidget/controller?
i.e. default 0 / default 1 / persist
Writing another application to run on some persistent server (using a HUB5000) just to keep the device states seems a bit wasteful.
EDIT: specifically when the HUB5000 controller is attached to a network remotely... it would be nice to know multiple clients can cycle in and out of having access without worrying there may not be "one left" to hold the current states... each client/user can connect in a do a "read, modify, write" instead of assuming there's some initial state or assuming there is no one else connected.
Re: Digital Output Persistence
Posted: Wed Jul 29, 2020 12:57 pm
by Patrick
It's true that writing a dedicated app just to keep state shouldn't be necessary. When the library was designed, we just decided to enforce that users need to keep a channel open if they want it to be controlled - this does fall apart a bit in the case of in-browser JavaScript, and in fact JavaScript support was added after the library was designed.
-Patrick
Re: Digital Output Persistence
Posted: Fri Jul 31, 2020 3:13 pm
by philx1
I am new to the phidgets ecosystem - creating a python CLI for developers to interact with hardware remotely and just figured remote network interfaces tend to not be as reliable... having some persistence would help keep the hardware "in tact" if the network drops for some reason. Have not done any remote testing yet to see how reliable it is.
Re: Digital Output Persistence
Posted: Sat Oct 17, 2020 12:28 am
by gregbalco
I was just reading this thread and want to add a comment that it would be useful if devices could have persistent state. I have been working on a SBC + analog voltage output Phidgets setup to control a set of high voltage sources. The Phidgets supply a control voltage. If the control voltage goes down, so does the HV, which has numerous bad effects. I have it basically working with a program on the SBC that starts on boot and stays running, but every now and then the analog outputs detach, which is bad. It would be a lot better if the analog outputs could be set and detached and would maintain their setting.
Re: Digital Output Persistence
Posted: Thu Mar 10, 2022 8:27 am
by rwilcox
Me too! Enabling a relay and then having to maintain a running program to keep that relay state seems excessive. I would suggest something that is non-default behavior and requires a few extra steps for those that are sure they want this behavior. Would make my use case much simpler
Re: Digital Output Persistence
Posted: Thu May 25, 2023 2:26 pm
by xsdg
I'm using the 16-way SSR to control power to some devices. I need the outputs to generally be on (connected), and I'm making a power-cycle script to set them off, wait for a bit, set them on again, and exit.
I'm using the Python API, and found that if I use "finalize" when I want to freeze the output state, it seems to do what I want. It prints an error message on exit, but that seems to only be cosmetic.
So in short if I modify the demo app in this way, it does what I need (with the understanding that the output reset on opening the output is inconsequential for my usecase, even though that might be non-ideal for other usecases):
Code: Select all
# powercycle script
def main():
digitalOutput0 = DigitalOutput()
digitalOutput0.openWaitForAttachment(5000)
# digitalOutput0.setDutyCycle(1)
digitalOutput0.setState(False)
# try:
# input("Press Enter to Stop\n")
# except (Exception, KeyboardInterrupt):
# pass
time.sleep(5)
digitalOutput0.setState(True)
#digitalOutput0.close()
digitalOutput0.finalize(0)