Share Position -> shares your position for all people (family, members) that owns your Tracking code, you can share it using the menu Show my code. You can change this code, so this stop tracking all persons that own the old code. The rest api will work in this mode.
Do not share position -> the app tracks your position but does not share it, so also if you shared your tracking code, people can’t track you when you choose this option. The rest api will work in this mode.
Stop tracking -> the app does not track at all, in this position the app does not work for tracking neither for fire rest api events. It can be useful if you have to save battery cause in this mode the app do not use battery at all.
Regarding the rest api the app works in this manner:
When you are coming back home and you are close to it, the internal switch of the app “comeback” is switched ON and command Rest Api Back Home is sent to the openhab server with the ON value. I used in my openhab server a rule that does some tasks when receive the switch ON value like opening gate, switching on the lights if it’s dark, fires a scenario, and so on… and at the end of the rule switchs the item that was fired from the app to OFF. In the side of the app, when the app knowns that the command is correctly received from openhab, turns the “comeback” switch to OFF, but does not send any other command to openhab. The internal “comeback” switch can’t fired again if you don’t go almost 250 meters far from house, so it prevents to fire it when you are still at home, causing gate open switch external lights on etc… In other words, the item Rest Api Back Home is a one-shot switch and is fired only when you come back home.
The Rest Api Presence instead sends the command ON at the indicated item when you are at home and remains ON for all the time you stay there. When you goes out, the app send the command OFF to the inserted item. The app continue trying to send the command until receives the acknowledgment from openhab server.
If could be useful for you, I can share some example for openhab rules and switchs. It works perfect for me and I use it other than fire a scenario when I come back home, also for set my home in a kind of “standby” mode when there are not presences inside and resume the regular mode when I come back. It is very useful for power saving.
Bye,
1 Like
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
22
Thank you for that explanation.
I haven’t got your app working correctly yet, so I think this info will help me.
// switch backhome
Switch backhome
// switch presences
Switch imathome "Me at home"
Switch mywifeathome "My wife at home"
this is the backhome.rules
rule "backhome_rule"
when
//ITEM BACKHOME FIRED FROM LOCATOR APP REST API
Item backhome received command ON
then
{
// SEND THE COMMAND TO OPEN THE GATE
sendCommand(gate,ON)
if (Elevation.state instanceof DecimalType)
{
if (Elevation.state < 0)
// IF IT'S NIGHT TIME IT SWITCH ON THE
// EXTERNAL LIGHTS AND BOX LIGHT
{
sendCommand(ExtLight1,ON)
sendCommand(ExtLight2,ON)
sendCommand(boxLight,ON)
}
}
// WAIT 6 SECONDS BECAUSE THE GATE IS OPENING
Thread::sleep(6000)
// OPEN THE BOX DOOR
sendCommand(BoxOpen,ON)
// SWITCH OFF BACKHOME SWITCH
postUpdate(backhome,OFF)
// YOU CAN ADD OTHER COMMANDS HERE
}
end
in the presence.rules
rule "none_at_home"
when
Item imathome received update or
Item mywifeathome received update
then
{
if (imathome.state == OFF && mywifeathome.state == OFF)
//NONE AT HOME
{
sendCommand(switchalllightsoff,ON)
sendCommand(switchoffallexternal,ON)
// YOU CAN ADD OTHER COMMANDS HERE
}
}
end
For sure, you can add more code to trap, for example when the two (or more) presences change in ON/OFF - ON/ON etc.
My configuration is much more complex, but I simplified it for clarity.
Hope this help you
Hi,
I made some changes to the app, one is the new parameter in Rest Api menu that can set the number of retries after stopping sending backhome command to the server, cause some users reported that 4 retries (that was the fixed value) could be insufficient, so now it’s possible to set a value from 1 to 10.
Another change is in the log procedure that now is more detailed and I fixed a bug that in some cases did not report all the connection rows in backhome procedure.
Please, test it and send me a feedback,
Thanks,
Nicola
1 Like
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
25
Hi
I think I’ve finally managed to put the correct information into the right places
13-04-2019 19:01:44 - trying connecting local Url: http://192.168.178.42:8080
13-04-2019 19:01:46:/rest/items/Stu_Presence - Error local Url does not reply: java.net.SocketTimeoutException: timeout
13-04-2019 19:01:46 - trying with Remote
Remote Url: https://home.myopenhab.org
13-04-2019 19:01:47 - connection Ok,/rest/items/Stu_Presence set to: ON
13-04-2019 19:01:46 - trying connecting local Url: http://192.168.178.42:8080
13-04-2019 19:01:48:/rest/items/Stu_Presence - Error local Url does not reply: java.net.SocketTimeoutException: timeout
13-04-2019 19:01:48 - trying with Remote
Remote Url: https://home.myopenhab.org
13-04-2019 19:01:49 - connection Ok,/rest/items/Stu_Presence set to: ON
Hi Stuart,
yes it seems to work, I didn’t tried it cause I don’t use myopenhab.org
You can check it, if you didn’t yet, putting the switch Stu_Presence in your sitemap.
Moreover, it’s better to put the same switch in persistence, if you use one. It will prevent to assume a wrong value when, for example you have to restart openhab.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
27
Hey Nicola
I’m happy to report that EVERYTHING is working well now.
I don’t use BasicUI, but HabPanel is showing the status of the items.
I’ve added the Item into my presence rules now too.
My aim is to achieve the following.
When everyone has left the property, OH activates the house alarm AND checks that we’ve remembered to lock the doors & close the windows.
(I have tiny microswitches in the door lock striker plates that the lock mechanism/s press against)
If we’ve (read “I’ve”) forgotten to lock the doors fully, OH will send us all an SMS and a OH cloud notification.
Yes i agree, that would be a very nice feature and would make it easy to react for example with rules to the current position of the smartphone-user.
In my opinion it should work similar to the AlarmClock-Feature. The App should frequently update a string-Item that contains the coordinates of the GPS-Position (or just the position estimated by the mobile network). Perhaps the string could be compatible for example to the NMEA-2000-format.
Is there anyone currently working on a feature like this?
Hi, I’m using this app and, after many tests to put the right values inside the settings now it works very well!
I have only an issue: all the members of the family have the app installed on the phone so when we come back home together the scenario Rest Api Back Home in the Rest Api Setting fires many times.
Is there a way to avoid it?
Thanks
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
33
Have you tried setting up seperate Items for each member of your family?
Or, can you group the items and run the Rule when the Group switch changes to ON ?
Thank you very much for the reply!
I’m sorry but I saw that I didn’t explain the question in the right way.
I’ll try to explain my problem better. I wrote a rule that opens my gate when I’m near it using the Rest Api Back Home function in the app and it works very well when I or another member of my family comes back alone but, when we come back together with 2 or more phones, the app of each phone starts the rule and, cause my gate accepts only one command for open, close and stop I obtain that the gate opening starts but it stops after few seconds because another phone sends the same command.
It happens only when we come back together and reading the log it was confirmed because more than one phone sends the same command.
Thanks
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
35
Oh I see.
So you can’t simply use a group, because you need the next returning person (if not together) to also trigger the rule.
So really, you need a way to limit the amount of triggers per minute ?
I’m not sure how that’s done, but is that the kind of rate limit you’re thinking of?
In my very rough approach, I’d add a variable or state Item that locks out repeat actions for a period of time.
So a rule might trigger and first check the state of a ‘trigger lock’. ???
If you wanted a really dirty solution, you could put the rule to sleep using a thread::sleep(5000) command, but there are thread issues to consider.
I think you have more options to solve this issue.
One quick and dirty it’s to use the expire binding using an item like this:
Switch wd_comeback {expire=“2m,command=OFF”}
this is a kind of watchdog that you can use to watch if someone fired the rule before.
In the rule you can write something like this:
rule “backhome”
when
Item scenariobackhome received command ON
then
if (wd_comeback==OFF)
{
sendCommand(wd_comeback,ON)
####
#### SEND YOUR COMMAND FOR GATE OPENING
}
end
In this case only the first phone can send the command because it switch ON the wd_comeback and the condition to send the command is not satisfied for another. After 2 minutes (that I think it’s enough), the wd_comeback switch turns automatically OFF.
Another more “scientific” but more impactful option is to use a contact sensor to test the status of the gate instead of the wd_comeback switch.
Hope it helps…
2 Likes
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
37
Thanks, I hadn’t worked out how that binding functioned.
this is the contents of the Items file that I got working.
Switch Expire_2_Min "Expires after 2 minutes" { expire="2m,command=OFF" }
Switch Expire_30_Sec "Expires after 30 seconds" { expire="30s,command=OFF" }
