Yeah, I don’t think the update triggers work in 2.5
We’ve talked about this before but I don’t think I was clear about what I need to do. What I need is to send data to OH from my phone (amongst other things). How do I do that?
Maybe I never needed to expose the items if I use the REST API. In that case, the problem I have must lie elsewhere.
DOH! It was an account problem on my phone. Sorry. Delete everything I said.
Thousands of users testify otherwise. This is basic functionality since OH 0.1
There might be confusion about the term ‘update’ in openHAB context. When you want some help with that, show example.
This was already discussed at length here:
The conclusion was that all the solutions offered (GroupMemberUpdateEventTrigger, UpdateEventTrigger) were for OH3 only. I’ll see if I can get around to doing some more tests, but the ones I’ve tried (UpdatedEventTrigger (with a “d”), ItemStateUpdateTrigger) don’t seem to do anything.
If you are using the phone app, I know at least the Android app has the ability to send some phone related stuff to specific Items.
- phone events like an incoming phone call
- alarm time
- call state
- battery level
- charging state
- wifi name
- DND mode
Using Tasker you can send anything Tasker knows (which is pretty much everything) to openHAB through the openHAB plugin.
I don’t know as much about iOS’s app capabilities.
Without the apps, you would need to use the REST API of openHAB to PUT or POST commands/updates to Items. When you are not on your LAN, you would need to do so through myopenhab.org’s server. What ever you are using to issue the HTTP PUT and POST commands will need to be able to handle basic authentication with myopenhab.org.
There really isn’t anything specific that needs to be done to individual Items to achieve this. Once authenticated with myopenhab.org, all of the REST API is available to you (at least in OH 2.5, in OH 3 there is an additional authentication step to access parts of the REST API, but not for Items so what ever you do for now will still work in OH 3.
Exposing Items in the Cloud Connector is not necessary and in fact wouldn’t do anything to support this use case even if it were still enabled.
Anyway, I wrote all the above before I saw that you figured it out but I’ll leave it in case future readers find some use from the list of possible approaches.
For OH 3 everything here with “Trigger” in the name are the possible triggers.
For OH 2 your best bet is probably looking at the Python triggers.py from the Helper Library which provides the implementation that parses the “Member of Foo changed” to the Trigger Objects that need to be passed to the Rule.
Search for “Trigger” and you should see all the ones that are supported in OH 2. Note that for Items the triggers are (lines 126-132):
- ItemStateUpdateTrigger
- ItemCommandTrigger
- ItemStateChangeTrigger
Also take note of how Member of triggers are handled. What actually happens is all the members of the Group are pulled and a separate trigger is created for each member. The JavaScript Helper Libraries do not handle this I think so you’ll have to do something similar in your code. Then to see which Item triggered the rule you use event.itemName. Note there is a limitation where you’ll have to reload the rule when the Group membership changes. There is no event to tell you when a Group membership has changed so there is no way to automate that.
One work around you can find in the various Python rules I have at GitHub - rkoshak/openhab-rules-tools: Library functions, classes, and examples to reuse in the development of new Rules. (e.g. Debounce) which creates a Switch Item that you can command ON and have the rule reloaded/recreated with the new triggers.
1 Like
Do you mean that I’d have to create a separate trigger for each item? My conclusion from testing is that there is an inconsistency: if I use ChangedEventTrigger(“gRecordLastUpdate”) on a group, it works as expected, that is, I get a notification of a change to the value of any item in the group and I can obtain the item name and act accordingly. This allows me to have matching timestamp items with the same names as the items, but with _LastUpdate appended. With one rule I can handle changes to all of them. But if I try the same with UpdatedEventTrigger(“gRecordLastUpdate”), it doesn’t work. However, both UpdatedEventTrigger and ItemStateUpdateTrigger seem to work for individual items - but obviously that forces me to specify all of the items, negating the point of the group.
I expect OH3 will provide relief, but in the meantime I’ll just have to list the items separately.
Essentially yes. But you don’t need to type them by hand. In the Python version is looks for a trigger definition string that starts with “Member of GroupName”, pulls all the members of GroupName and creates a separate trigger for each member. I would expect something similar to be done in the JS code where instead of creating a single rule trigger, you would loop through the members of the Group and create a trigger for each.
That’s not how ChangedEvent is supposed to work. It should trigger only when the state of the Group changed and event.itemName would be “gRecordLastUpdate”.
Even in OH 2 the timestamp Profile was available. Is there a reason you are not using that instead of a rule for this?
1 Like
OK, dynamic triggers. I haven’t tried those. Maybe if the number of items grows it’ll be worth it.
I’ve never understood what the “group state” means. As far as I can see, it triggers every time one of the group members has its value changed. If this isn’t the intention, what are groups for?
The profile solution (which I didn’t know about until yesterday or the day before) only works, as I understand it, with things and channels. It wouldn’t work with thing-less items that I’m updating remotely. It would be a solution for a couple of sensors that don’t have their own timestamp items built in, but since I have the rule I almost prefer to have one solution rather than two.
See Items | openHAB. A Group’s state is an aggregation of all the states of its members. For example, the average of all temperatures or the count of ON Switches or “ON if one Item is ON else OFF” type logic. Whenever a member changes state, the aggregation function runs and updates the Group’s state with the result.
Therefore, if you had a Group defined something like:
Group:Switch:OR(ON,OFF) gMySwitches
gMySwitches’s state will be ON if one or more of it’s members are ON and OFF if all of its members are OFF. And thus triggering a rule with Item gMySwitches changed should only trigger when gMySwitches’s state changes and the triggering Item is gMySwitches, not one of its members. That’s how it has always worked since OH 1.6.
It wasn’t until OH 2.2 (IIRC) that Member of gMySwitches triggers were added which would let you trigger a rule based on events from the members of gMySwitches. Prior to that there was no good way to know at all which member of gMySwitches triggered the rule.
Finally, Groups can be used to command all the members of the Group all at once. When you sendCommand to a Group Item, that command is forwarded to all of its members.
Group state is derived from some aggregation of members states.
It follows that if no optional aggregation s specified, there’ll be no group state update.
Caution; because aggregation is calculated in an iterative way, you can get more Group state updates than the single member Item change that began the chain.
Member Items may update without change. Because there was no change, I don’t think this triggers any aggregation, so no Group state update.
Member Items changing should generate Group update events (if there is an aggregation), and may generate Group change events.
None of that has anything to with “Member of” rule triggers, which totally ignore Group state and Group events.
One more thing to add is that even in Rules DSL which has Member of rule triggers, the code that actually parses and loads the rule actually unrolls that into a separate trigger for each member behind the scenes similar to how the Python helper library does. That’s why you have to reload your .rules files to pick up changes in Group membership.
OK, that’s clear. So in the case of timestamp triggers, “by design” the only way to take advantage of the group functionality would be creating triggers dynamically?
In OH 2.5, yes I think that’s the case. It does look like in OH 3 they created proper events and triggers for members of Groups.
1 Like
Right. I think I’ve fully grasped this trigger business now. I might park the problem for now, since I intend to upgrade to OH3 at some point in the not-too-distant future.
I’ve recreated most of my Zipabox rules in openHab, including control of heating, cooling, ventilation, blinds, awning, Sonos speakers and one or two Z-Wave sockets. I’ll try to add the Alexa skill today (I seem to be in a bit of a pickle because I bought the first Alexa device in the UK, but I’m in Spain. If I go to the Amazon UK page I get “You are not eligible to enable this skill due to geographical restrictions.”. If I go to the Amazon.es page I’m told to go to the UK page. The app goes blank when I select the openHab skill. I’ll try with the tablet, which has a new Android version.)
I’m missing the Fibaro Z-Wave sockets that openHab couldn’t detect properly as a secondary controller. For the moment I’ll leave that until the end, when everything else is ready and I can hopefully switch everything over in a weekend. The Fibaro flood sensors are also missing, but they’re not exactly critical. The non-existent sockets are wrapped in objects so I can reference them in the rest of my code.
To validate the openHab rule calculations, I’m sending the same values from the Zipabox and openHab to side-by-side columns in a Google Sheet every 10 minutes so I can check for errors. It’s an effective method - I’ve already found quite a few bugs.
I’ve managed to get the blinds and awnings to go the desired position purely with timers (they’re “dumb” RTS devices) and I think I’ve cracked getting Sonos to interrupt my music with alert messages, one room at a time.
There’s still quite a lot to do, but maybe in a couple of weeks I’ll be ready to unleash openHab on my flat. Before then I’ll upgrade to OH3, though - no point in introducing another source of bugs after I’ve given it control of my house.
I solved the Alexa thing. Just had to change the country registered in Amazon to the UK, install the skill and then change it back again.
I’ve add WeatherUnlocked weather info and AirVisual weather/pollution info. For now I’ve just ported the functions I used in Google App Script and I call them every ten minutes. No nice bindings or anything. Maybe later.
It seem as if switch/case doesn’t work with strings in JSR223/Javascript. This:
switch (sAirVisualCode)
{
// Clear sky
case "01d":
case "01n":
{
logInfo("AirVisual weather code matched: clear");
codeWeather = WeatherCode.CLEAR;
break;
}
// Few clouds
case "02d":
case "02n":
{
codeWeather = WeatherCode.MOSTLY_SUNNY;
break;
}
// Scattered clouds
case "03d":
case "03n":
{
codeWeather = WeatherCode.PARTLY_CLOUDY;
break;
}
// Broken clouds
case "04d":
case "04n":
{
codeWeather = WeatherCode.MOSTLY_CLOUDY;
break;
}
// Shower rain
case "09d":
case "09n":
{
codeWeather = WeatherCode.SHOWERS;
break;
}
// Mist
case "50d":
case "50n":
{
codeWeather = WeatherCode.MIST;
break;
}
// Rain
case "10d":
case "10n":
{
codeWeather = WeatherCode.RAIN;
break;
}
// Snow
case "13d":
case "13n":
{
codeWeather = WeatherCode.SNOW;
break;
}
// Thunderstorm
case "11d":
case "11n":
{
codeWeather = WeatherCode.THUNDERSTORM;
break;
}
}
always drops through to the default (which I omitted here). It doesn’t matter whether I use single or double quotes. In GaS it works fine. I just converted it to if…then…else 