[SOLVED] Help with sending Command

NCO · October 4, 2018, 8:35am

I am using CarLocked and CarLock items as follows:

Switch CarLocked			"Pulpo Verriegelung [%s]"		            (G_jdbc)        {channel="volvooncall:vehicle:xxxxx:doors#carLocked"}
Switch CarLock			    "Pulpo Verriegelung [%s]"				    (G_jdbc)        {channel="volvooncall:vehicle:xxxxx:lock"}
Switch CarUnlock			"Pulpo Entriegelung [%s]"				    (G_jdbc)        {channel="volvooncall:vehicle:xxxxx:unlock"}

rule "Lock / Unlock Car"
when
	Item CarLocked received command
then
	if(receivedCommand == ON) {
		CarLock.sendCommand(ON)
		logInfo("car.rules", "Car: Locked")
	}
	else if(receivedCommand == OFF) {
// NOTE: This just unlocks invisibly the trunk - when opening the trunk, the vehicle will be completely unlocked.
		CarUnlock.sendCommand(ON)
		logInfo("car.rules", "Car: unlocked")
		sendTelegram("OH_TeleBot", "Heckklappe wurde entriegelt.\nDurch Öffnen komplett entriegelbar.")
	}
end

After a while I see the following in the logs:

2018-10-04 10:19:03.095 [vent.ItemStateChangedEvent] - CarLocked changed from ON to OFF
2018-10-04 10:19:03.272 [vent.ItemStateChangedEvent] - CarLock changed from ON to NULL

So it seems that the CarLocked channel resets the state according to the lock status of the car (which is alright).
But at the same time the “lock” item goes to NULL.
Is this on purpose?

Thilo_Wiesner · October 4, 2018, 9:18am

Continuing the discussion from Help with sending Command:

yes, but the channel doesn’t show

rossko57 · October 4, 2018, 9:37am

Just a comment: if that’s coming from the binding, like in the case of a communication error or suchlike, it really ought to be setting the state to UNDEF rather than NULL

NCO · October 4, 2018, 10:19am

I actually don’t know where this comes from.
@glhopital: I guess you know,

Definitely is does not come from my rules, so I assume from the binding.
As the Lock Channel is to send the lock command into the binding only, I assume that it’s reset after a specific time to NULL within the binding…

glhopital · October 4, 2018, 4:03pm

@NCO : these “lock” and “unlock” channel does not exist anymore since I introduced actions. Reason why they switch back to NULL is because they are not found in the channel list.

NCO · October 4, 2018, 7:41pm

Alright.
Thanks.
Which is the lasted one (and where) I could test then?

glhopital · October 5, 2018, 6:59am

The latest one is available as a PR, including binding and actions. You’ll have to use experimental rules engine to use actions as earlier discussed.

NCO · October 5, 2018, 8:33am

Alright. I will try. Thanks
Which build # are you referring to?
I did not find a build of VOC binding since #11052:
https://openhab.ci.cloudbees.com/job/PR-openHAB2-Addons/11052/

tnemrap · October 8, 2018, 7:30am

NCO:

I see a warning in the logs, which might not related to your binding but the Core:
2018-09-24 07:45:08.486 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VehicleHandler of thing volvooncall:vehicle:xxx tried checking if channel doors#tailgate is linked although the handler was already disposed.
Have you seen this as well?

I also have this flooding my logs.

/Mike

NCO · October 8, 2018, 1:46pm

a restart helped in my case.

glhopital · October 9, 2018, 10:22am

You’re right. Travis failed on my last PR.

Jacob · October 18, 2018, 4:01pm

Any chance there will be a build to install from inside of OH gui any time soon? Happy to help and test it out.

NCO · October 23, 2018, 2:38pm

I juste moved to Milstone Build M4.
Could you please point me to the latest suitable VolvoOnCall?
Thanks in advance.

tnemrap · November 21, 2018, 6:04pm

Any updates on this?
I could not find it in M6.

/Mike

tnemrap · December 9, 2018, 11:31am

@glhopital What can we do to get this in OpenHAB 2.4?

glhopital · December 9, 2018, 4:33pm

In fact, the binding itself it - I think- ready, or nearly ready. We miss documentation, but what bothers me is that it includes an action package for the new rule engine and I think I must have @Kai advice on this.

tnemrap · December 9, 2018, 6:35pm

Where can i help with the documentation?

Kai · December 9, 2018, 6:38pm

Is this about https://github.com/openhab/openhab2-addons/pull/3740? Looking at the PR, seeing it is still marked WIP, I fear this won’t make it in the 2.4 release - for this, it should have ideally been finalised this weekend. But let’s plan it as a first candidate for 2.5!

NCO · December 13, 2018, 7:10am

Hi Gael,
Where can I find the latest version?
I just can find this one:
https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.volvooncall/2.4.0-SNAPSHOT/

NCO · December 13, 2018, 8:00am

By the way:

Running the version above I found this (maybe it’s not relevant anymore with a newer version).

2018-12-12 08:00:43.639 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
        at org.openhab.binding.volvooncall.internal.wrapper.VehiclePositionWrapper.getPosition(VehiclePositionWrapper.java:47) ~[?:?]
        at org.openhab.binding.volvooncall.handler.VehicleHandler.getValue(VehicleHandler.java:259) ~[?:?]
        at org.openhab.binding.volvooncall.handler.VehicleHandler.lambda$5(VehicleHandler.java:131) ~[?:?]
        at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) ~[?:?]
        at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) ~[?:?]
        at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:?]
        at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) ~[?:?]
        at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:?]
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:?]
        at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) ~[?:?]
        at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) ~[?:?]
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
        at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) ~[?:?]
        at org.openhab.binding.volvooncall.handler.VehicleHandler.queryApiAndUpdateChannels(VehicleHandler.java:130) ~[?:?]
        at org.openhab.binding.volvooncall.handler.VehicleHandler.lambda$3(VehicleHandler.java:113) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

According to the VOLVO hotline, they had issues with the VOC services - so this might be related.

However, after VOC services were up and running again, the positioning of the VOC binding did not catch up the actual position.
Running the python script by molobrakos did return the correct position.