Digital Output Persistence

Comments & issues
Post Reply
gjacquemin
Fresh meat
Posts: 1
Joined: Tue Jul 21, 2020 2:29 am
Contact:

Digital Output Persistence

Post by gjacquemin »

Hello,

I'm controlling among others a
16x Isolated Solid State Relay Phidget
with the

Code: Select all

phidget22.DigitalOutput
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!
User avatar
Patrick
Lead Developer
Posts: 3403
Joined: Mon Jun 20, 2005 8:46 am
Location: Canada
Contact:

Re: Digital Output Persistence

Post 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
philx1
Fresh meat
Posts: 2
Joined: Wed Jul 29, 2020 7:16 am
Contact:

Re: Digital Output Persistence

Post 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.
User avatar
Patrick
Lead Developer
Posts: 3403
Joined: Mon Jun 20, 2005 8:46 am
Location: Canada
Contact:

Re: Digital Output Persistence

Post 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
philx1
Fresh meat
Posts: 2
Joined: Wed Jul 29, 2020 7:16 am
Contact:

Re: Digital Output Persistence

Post 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.
gregbalco
Phidgetsian
Posts: 9
Joined: Fri Sep 25, 2020 12:01 pm
Contact:

Re: Digital Output Persistence

Post 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.
rwilcox
Fresh meat
Posts: 1
Joined: Sun Jun 27, 2021 11:19 am
Contact:

Re: Digital Output Persistence

Post 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
xsdg
Fresh meat
Posts: 2
Joined: Thu May 25, 2023 2:13 pm
Contact:

Re: Digital Output Persistence

Post 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)
Post Reply

Who is online

Users browsing this forum: No registered users and 27 guests