Supplying full path in script should work, but keep in mind that if the called path itself calls other binaries, it might not work. Try including PATH=/usr/local/bin:/usr/bin etc, make sure that all paths are included.

You should start domoticz with the -log argument, just add this under the last DAEMON_ARGS line in /etc/init.d/domoticz.sh: Restart domoticz to start logging to /tmp/domoticz.log (or whatever path you want).

bigpea wrote: ↑Thursday 19 October 2017 21:00 One question, the lenght of the text (string type) in the domoticz.variables, have a max number of char?
I have some problem when I try to insert one String.

The limit is set to max 200 chars. Fix for this one (empty value) is coming soon

Ah interesting, thanks for letting us know! I think the full paths to both node and js file would be sufficient? Or is it really necessary to use sh?

I didn't catch the idea about "showing up in the log should be solved". I updated to the v 3.8390 and what? Please, write a little bit more about it? Thank you! I meant the line which prints 'dzVents' in your second post, while it should print 'LUA'. This is pure cosmetic, but fixed in the latest ...

You could try something simple like this, it should print the current date in /tmp/test.log: #!/bin/bash echo $(date) > /tmp/test.log If you update to the latest beta, the mix-up of dzVents / Lua lines showing up in the log should be solved (but that has nothing to do with your issue, just to make ...

You could try using those actions instead, but that doesn't explain why it's not working with Lua.. When using script:// you should set it like this: script:///bin/bash etc (triple / and full path to bash). It might work for you, because it calls the scripts without Lua involved. If in doubt, I ...

You could try using those actions instead, but that doesn't explain why it's not working with Lua.. When using script:// you should set it like this: script:///bin/bash etc (triple / and full path to bash). It might work for you, because it calls the scripts without Lua involved. If in doubt, I ...

What about /bin/bash? And the cannot open dzVents.lua error is suspicious, something seems wrong with your installation. Could try disabling dzVents under settings -> other, restart domoticz and see if at least that error message is gone?

Verstuurd vanaf mijn SM-N930F met Tapatalk

It seems that dzVents log line is printed instead of Lua, which sometimes seem to occur for yet unknown reason (it's harmless). So the example/test script is working, it just tries to match on all device changes, which results in those nil value messages. Try to add the full path to screen in os ...

Not checked / tested it myself, but can't you just use armAway().afterMin(20)?

My main question still remains: Why is the state in the GUI different from the state which I call in the scripts. I cannot get my head around that one. The GUI is right in my opnion when I look at my door and at the state :) Because there is no event generated for the slave device when being ...

But you see the logic in the script? When 'something' from Achterdeur_Open arrives (could just be On every time), it will set Achterdeur to On. If 'something' from Achterdeur_Dicht arrives (could also just be On every time), it will set it to Off. Achterdeur must change it's status, really weird if ...

And the script should just work, period :lol: Just make sure you've got 3 devices (1 dummy, 2 RFLink) and maybe to be sure, first add the 'Achterdeur' as On/Off switch, not a Door type. Also check for On and Off status instead of Open / Close while testing this... Believe me, tried it, tried it ...

Yes the GUI gets it's info from DB directly, so no strange behaviour here and all as expected ;)- So why not get the right data that way? If only I knew how :) Because it now accidentally works for you and gives the correct value, but it's not intended to use the way you do, resulting in unexpected ...

Yes the GUI gets it's info from DB directly, so no strange behaviour here and all as expected ;) Well then I'm out of options then, because the script above should definitely work if you've got 2 separate RFlink devices sending the On status (or Off, doesn't matter). But to be clear: We're not ...

Ah I understand what you mean. You should create a dummy device as master and add both RFLink devices as slaves to it. Now you should get the correct status on the dummy device.. Edit: Well I think I understand it, is it correct that you have 2 RFLink devices, one only triggers when door is open ...

Ah I understand what you mean. You should create a dummy device as master and add both RFLink devices as slaves to it. Now you should get the correct status on the dummy device.. Edit: Well I think I understand it, is it correct that you have 2 RFLink devices, one only triggers when door is open and ...

Yes, danny described it thorough. Conclusion for now: Only switch master through slaves only, not directly or via scripting. The trick in this case would probably just adding a second slave and use that for the timer. Could you explain that a bit more? Bot, master and slave, are devices which are ...