I just finished testing a program that monitors new variables assigned to a device under the advanced tab. Take a look at the screen shot. The variables at the bottom are the ones I created. You can create them in a minutes time and read or write to them in Luup Code. It is a long process to create virtual switches and they only handle on / off. This might be a better way to go…Food for thought!
I can finish my code generator now that I am done with this…i believe it will be easier to write code if you can monitor the variables in the code…also you can push timers forward and watch results quickly.
Thoughts?
Tim
Excellent work Tim!
Your ideas here will save myself (and others hopefully) a LOT of headaches trying to implement “virtual switches”.
Thanks for the help,
bob
[quote=“FlyBoyBob, post:2, topic:168381”]Excellent work Tim!
Your ideas here will save myself (and others hopefully) a LOT of headaches trying to implement “virtual switches”.
Thanks for the help,
bob[/quote]
@Guessed gave us the parameters in another thread…bottom line is to use a unique service ID, in my example it is “Tim”, and then give the variable what ever name you want. It works great!
I will be creating an “Enable” variable to over ride timer scenes when you want them switched off.
A “timer” variable for things like “door open for more than X amount of time”.
A “time” variable for things like “is it between time X and Y”
and more.
Regards
Tim
FYI,
This method can be used without my software. Another advantage of this method is to expose variables you want to change.
EG. Create a variable called “offset” and use it to control how many minutes before sunrise to switch on.
Now using the Vera UI and going under the advanced tab where you created the variable, you can type over the value and press the “save” button and the offset is changed to the new value without digging into you Luup code.
More to come…
Regards
Tim
@TimAlls, Can you provide an example(s) (I too am a visual learner ???) as to how you could use your technique, vice creating a virtual device (VD). I was going to create a VD that would turn “On” if both of my locks are locked and turn “Off” if one or the other door is unlocked for both a visual indicator and implement within Scenes. I saw the new report capability but did not realize who to interpret and/or use it. Mike
One point to note is that UPnP control points won’t understand an user-defined service/variable. By using virtual Luup devices that adhere to the UPnP specification, chances are that UPnP control points are able to control your virtual Luup devices.
@Guessed indicated to use a unique service ID so that it can’t be changed by anything but user code…
Explain if you agree or disagree…or did I misunderstand him?
Regards
Tim
I am revising this post…new Service IDs being created and new example will be posted
later today. Thanks …Tim
For more info read all the responses.
…
open a device and goto the advanced tab
Create a new Variable at the bottom…first the Service, for this example use “Tim”
Then the Variable…enter “TimeA”
Under Value enter “10:00”
Close and Save (UI bug…don’t try doing more than one…only the last one will be saved)
Create another Variable at the bottom…first the Service again make it “Tim”
Then the Variable…enter “TimeB”
Under Value enter “11:00”
now start a new scene and give it a job to turn off a light nearby.
goto the timer section and add a new timer to run every minute.
goto the Luup tab and paste in the following code:
local startTime = luup.variable_get(“Tim”,“TimeA”,52)
local endTime = luup.variable_get(“Tim”,“TimeB”,52)
local hour = tonumber( startTime:sub( startTime:find(“%d+”) ) )
local minute = tonumber(startTime:sub(-2))
startTime = hour * 60 + minute
luup.variable_set("Tim","STime",startTime,52)
hour = tonumber( endTime:sub( endTime:find(“%d+”) ) )
minute = tonumber(endTime:sub(-2))
endTime = hour * 60 + minute
luup.variable_set(“Tim”,“ETime”,endTime ,52)
local currentTime = os.date(“*t”)
currentTime = currentTime.hour * 60 + currentTime.min
luup.variable_set(“Tim”,“CTime”,currentTime,52)
luup.log("startTime = " … startTime … "; currentTime = " … currentTime … "; endTime = " …
endTime)
if startTime <= endTime then
– Both the start time and the end time are in the same day:
– if the current time is in the given interval, run the scene.
if startTime <= currentTime and currentTime <= endTime then
luup.variable_set(“Tim”,“Between?”,“Yes”,52)
return true
end
else
– The start time is before midnight, and the end time is after midnight:
– if the current time is not outside the given interval, run the scene.
if not (endTime < currentTime and currentTime < startTime) then
luup.variable_set(“Tim”,“Between?”,“Yes”,52)
return true
end
end
luup.variable_set(“Tim”,“Between?”,“No”,52)
return false
I recommend you paste the code first into notepad for editing and saving.
Replace the ID number “52” with your ID number to the device holding the new Variables
If you have my program with variable watch run it now…select your device and the new variables will pop up.
Four more will be created automatically “STime”, “ETime”, “CTime”, and “Between?”
These variables represent Start Time, End Time, Current Time, and is it between those times.
If you are not running my program it will work under the Vera UI but its slower because the UI does NOT update its variables until a complete refresh is done on the UI. ( that means hit the refresh button at the top right and press save)
Using the advanced tab you can change the variables in your program…the 10:00 and 11:00 are your start and stop times so play with it…if you are running my program you can see the current MIOS time with each update every two seconds. Try changing the times to the next minute and watch your variables update.
This is an example of an event that runs from time A to B and knows what to do do if they are on different days (after midnight)
The variable “Between?” is very important because it can be used in other Luup codes with very simple:
local BetweenTime = luup.variable_get(“Tim”,“Between?”,52) (use your ID of course.)
If BetweenTime = “Yes” then
turn up stereo to 100% and blow the neighbors away…or whatever.
REMEMBER…that the scene only runs once a minute…so you must wait for the scene to execute in order to see the variables change. Be patient and have fun!
Is this starting to make sense?
Regards
Tim
@Guessed indicated to use a unique service ID so that it can't be changed by anything but user code... Explain if you agree or disagree.....or did I misunderstand him?
IMHO, adding user-defined services/variables to preexisting Luup devices is a hack that might work - but are we really sure that adding user-defined services/variables to standard (upnp, micasaverde namespace) Luup devices doesn’t break Vera clients (SQ Remote, iVera, …)?
Do you want Vera clients to display your user-defined services/variables? If your answer is ‘no’, user-defined services/variables might be the way to go. If your answer is ‘yes’, you should use virtual Luup devices.
I would like to know as well…
MCV, if you are reading please advise. This method works great, but is it going to continue working and are there effects on the system by creating User Service ID’s…
PLEASE ADVISE!
Regards
Tim
Is there an easier way? Ap15e
I keep asking but nobody has an answer…We need variable watch!
An additional point to note is that AFAIK there is no easy way to remove user-defined services/variables …
What was the odd behavior you were experiencing, and how did ‘variable watch’ help in solving it?
How would you ever pick out the errors unless you can see the results of math[...]Looks like the result of the math is logged to the log file?
I noticed that too!
On the plus side…Vera creates the user variables when they are placed in Luup code…so it would seem that they are saying ok…go for it! I still want to hear from them to make sure…
Just tested the SQRemote and no ill effects.
I know how they derive their device list so I wasn’t too worried about that one, but I don’t know about others.
By the way…I would have used virtual devices but to my knowledge they only exist for the binary switch.
So I am putting it out there…who has a better way to create variables that can be EASILY monitored? This IMHO is very very important. (example posted)
Regards
Tim
What was the odd behavior you were experiencing, and how did ‘variable watch’ help in solving it?
How would you ever pick out the errors unless you can see the results of math[...]Looks like the result of the math is logged to the log file?[/quote]
Yes it is logged as well…not everyone can run my variable watch program, just do the math…Hours*100 + minutes = total minutes?
The math is faulty and so the results are unpredictable.
I understand that one can simply look at the log files but most Newbies are overwhelmed by the code and never make it to the log files.
I was able to debug it by adding variables after every calculation and then watching the results…that is how it helps.
Regards
Tim
Do you want Vera clients to display your user-defined services/variables? If your answer is 'no', user-defined services/variables might be the way to go. If your answer is 'yes', you should use virtual Luup devices.You misunderstand my intentions.....this isn't for me or my programs, it is to help the user's write code. The same with the upcoming code generator. Many of us look at the code as Chinese.....and because of that not even try to write code. I am just trying to improve what Newbies can do and hopefully inspire them to go further with what is possible. Keep it mind that this is not my expertise.....so I will listen to the experts here tell me....."don't do that!" I will drive you crazy asking why not though!
Regards
Tim
[quote=“Ap15e, post:9, topic:168381”]
@Guessed indicated to use a unique service ID so that it can’t be changed by anything but user code…
Explain if you agree or disagree…or did I misunderstand him?
IMHO, adding user-defined services/variables to preexisting Luup devices is a hack that might work - but are we really sure that adding user-defined services/variables to standard (upnp, micasaverde namespace) Luup devices doesn’t break Vera clients (SQ Remote, iVera, …)?
Do you want Vera clients to display your user-defined services/variables? If your answer is ‘no’, user-defined services/variables might be the way to go. If your answer is ‘yes’, you should use virtual Luup devices.[/quote]
To be clear, my original note said specifically NOT to add them to the existing Namespace, and to create a new namespace for these to go into. UPnP “things” are permitted to support and expose multiple namespaces, not all of which are standard. They have specific naming conventions, outlined in the spec, for the non-standard namespaces which should be conformed to but there’s nothing stopping people from using these. I also recommended that Tim avoid using duplicate Names, within these newly defined Namespaces, in order to avoid poorly coded CP’s.
The downside, as you point out, is there’s no way to “remove” these Variables once they’ve been created. I believe this has already been bugged, but it a small price to pay compared to an explosion of Dashboard Devices, and resulting scale problems for Vera, but both options are valid techniques.
The other risk run with a Custom namespace, is that the Vera Advanced UI’s may not now and/or always handle escaping/encoding correctly. If this happens, and you put “interesting” data into it, then you run the risk of not being able to navigate to the Advanced tab. Of course, this would be a poorly coded UI, and a bug in MiOS, as we already know 8)
Tim, you’ll want to read that part of the spec as “Tim” isn’t a valid/conforming namespace, even for a custom one.
@Guessed,
Thanks for the clarification…can you give me a link that will educate me as to “Namespace” and the proper use. As I mentioned, I am way out of my expertise on this one.
I thought is was a creative way to solve some problems though!
If the downsides to this are too great one could simply use this to create working code and then switch to general variables.
The pro’s are enormous…not just debugging but also letting users change variables without rewriting their code…that is a big plus IMHO!
Regards
Tim
@Guessed, should I remove this post until it is an approved method by our more advanced users? I don’t want to Brick anyones machine!
Also, your reply make me think you favor this method over Virtual Devices…Am I understanding you correctly?
Tim, you'll want to read that part of the spec as "Tim" isn't a valid/conforming namespace, even for a custom one.You all must be getting quite a laugh at my attempt to program! Ha
[quote=“TimAlls, post:17, topic:168381”]@Guessed,
Thanks for the clarification…can you give me a link that will educate me as to “Namespace” and the proper use. As I mentioned, I am way out of my expertise on this one.
I thought is was a creative way to solve some problems though!
If the downsides to this are too great one could simply use this to create working code and then switch to general variables.
The pro’s are enormous…not just debugging but also letting users change variables without rewriting their code…that is a big plus IMHO!
Regards
Tim
@Guessed, should I remove this post until it is an approved method by our more advanced users? I don’t want to Brick anyones machine!
Tim, you'll want to read that part of the spec as "Tim" isn't a valid/conforming namespace, even for a custom one.[/quote]
You all must be getting quite a laugh at my attempt to program! HaNot at all, I strongly encourage it. Most of us learn by making mistakes, and none of this stuff is going to sink the Bismarck ;)
On http://UPnP.org, there’s a document ZIp download that you can get the specs from. Specifically:
UPnP-arch-DeviceArchitecture-v1 ... pdf
In here, it shows the definition for the [tt][/tt] block, and the naming conventions that must be used, quoted here for reference:
For non-standard services specified by UPnP vendors, MUST begin with “urn:”, followed by a Vendor Domain Name, followed by “:serviceId:”, followed by a service ID suffix, i.e., “urn:domain-name:serviceId:serviceID”. If this instance of the specified service type (i.e. the element above) corresponds to one of the services defined by the specified device type (i.e. the element above), then the value of the service ID suffix MUST be the service ID defined by the device type for this instance of the service. Period characters in the Vendor Domain Name MUST be replaced with hyphens in accordance with RFC 2141.
In yourcase, you end up with something like [tt]urn:allseas-com:serviceId:[/tt]
Where is of your choice, largely, but the string overall must be <= 64 bytes, and the Service names are expected to be initial-capital for each word used in them
Thanks Guessed,
So much to learn and so little time!
I will update this thread as quickly as I can.
Regards
Tim
Nowhere does the conversion imply, or is used as ‘total minutes’ though. It’s a conversion to a single number for easy comparison. The left-shift of the hours by 2 positions preserves an easy readable format of the variables in the log file, for debugging (e.g.: 22:30 → 2230, 05:30 → 530)?