Fixed: OUTPUT-GPIO-1-ON/off only works when inverted

The OUTPUT-GPIO-1-ON/off piBeacon Model parameter when setting a new device only appears to turn on and off a given GPIO pin if "OUTPUT type" is set to invert.

This, I believe, may have been a problem for some time as I have only just got around to diagnosing the problem since weeks back when it first appeared.

I have tried setting "OUTPUT type" back to normal again and the problem breaks again. I have also tried creating a new OUTPUT-GPIO-1 device on a different GPIO and the issue is the same - only able to switch on and off when the "OUTPUT type" is set to invert, otherwise it is always 0, and then only able to be set to 1 using the gpio command on the rPi itself.

should be fixed in v .548, just posted

Hi Karl,

I've tried .548 but it is still exhibiting the same issue I'm afraid.

It only does anything when set to "set OUTPUT invers" (perhaps should read: set OUTPUT inverts). When set to "set OUTPUT normal" it stays on 0 whether on or off.

yes you are right: I fixed the wrong (old) program.
The process is not anymore in the program execCommands.py (called from receiveCommands) but IN receiveCommands in threads
That saves ~0.8 secs of execution delay

I did that last summer and I did not remember any more


Will post the fix later today

Karl

Hi Karl - just tried v550 and it's still the same (and still says invers and not inverts)

I tried mine and it works.
Could you post a screen shot of the device edit screen


Sent from my iPhone using Tapatalk

and re invers vs inverted ..

the function is
inverse to xx
inverted

as I have "inverse" everywhere and hard coded in states and programs I hesitate to change that one

Karl

Aww, you could at least put an 'e' on the end of invers

Please see screenshot - the device On/Off output is always 0 unless set to inverse, Here you can see the device is on yet physical pin 37 is shown as 0. It is also 0 when off.

Always0.png (287.56 KiB) Viewed 2704 times

Did you actually measure the voltage on the pin?


Sent from my iPhone using Tapatalk

Hi Karl,

I don't need to measure the pin voltage, I use a Python app to read its value.

The GPIO utility shown in the screenshot always stays on 0 unless the device is set to invers when I switch the device on and off. For now, to get around the problem before you fix it, I have modified my Python app to read this value the other way around and have set the device to invers. I could have just left it at that but I though I'd highlight the issue to you so that others do not run into the same problem using this piBeacon device type.

Note that this was working previously for about 2 years.

Put simply:
set OUTPUT invers = OK
set OUTPUT normal = FAIL (always 0)

I don’t understand, mine works fine.

I will post a version w some debug info on the rpi

Karl


Sent from my iPhone using Tapatalk

As an FYI, the piBeacon plugin option Set GPIO pin on rPi to HIGH-LOW option does not work either when the device is set to normal. Only works when set to invers; and when set to invers, setting the pin to LOW sets it to 1 which took me by surprise. I would have expected the ON/OFF to inverse the 0/1, but not the HIGH/LOW setting, but I'm not that bothered

please try v 7.139.552

then set debug on for the rpi you want to check

the ssh pi@...

tail -f /var/log/pibeacon

there you should see somethuing like this :

Code: Select all


25-19:43:58 receiveCommands execCMDS             L:367  Lv:20 1645814638.30 next command: {u'restoreAfterBoot': u'0', u'startAtDateTime': 0, u'pin': u'21', u'inverseGPIO': False, u'devId': 1742808216, u'command': u'up', u'device': u'OUTPUTgpio-1-ONoff'}
25-19:43:58 receiveCommands setGPIO              L:228  Lv:20 1645814638.31 setGPIO pin=21; set output to 1
25-19:43:58 piBeaconUtils   setLogLevel          L:65   Lv:10 cBY:receiveCommands      setting debuglevel to on
...
25-19:43:59 piBeaconUtils   echoToMessageSend    L:2208 Lv:10 cBY:receiveCommands       msg send --- {"outputs":{"OUTPUTgpio-1-ONoff":{"1742808216":{"actualGpioValue":"high"}}},"program":"receiveCommands","ipAddress":"192.168.1.25","pi":"5","ts":{"tz":"CEST","time":1645814639.35}}


Thanks Karl.

I installed from v7.139.550 straight to v7.139.553 and it worked straight away after it had installed. I've subsequently rebooted everything again and everything seems stable.

Thank you !!!

it might have been that the push of the new py programs to the RPI did not work and the old py programs were still running.

but anyway thanks for the feedback

Karl