Question on the socket protocol about pigpio HOT 12 CLOSED

That is correct as far as it goes.

Notifications are a method of getting updates when one or more GPIO change level.

The procedure is as follows:

Notify Open: returns a handle to be used on subsequent calls. The handle is a small number x >=0. A pipe is created at /dev/pigpiox to receive the reports.

Notify Begin specifying the handle (x) and the GPIO of interest. GPIO changes are then written to /dev/pigpiox in the form of 12 byte reports.

Notify Pause (optional) specifying the handle (x): to temporarily pause (discard) GPIO reports until another notification begin.

Notify Close specifying the handle (x). Notifications are stopped, the pipe (/dev/pigpiox) is closed, and the handle x is put on the free list of handles.

This is fine as far as it goes but pipes are only accessible from the local Pi.

So a modification was made to allow the use of sockets.

If a NOIB (Notification Open In Band) message is received on a socket the notification open does not open a pipe. Instead any data which would be sent to the pipe are now sent to the socket. You could still send commands to the socket. The problem is that the command response might be intermingled with GPIO notification messages. It might be possible to disentangle the mess but it is simpler just to use another socket for commands. So use two sockets, one to receive GPIO state changes, and one to send commands. That's what I do in the Python module, in piscope, and in the pigpiod_if library. Look in those for examples.

On your specific question. When you do the NOIB you will get a handle. Use that handle in requests sent via the command socket when issuing notification begin, pause, and close commands.

from pigpio.

Ok, thanks for your answer. That's exactly what I do, so there must be something else bad in my code, I'll investigate that when I get home.

from pigpio.

Hi,
I forgot to get back to you but everything is working great, thanks!
If you don't mind I'll probably publish on github an asyncio version of the python client lib in a few days.

from pigpio.

Glad it's sorted.

No problem publishing your software. pigpio is fairly stable at the moment. It has pretty much all the features I think are useful. I will be adding functions on an irregular basis if I find them useful.

Look forward to seeing your library.

I'll close this as an issue.

from pigpio.

Hello joan2937,

I don't understand the structure of the data that arrive every minute.
May you explain me?
For example:
00 00 40 00 B5 FC 1A 9F 4F C1 01 00
01 00 40 00 4F 84 AE A2 4F C1 01 00
02 00 40 00 D7 0E 42 A6 4F C1 01 00
03 00 40 00 F4 95 D5 A9 4F C1 01 00

Joey

from pigpio.

@Joey-1970 See http://abyz.co.uk/rpi/pigpio/cif.html#gpioNotifyBegin and PI_NTFY_FLAGS_ALIVE.

from pigpio.

Hello Joan,

thanks for your answer!

Now a may ask, if it ois a possible Option to change the output of Notification - equal to the other answers, with a lenght of 16 and in the first bytes the identifier ("command", for example 111). So I think it would be easierer to know what message comes.
You can identifier it by the lenght, but sometimes there are more messages in one row, so you have the problem to select what is what.

Is it conceivable to change or to expand PIGPIO?

Joachim

P.S.: Maybe you can start NOIB with 99,0,0,0 for len of 12 or with 99.1.0.0 for 16 charakters with identifier first...

from pigpio.

It is certainly possible to change the message structure. It's not something I will be doing though.

My suggestion is to use two sockets, one for commands and one for notifications. On the socket for notifications send the single command NOIB. Thereafter only use that socket to receive notifications. Use the command socket to update the GPIO to be notified if that is required. This is what I do in piscope, the Python module, and in the pigpiod_if2 library.

Using two sockets, one for commands, one for notifications, also seems more natural, and to my mind leads to a cleaner design.

from pigpio.

Thanks again for your answer!

Do you thing about a delimiter, that shows the end of this transmission? (Or is there one and I don't see it?)

Take two sockets may solve some problems, but maybe not if the communications is so fast, that it would show in only one row...
(If you know the lenght you can cut it, but not when it is variable, I2C for example...)

Joachim

from pigpio.

Hello Joan,

when will you split it into two sockets?

Joachim

from pigpio.

I will not make any changes to the notification handling.

I'm suggesting you open two sockets in your program (like I do in the programs I mentioned above).

from pigpio.

Okay, I misunderstood you, sorry...

Now, I have done it and it is better to treat!

Thanks again!

Joachim

from pigpio.