Again, thanks for your detaile response and sorry for the delay.
Never mind - I guess I won’t need it anyway
Weatherunderground might become an issue, but I can also still retrieve data.
I guess I will try the new OpenWeatherMap binding…
I actually get the coordinates from the dashboard.
For car theft I compare if the engine starts and no one is around.
That does work kind of ok, but the problem is, that the location is not updated while the car is in use.
So I usually check whether my wife or I have been close to the car within a 5 minutes time frame when the engine started:
val Number dist = (CarDist.minimumSince(now.minusMinutes(5), "jdbc").state as DecimalType)
I have to confirm that even after some more tests I’m not able to control the horn and lights of my Volvo. I’m not so interested in, as it is a function that I rarely use. For the temperature I use the HERE
weather service. In Node-Red I read the api, parse the temperature and push the value further with MQTT. The value is always identical with the value indicated by the VoC app.
Since, I think a recent update, the coordinates of the car are also available in MQTT and are published under the topic owntracks/volvo/abc123. This makes the use of voc owntracks obsolete.
Regarding the “theft” function I do not have a solution yet. My car is mostly to close to my house so that even if we sleep the “coordinates” are overlapping . So if someone starts the engine the “system” might think we are nearby and we are. As long as the coordinates are not updated if the car moves, we cannot detect it in a reliable way. So if (“theftAlarm”: null,) is supported we can used that. If not we have to wait fore more reliable solution. Fortunately theft is not a daily event.
Regarding position.
Does anyone know what the intention is of:
“calculatedPosition”: {
“longitude”: null,
“latitude”: null,
“timestamp”: null,
“speed”: null,
“heading”: null
Anther option, I look at is:
“sendPOIToVehicleVersionsSupported”: [
“sendSinglePOIToVehicle”
I have switched from voc script to the binding.
I have one question though:
The doc /https://www.openhab.org/addons/bindings/volvooncall/) mentioned to access the commands through a classic rule:
Does this mean that I can
closeCarCommand(“volvooncall”,“volvooncall:vehicle:myVinNumber”)
in a classic rule?
Or is it still required to be run in the ERE within PaperUI?
When using the code on the doc site I get: Pulpos available Actions: org.openhab.binding.volvooncall.internal.action.VolvoOnCallActions@xxxx
In the NRE I get three same Things when trying to map the commands.
Even after deleting the actual thing.
So I assume that there are some old Thing configs!?
My Bridge’s ThingId is: VOC_API
My vehicle’s ThingId is my VIN_Number
but I get: Rule 'Lock / Unlock Car': An error occurred during the script execution: index=0, size=0
I guess this looks better: URL https://vocapi.wirelesscar.net/customerapi/rest/v3.0/vehicles/VIN_Number/unlock returned The service was unable to start
Weird, this works on my side. So for a reason or another, answer from the service is different. But the error should be catched at binding level. Can you file an issue ? Thanks
I´m getting along as well (managed to customize the 2.5.0 binding to work on OpenHab 2.4.0, i.e. some issues with BaseDynamicStateDescriptionProvider used, which is not compatible with OH 2.4.0).
Anyways, I’m testing rules for VOC as well, and what I have figured out:
I still need to use getActions and not actions.get, i.e.
val actions = getActions("volvooncall", "volvooncall:vehicle:VIN")
Having DEBUG enabled, it seems like the correct way of getting action commands through is to use volvooncall:vehicle:VIN. So my rule for testing “Start Engine” looks like:
rule "VOC Engine Start"
when
Item BevFolerVaskerom_FhSwitchChannel changed to ON
then
val actions = getActions("volvooncall", "volvooncall:vehicle:VIN")
if(actions===null) {
logWarn("VOC", "Actions not Found")
return
}
else {
logWarn("Volvo", "VOC - Actions")
actions.engineStartCommand(15)
}
BevFolerVaskerom_FhSwitchChannel.sendCommand(OFF)
end
This rule worked one time, afterwards I get: Action status : FAILED for vehicle : VIN
Regarding the different commands: openCarCommand: This one just times out for me, no response/error engineStartCommand: Managed to get this one working, but is now failing. heaterStartCommand This one replies: The car VIN does not support remoteHeater. Which my Volvo V90 XC (´18 mod) most certainly does, and I can control the heater via the VOC app.
So, you don’t use any ID of the API (just the car’s thing ID (like my Heater example above)!?
I will give this a try again.
However, the main functions I would trigger with these actions are start/stop Heater and open/close (engine start is not supported by my XC60).
So I guess, I will need to stay with a hybrid setup (voc and binding).
Anyway - I will try your syntax.
Thanks for sharing and your help @Stian and @glhopital
Yes, agree, the Engine rule is really not relevant, and was just presented as a test example. However, the action command could just be replaced, i.e engineStartCommand —> heaterStartCommand or openCarCommand.
Also, I am not using API ID in the call address. Not sure if this is correct, but see from DEBUG that the binding responds when using the presented call address, e.g “engineStartCommand called” and “heaterStartCommand called”. As mentioned, I managed to start the engine. So, in your case, the call address would be: volvooncall:vehicle:VIN_NUMBER
Not sure why the other commands don’t work. Maybe things/channels are recognized and generated differently for different models/locations? @glhopital?
And @NCO, are you willing to share/explain how you use your hybrid setup? I am really looking for a solution where I can implement VOC into triggered rules: E.g, when Good Morning switch change to on, if month, day and time meet criteria, heaterStartCommand. This way I can remove timers in the VOC app, and thus avoid activating heater on days off (which would be activated based on app timer).
Thanks, I got the right syntax I guess. At least I get a proper response:
2019-10-25 12:35:24.474 [WARN ] [nal.handler.VolvoOnCallBridgeHandler] - URL https://vocapi.wirelesscar.net/customerapi/rest/v3.0/vehicles/VIN_NUMBER/unlock returned The service was unable to start
2019-10-25 12:35:36.029 [INFO ] [pse.smarthome.model.script.car.rules] - Car: Lock command sent
2019-10-25 12:35:36.098 [INFO ] [call.internal.handler.VehicleHandler] - The car VIN_NUMBER is already locked
Even though Lock / Unlock and Heater does not work, I assume the reason is different.
I actually use the voc binding from @glhopital for updating the items.
For sending the commands I just use the python voc script by @molobrakos due to the issues above. /usr/local/bin/voc -u 'xxx' -p 'xxx' heater start
Previously I have read the state of the car using the dashboard: /usr/local/bin/voc -u 'xxx' -p 'xxx' dashboard
Have tested further today, and have managed to customize the binding to be able to use heater start in rule:
So, my findings for my Volvo V90 XC ´18:
My V90 does not support remoteHeater, but supports preclimatization. I.e. modified the binding to run preclimatization/start instead of heater/start when action heaterStartCommand is run.
As part of preclimatization, a {} attribute is required, which I now have implemented into the binding.
So the engineStartCommand and heaterStartCommand now works for me.
I have now customised the binding and have working rules both for handling lock (open tailgate / close when all doors open), handling heater (on/off) and for starting engine.
As previously mentioned, some Volvo models apparently have remoteheaterSupport, while others have preclimatizationSupport (like my Volvo V90 XC). So I have customized the binding to have both heaterStart/StopCommand() and preclimatizationStart/StopCommand() available to be used in actions, and a revised actionHeater in the binding to be able to handle both.
Additionally, based on the Volvo on call bundle used for Homey, I see that there is an “{}” attribute included for both heater/preclimatization start and for lock doors. So I have implemented the attribute, and now all the commands work as they should for me.
Could do a PR, or make the jar file available for others to test if interested.
Also see that the honk/blink command is insufficient as is for the OpenHab binding, as location (long,lat) apparently is required included, although, I can not foresee this being a relevant command for me.
