Happy new year to all.
I am using a HTTP request in my rules to call some Vera actions to control Sonos (play something and TTS). That works well.
@guessed: Any timeline for adding a Vera action binding (with multiple parameters) ?
[quote=“lolodomo, post:1, topic:185625”]I am using a HTTP request in my rules to call some Vera actions to control Sonos (play something and TTS). That works well.
@guessed: Any timeline for adding a Vera action binding (with multiple parameters) ?[/quote]
I hadn’t put a timeline to it, as I’d switched to building an openHAB binding for my Paradox Alarm, but I took a quick look at what it could look like, syntax-wise in Xtend (openHAB’s rule language).
The notes from this are below, for comments (to ease the steps required when I get around to implementing it)
A few things I tried didn’t work out, so I’m not sure how complete the XTend implementation is in openHAB, or whether perhaps it’s just that those features weren’t available in the version of XTend that openHAB is using. In most cases, when it didn’t work, the Rule engine stopped (silently) so it was a lot of trial and error.
Initially, I wanted to use XTend’s Collections, notably this construct:
val myMap = #{'a' -> 1 ,'b' ->2}and apply a UPnP bent to it, so you’d end up with something like:
val sayParams = #{'Text' -> 'Hello from Sonos' ,'Volume' -> 50}which would have looked a lot like luup.call_action parameters, but I couldn’t get that working for the life of me, so eventually I used the more explicit form:
val sayParams = newArrayList('Text' -> 'Hello from Sonos' ,'Volume' -> 50)
Putting it together, the overall call structure would look something like:
[code] callMios(OfficeSonosId, “Sonos/Say”, newArrayList(‘Text’ → ‘Hello from Sonos’, ‘Volume’ → 50))
// or their syntactic sugar version:
OfficeSonosId.callMios("Sonos/Say", newArrayList('Text' -> 'Hello from Sonos', 'Volume' -> 50))[/code]
In both cases, I’d use the Item as the handle to get ahold of both the MiOS Unit as well as the Device Id within that Unit. I hadn’t planned to use the rest of the Device/Service identification information… but I could possibly default the UPnP ServiceId from that IF it’s not been specified in the Command itself (as above “Sonos/Say”, where “Sonos” would be the serviceId alias that we’ve used elsewhere)
For the most part, I’d like to avoid putting the direct Device Id into the MiOS Rule API, as this would make it brittle when devices are changed out. That’s the motivation for using the Item here, even though some of the Item information really isn’t needed.
Thoughts?
That looks good for me.
No urgency as we already have a workaround.
PS: I started yesterday to setup IDE 
[quote=“guessed, post:2, topic:185625”]Putting it together, the overall call structure would look something like:
[code] callMios(OfficeSonosId, “Sonos/Say”, newArrayList(‘Text’ → ‘Hello from Sonos’, ‘Volume’ → 50))
// or their syntactic sugar version:
OfficeSonosId.callMios("Sonos/Say", newArrayList('Text' -> 'Hello from Sonos', 'Volume' -> 50))[/code]
…[/quote]
Just an update on the support for scripted MiOS calls in openHAB Rules…
I have first-cut prototype of this working. I made some tweaks along the way, and the code is messy and not ready to be rolled back into the mainline, but the core of it works.
I have a test-rule that looks like:
[code]rule “Test action rules Off”
when
Time cron “4/5 * * * * ?”
then
sendMiosAction(GuestBedroom2LightsId, “Dimmer/SetLoadLevelTarget”, newArrayList(‘newLoadlevelTarget’ → 0))
end
rule “Test action rules On”
when
Time cron “2/5 * * * * ?”
then
sendMiosAction(GuestBedroom2LightsId, “Dimmer/SetLoadLevelTarget”, newArrayList(‘newLoadlevelTarget’ → 100))
end[/code]
and it does preity-much what you’d think it would do…
I changed the Action name to sendMiosAction (and sendMiosScene) to be more consistent with the naming used for the existing openHAB Action extensions.
The remaining things to do before pushing them to Git and submitting a PR are:
[ul][li]P1 Cleanup the code structure, since it’s currently awkward with the tweaks made to allow the MiOS Action [OSGi] Add-on to talk to the MiOS Binding [OSGi] Add-on.[/li]
[li]P2 Add some sort of Command-queue for HTTP calls sent to the MiOS Unit, to avoid failures due to too many threads hitting on Vera at the same time.[/li]
[li]P3 Work out why the syntactic-sugar version (eg. GuestBedroom2LightsId.sendMiosAction(…)) doesn’t work.[/li][/ul]
Depending upon how much spare time I have, I may submit after P1 and work later on P2 & P3.
If anyone really wants to try out this version, let me know as I haven’t updated the online JAR version of it in a while now.
Submitted MiOS Action Binding as PR #2025 in order to get initial code-review comments, and a “build” version of it in the 1.7.0 code line.
Until it’s merged, you can read the Documentation for the new Action methods here:
https://github.com/mrguessed/openhab/tree/mios-action-binding/bundles/action/org.openhab.action.mios
There are still a few items on the todo list, but I wanted to get a version out early, since folks have been pinging me for this.
[quote=“nwootton, post:6, topic:185625”]@guessed
A heartfelt thank you for this. Roll on release 1.7![/quote]
You’re welcome! I figured it was better than wasting folks time by having them build the work-arounds
Ok my apologies @guessed - can you provide the shorthand of what the main benefit is of this new callMios() capability over the sitemaps/items I’m already using? I hadn’t followed the whole thread and it may be difficult trying to find the value in the thread this far out. 
PS - for anyone who has been hoping we would one day have a ZWave based LED bulb, I recently found one on Amazon - http://www.amazon.com/gp/product/B00PJH16UC/ref=oh_aui_detailpage_o06_s00?ie=UTF8&psc=1
While they are expensive, they operate with the Vera. Though I did have to turn off the Auto Configure function because it kept coming up with errors. It works though and had full dimming capability. I personally use them for nightstand lights and will be setting rules to gradually dim the lights as it gets later. Helping to ease the bedtime rituals and getting in bed at a reasonable hour!
The declarative SiteMaps/Items mechanism are the easiest approach to integration, and will handle most user’s needs.
But there are cases where you need to explicitly call you Vera unit during a Rule execution and/or where the form of that call isn’t a simple, single-parameter, Bind.
eg. Any UPnP-style call with more than one parameter
eg. Any UPnP-style call where you want to compute a value and pass the parameter value more explicitly.
There are a couple of UPnP API’s floating around that have more than one parameter, and here are a few examples:
[ul][li]the Say method of @lolodomo’s Sonos Plugin[/li]
[li]the SetPollFrequency(PollingEnabled,PollMinDelay) action of some HaDevice1 ServiceId’s[/li]
[li]the RequestArmMode (State,PINCode) action of urn:micasaverde-com:serviceId:AlarmPartition2[/li][/ul]
For these, you’ll need an openHAB Rule, and the sendMiosAction(…) call…
[quote=“guessed, post:5, topic:185625”]Submitted MiOS Action Binding as PR #2025 in order to get initial code-review comments, and a “build” version of it in the 1.7.0 code line.
Until it’s merged, you can read the Documentation for the new Action methods here:
https://github.com/mrguessed/openhab/tree/mios-action-binding/bundles/action/org.openhab.action.mios
There are still a few items on the todo list, but I wanted to get a version out early, since folks have been pinging me for this.[/quote]
This PR has been approved, and will be available in Cloudbees Nightly build tomorrow, allowing users to perform the [tt]sendMiosAction()[/tt] within Rules.
The merged Documentation is here:
openhab1-addons/README.md at main · openhab/openhab1-addons · GitHub
I will update Forum links when I get a few cycles.
I’ve also uploaded new Untested build, including:
[ul][li]this openHAB Action change AND;
[/li][li]pre-merge changes for reducing the logs (and Item Change events) generated by openHAB PR #2183
[/li][/ul]
for those not wanting to wait, esp for the log/update optimizations. Both JAR files are needed if you want to use the new MiOS Actions within Rule files.
I just tried the new sendMiosAction to call either Sonos/Say or Sonos/PlayURI and it is working well 8)
The only problem I have is that in openHAB Designer, I get an error “Couldn’t resolve reference to sendMiosAction”.
For information, I have not the same error when I use sendHttpGetRequest.
My imports in my rule file are only
import org.openhab.core.library.types.*
import org.openhab.model.script.actions.*
import org.joda.time.*
import java.util.regex.Matcher
import java.util.regex.Pattern
I just replaced the two new 1.7 jars in my 1.6.2 setup.
Any idea ?
Howdy,
I’m dealing with this too (the fact the designer doesn’t recognize the action). It appears that the actions are pretty embedded into the designer and adding a new one isn’t trivial. That said, I’m trying and think I’ve found most of the places that the designer is looking. I have an active query going on the OH google groups and hope to get something soon.
[url=https://groups.google.com/forum/#!category-topic/openhab/hhL0wUakpko]Redirecting to Google Groups
Once I find out what has to be done, I’ll post back here.
Gerry
Just an idea: maybe we should use designer v1.7 ?