Hi,
after setup my MS Visual Studio Code with the OH extension I recognized, that the IDE throws me some error on createTimer functions. the IDE says, that the parameter of now,plusSeconds needs to be an integer.
Is that correct? I also used something like “2.2” and the rule worked, but I never checked the correct time countdown.
BR
It’s REALLY hard to help if you don’t post the actual code it is complaining about.
But I can say that now,plusSeconds is wrong. It needs to be now.plusSeconds(n) where n is an int.
I don’t know if you can pass a float to now.plusSeconds.
Hi,
at highest respect, but I dont agree with you that you need a complete code for this question. the comma was a typo.
your last sentence would solve the question, if you would now it 
actually I can pass a float, the rule does work, the timer get executed. but I dont know if the function cast it to an int. But I believe so.
I didn’t ask for the complete code. I asked for the line of code with the error. But what the hell do I know. I’ve only been helping people on this forum for years. You, of course, know better what I need to know in order to help clearly.
To be clear, I still don’t know what your actual problem is. I don’t know if you’ve solved it. I don’t know if VSCode is still complaining, but if it is complaining it most certainly is a problem. I don’t even know what you are trying to accomplish. But clearly I should still know enough to help.
Good luck with that.
I dont understand why you are writing with so much fury. Also words like “highes respect” should cause the opposite of this. Is it not possible to critize someone or have another opinion?
So my question is just simple and maybe my sentences are not clear because my english is not so good… but the question is: the function plusSeconds excepting integer or is float also allowed… I was just try to find out if the MS VSC intellisense is wrong because a rule where I’m using plusSeconds with a value of 2.2 does work.
and I stay with my opinion: for this question no line of code is required. sorry if my question and sentences wasnt clear for that!
Because despite the niceness at the beginning you basically said despite my years of experience helping people on this forum you think you know better and do not need to share details.
A vague question like you asked takes me minutes to trans off minutes to even understand what is being asked. And even then I have to guess.
If you party there line that caused the error and the error reported I can tell you what is wrong and how to fix it in 30 seconds.
So when you “respectfully disagree” you are telling me my time and my expertise don’t matter. I could care less about what you think about my expertise. But my time and more importantly the time of everyone else who hello out on this forum is precious.
My response reads angrier than I intended or felt when I was working it, but I admit I was miffed. Until this past I never did understand what your original posting was asking and I spent far too long trying to figure it out.
To answer the question about the intellisense, VSCode connects to and uses the exact same parts of your OH server to check the code as OH uses to parse your .rules files. So if VSCode says something is wrong it’s wrong.
The fact that it is working with 2.2 may be party of some of the built in ability of Xtend to convert values as necessary most of the time. Joda DateTime, the class for now, only defines plusSeconds(int) which is why VSCode is complaining. But Xtend treats all numbers as BigDecimal which has an intValue method which converts the BigDecimal to a primitive int. I do not know if intValue truncates or rounds. But no matter what it does, you are sending an int to plusSeconds. And all of this conversion stuff happens at runtime.
This sort of weakly typed conversion is really hard to deal with using intellisense so I suspect it is throwing the error or warning because all it sees is you are trying to send a float to a method that only accepts an int. It isn’t until runtime that the language can figure out that it can handle that after all.
I would still expect to see the same error reported in openhab.log.