[danieljo]

@ Curlymo: Same Problems i posted earlier one or two months ago.

I have actually the same Problem in my Ad-Hoc network and an RPi 2 with a 8 Port Relay Card on my Fish-Tank. I comment out the check function and compiled it manually so the Relays don't go in off state after a lost connection or pilight daemon reset.

[terrar]

Instead of commenting out and manually compile pilight i would like to put this into /etc/init.d/pilight to execute it after start or restart the service:

Code:

pilight-control -d neon -s on
pilight-control -d fog -s on
pilight-control -d fan -s on
pilight-control -d fanfog -s on
pilight-control -d neon -s off
pilight-control -d fog -s off
pilight-control -d fan -s off
pilight-control -d fanfog -s off

It seems easier for me to do this after every pilight-update than always compile pilight manually.

I tried this in the console and it works for me to get the control over the relay ports back.
If the relay ports can be controlled again by pilight the rules manage the rest.

Can you tell me exact the lines where i have to insert it in/etc/init.d/pilight so that its executed when starting and restarting the daemon?

2nd way (and easier for me) would be a new setting in the config for executing a script after start or restart.
Something like:

Code:

"execute-after-start": /home/pi/script.sh
"execute-after-restart": /home/pi/script.sh

[danieljo]

@terrar: This is a very simple and good idea for this problem at time.

Im hope curlymo can fix this Problem in future with Relay protocol and the permanent resets in Ad-Hoc Network.

[curlymo]

Can someone summarize the issue here?

[terrar]

Summary:

If using relay's with pilight 7 stable and also development after every reboot the state of the relay's is "on" in the webgui but "off" in real.

To get the correct state again you have to switch every relay device off/on/off in the gui. Without this pilight does not recognize the real state of the relays.

Error is also reported in issue #201 on github

[curlymo]

A GPIO can be set as input or output. The problem is that as soon as you set the GPIO as input, the already set state cannot be read.

Example:
1. Set GPIO as output
2. Set GPIO as HIGH
3. Set GPIO as input
4. Read GPIO

This will result in a LOW reading while the GPIO is still HIGH.

So, reading the state of a relay cannot be implemented. What we can implement is a "bootstate". So as soon as pilight starts, it will set all relays to this state.

[wo_rasp]

The problem with the GPIO is even more complex. First of all the GPIO lines are General Purpose IO Lines, and that is the issue here. The GPIO interface has no provisions for what you are asking for.
During the boot sequence of the Pi, the state of the GPIO lines changes twice, before the final status of last known configuration of the pull up/down resistors is restored. Thus the first problem arises at this point in time.
AFAIK at this point in time, the OS has no clue whether the GPIO lines were used last as Input or Output lines, thus the logical state of the GPIO lines is still undetermined.
After start of the application, the application needs to remember its last state.
The current concept of pilight is doing so by reading its last config.json file. If pilight was able to terminate properly, it restores the last known state, if pilight was not terminated properly, well - there is a big question mark.
IMHO, for a 100% reliable solution to work, you do need to latch the states of the GPIO lines on an interface board, use some logic for latching and set/reset the latch registers using some kind of additional interface logic (strobe signals either edge or pulse triggered), and read the status of those latches back upon restart (using a R/W interface line and one or two address bits).
For the latches we were using 245 chips to implement 8 data lines. Nowadays you may want to look into 74LCX16245 chips. The strobe signals/RW/address lines can be implemented using rules.
Remember the aforementioned boot behaviour, while implementing the latch interface and logic.

[TEN]

Could https://wiki.pilight.org/doku.php/relay be wrong by omission that is expects a rather rare PNP transistor (which is less common than NPN for a reason), and that the default-state parameter inverts only the GUI display but not the effects of -t and -f (leading to obvious confusion) ?
If this is the case, the expected circuit diagram should be disclosed, especially since the load does not always have to (nor will) be an electromechanical relay where the effects could be remedied by swapping its NO and NC pins.

[curlymo]

Where do you read the NPN advice?

[TEN]

Where do you read the NPN advice?

I don't. Just trying to make sense of the implementation with high=off (as reported throughout this thread), where one explanation would be that https://wiki.pilight.org/doku.php/relay expects PNP (unusually for GPIO on a μC):
So the actual schematic it tries to imply would be useful.