Digital Output Persistence

[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!

[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]

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.

[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]

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]

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]

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]

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)