New Plugin: Switchboard -- Virtual Switches Re-imagined

Plugins & Plugin Development General Plugin Discussion
#41

Has everyone got different expectations of what the tri-state is meant to do?

For me, I’ve left the timer toggled off and created 2 scenes to alter the state from either ON or OFF to VOID.
It works as I expect it to.
Patrick, I’ll have a play with the code later today (if I get some spare time) and see what the changes do.

#42

I’m on a VeraPlus which does have openLuup installed but I manually installed Switchboard on the actual VeraPlus. And I am testing there too.
I also have a VeraLite testbed that does NOT have openLuup installed and I have the same problem.

I’ve set up the test with both Vera and AltUI. Same story on both.

I took the liberty of adding a couple of calls to luup.log in SetVar and can see that it does, in fact set the Status even when the value hasn’t changed but for some reason this does not trigger the scene. ??
Do I need to set up the scene trigger special??

And, thanks for the quick reply.[/quote]

I’ve also confirmed that it sets the Status value every time on both platforms. This is easily seen on both: openLuup always logs all variable changes, and Vera logs them at log level 6.

I’m able to confirm that Vera doesn’t run the scene on repeats as expected. I can also confirm that watch callbacks are not being called when the variable is set but unchanged, so other subsystems and plugins, like Reactor, are also unaware of repeats.

#43

So it’s not just me. I feel a little better now. ???
Except that I could swear it worked OK the first time.

This is the part of coding that I don’t like.
When everything is correct, except that it just doesn’t work!! :frowning:

#44

So it’s not just me. I feel a little better now. ???
Except that I could swear it worked OK the first time.

This is the part of coding that I don’t like.
When everything is correct, except that it just doesn’t work!! :([/quote]

Works great on openLuup! Just like we want! :slight_smile:

For some reason, I think this is a behavior change. I was testing on 1040, which is the most current firmware for Vera3. I also have 963 on a Lite, so I just tested on that, and the behavior is the same. And maybe I’m thinking of openLuup, but I want to say that it hasn’t always been like this. But 963 goes quite a way back, so I’m likely mistaken. If anyone else had any input to the history of this, your input would be welcome.

FWIW, I’ve also tried testing with the rarely used startup parameter to [tt]luup.variable_set[/tt], and testing with it both true and false, and all I learned was that (a) false doesn’t change the behavior we’re looking at, and (b) true doesn’t work as documented.

#45

Any chance a workaround can be found? Any way I can help?
So hard to believe Vera’s documentation could be wrong. (NOT!) :frowning: >:( :frowning:
Thanks,
Jim

#46

Any chance a workaround can be found? Any way I can help?
So hard to believe Vera’s documentation could be wrong. (NOT!) :frowning: >:( :frowning:
Thanks,
Jim[/quote]

I don’t think the docs are wrong for anything we care about/that matters to getting this done on Vera.

For the sake of clarity, the only wrong doc I found was the “startup” flag on variable_set, which is documented as “Optionally, you can add an argument ‘startup’. If startup is true, this change will be considered a startup value, and if the variable is set to it’s [sic] existing value, events and notifications will not be fired” (emphasis mine, ref: http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_variable_set). This statement is incorrect, in that, when this flag is true, current firmware suppresses “events” (which I assume to mean watches and scene triggers at least, and I didn’t specifically test notifications) irrespective of whether the variable is set to its existing value or another value (i.e. it always suppresses events).

But that’s an academic exercise. Vera ain’t gonna do what you want it to do. Very often, those kinds of things point to an X-Y problem: you want to do some big thing, and you’ve decided how you want to get it done, but you don’t know how to do one of the little steps along the way, so now you (and I as a consequence of your post) are focused on that one little step, rather than the actual problem you are trying to solve, which may be better solved another way.

#47

installed this plugin via the GUI: install app to both my Veras today (Veralite and VeraPlus).

The installation to the Veralite when without any issue but on the VeraPlus I got an error that it could not download “L_Switchboard1.lua” retry in 10min.
I retried a few times by triggering an engine restart but as it did not work I then checked from “Luup Files” page in Vera if all other files had been downloaded and then manually uploaded the “L_Switchboard1.lua” file via the “Luup Files” page. Engine restarted automatically and now all was fine.

Thanks for sharing this plugin!!

#48

Thanks for this plugin.

I just installed it on my vera plus. Via the GUI on my PC it works just fine , but I am unable to show the devices on Imperihome on my Android phone.
Any option to have them shown there?

Thanks,
Cor

#49

They show up like any actuators on my android phone? Did you press reload in imperihome?

#50

@Forzaalfa: Ah … interesting; Imperihome crashes since the last update when I reload. I have allready send an email to imperihome. I have rebooted my android device , I " guess" this reloads the devices as well?

edit ,got a workaround by checking “autodetect vera conf. changes” , I deselected that since the screen goes for a milisecond every 5 seconds black… very wierd

Cor

#51

Ok, so I started out at the github pages, and…of course I installed the files in the openluup directory. Is there anything I can do to reverse this? Will anything break?

#52

Remove the files named in the openluup subdirectory from your /etc/cmh-ludl/ directory. DO NOT remove the similarly named files from /etc/cmh-lu, as these are the Vera system versions you need to keep. Then do a Luup reload, and you should be OK.

#53

I’m using virtual switch, but I will try your plungin.
Thank you !

#54

Thanks. Do I need to telnet into the box or something? If so, do you have any pointers on how? I’ve just never seen anyone telnetting into it.

#55

You use ssh to log in as root. The password is printed on the label near the serial number.

If you’re on Windows, I think putty is probably the most common SSH client.

#56

Thanks. WinSCP did the trick :slight_smile:

#57

That’ll work, too!

#58

Wow… I am loving the new Switchboard Switches!
Just replaced all my old VSwitches. Love that that look like regular switches.
Also got to create a tri-state switch, which works great! Love that you added an icon for the Void state. Looks nice.

One question, what is the different between PulseTime and PulseTimeReset? (for regular binary switch)
What do they do with the TriState switches?

Would you consider adding Dimmers to this next? This is a much needed feature in Vera… would allow you to group multiple dimmer switches or z-wave bulbs together (though you probably need Reactor or something soffisticated under neither to send the right commands at the various dim levels). Personally I would use this for my whole house speakers to set the volumn (have a bit of LUA code that can convert the dimmer % to the volumn command that I send to an Itach to control the volumn currently) but couldn’t quite get the bad virtual dimmer switches that Vera provides to work. I used PLEG to monitor the states of the dimmer, but the dimmer sample they gave was bad and would reset itself to 0 when going to 100% and other wierd stuff that I couldn’t debug.

#59

Excellent! Glad you’re having a good experience with it.

ImpulseTime is the amount of time the switch can stay on before it automatically turns back off. If 0, auto-off is disabled (this is the default; time units are seconds). The ImpulseResetTime value is an implementation variable that tracks the time the switch should turn itself off. This is used if Luup reloads during the time delay–by storing the absolute time that the switch should turn back off, when Switchboard is restarted it will know exactly when to schedule the turn-off. It will be 0 unless a time delay is in progress.

Absolutely. Stay tuned…

#60

Just out of curiosity, what would be a use case for a virtual dimmer?