*Digital* UDP Virtual Inputs

[Rob_in]

Evening all,

So today I finally got round to connecting our home-brew extension in the garage. This is basically just a Raspberry Pi with 4 relays, 7 switches, a DHT22 temp/humidity sensor & couple of PIRs connected to it. Works like a charm but... there are some funnies in the Miniserver that I'm curious about so hence the below...

As far as I can tell there are only 3 ways to get *instant* input into the Miniserver:

1. Loxone's proprietary tree devices.

2. KNX.

3. UDP virtual inputs.

4. 1-Wire fobs? Maybe? But the doco reads like you can only have one reader (or input) per 1-wire extension so that sounds like a non-starter.

Everything else seems to be done on a polling cycle so no good for switches. So naturally I chose to have the RPi spit out UDP messages and create virtual inputs in Loxone Config. In there I have this in the command recognition for the first input (the rest are the same, just the number changes):

switch.1.\v

The '\v' value the RPi spits out is either a one or zero as you press/release the switch - this works perfectly and can be seen in the UDP monitor.

You'd think then, that one should check the 'Use as a digital input' box, but that doesn't work. If I check this box it simply doesn't do anything (watching in Liveview) even though you can see UDP packets arriving in the monitor. If you leave that unchecked, yes, everything works as expected.

So what's the problem? Well - I just rebooted the Miniserver which came back thinking one of these inputs was high. No idea why, but that's no good - it was stuck on as of course the RPi won't send an 'off' (zero value message) until the switch is toggled (guess I could change that in the S/W and might, but still...). Thus problem is:

1. What's with the Miniserver coming back online after a reboot with this value? Seems a bit odd to say the least. There's no 'remanence' checkbox in UDP inputs so one would assume they would always come back with the default value (which is set at zero).

2. What is 'Use as a digital input' meant to do? Clearly it doesn't take \v as true/false, one/zero, etc. so what does it do?

Any ideas?

Cheers,

Robin

P.S. Please don't berate me for building something home-brew. I treat the house as 'mission critical' so have all the good stuff(tm) in there (all branded, good quality gear) but the garage isn't so important and wanted to tinker as I like to do that sort of thing. Doesn't hurt that it's hundreds of $$$ cheaper either! ;)

[Tico]

'Use as a digital input' should work but the pulse will be too quick to see anything in Liveview. Try hanging a monoflop of at least a second duration on the UDP input. This will make the pulse visible.

Recognising that the UDP input will only pulse with 'Use as digital input', you then need to work out what sort of logic to use to retain the 'state' you're switching with the Pi. Something like a Retractive Switch might be suitable.

I don't know why the input is coming back high. 'Use as a digital input' might solve that problem though.

[Rob_in]

On Monday, 2 September 2019 01:47:54 UTC+2, Tico wrote:

Recognising that the UDP input will only pulse with 'Use as digital input', you then need to work out what sort of logic to use to retain the 'state' you're switching with the Pi. Something like a Retractive Switch might be suitable.

Ahhhh... thank you for the clarification. So this is similar to the 'KNX/EIB Extended Sensor ' type, yes? Basically, a packet/datagram/whatever received one time triggers a very short pulse and therefore no 'off' packet/datagram/whatever is necessary. I don't suppose the '\v' is necessary either in such cases as it doesn't matter what value is in the packet - if it is recognised a very short 'true' pulse is triggered.

That *almost* makes sense ;) I don't suppose this is documented anywhere?

While this would work for push switches (well - for clicks - you'd have to detect a long press in the sending device and implement a second packet value for that), some of the inputs I'm talking about are door sensors which need to send a true on/off signal to Loxone that would obviously last longer than the transient pulse of a push switch.

So the Loxone description of a 'Use as digital input' is sort of misleading as these can only be used as transient pulses and not true digital on/off signals of any duration. For that one must leave said checkbox clear.

At least that explains what's going on. I may leave this for now but tinker with it in the future.

Cheers,

Robin

[Rydens]

Hi Ron_in,

another way to communicate, which I use, from Pi to Loxone is by virtual inputs (the first one on the list). 

On the Pi you can send 'http://admin:Pass...@192.168.x.xx/dev/sps/io/Turn_on_shelf/Pulse' 

where obviously:  change password password and IP address to that of your Loxone server.

Then in Loxone create a virtual input with the name Turn_on_shelf and I tick use as digital input.

You then have a VI you can drag into logic to trigger whatever you want.

Works well for me.....and fast

As I understand it with your UDP approach there is no guarantee of delivery where as my TCP approach should be more reliable. 

Cheers David

[Rob_in]

On Monday, 2 September 2019 09:12:11 UTC+2, Rydens wrote:

another way to communicate, which I use, from Pi to Loxone is by virtual inputs (the first one on the list). 

On the Pi you can send 'http://admin:Password@192.168.x.xx/dev/sps/io/Turn_on_shelf/Pulse' 

Ahhhhh... thank you for that. Very useful as I agree with you that TCP is much better than UDP for the reason you mention.

I found this method documented here...

https://www.loxone.com/enen/kb/web-services/

... and only tangentially mentioned on the virtual I/O doco page. Sigh... the Loxone doco does leave a bit to be desired!

Thanks again, will have a play with this. BTW, I assume one can create a user specifically for Virtual I/O with lesser privileges as I do not want to use the admin user with credentials hardcoded somewhere for sure!

Cheers,

Robin