Is PIM ACK/NAK not evaluated?

[ludvikjerabek]

Is it correct to assume the PIM's ACK/NAK response if being ignored instead of triggering a retry? Since an outgoing UPB packet determines the PIM response ACK/NAK behavior it appears that these responses are not taken into account? Just wanted to validate, but it would be nice to issue a retry in the event that an ACK was expected but a NAK was received.

async def _handle_pim_command(self, pim_command: str, pim_data: str) -> None:
        def _handled_response(done_with_message=True):
            if done_with_message:
                self._write_queue.popleft()
            self._handled_response_event.set()  # enables write stream to start again

        # Ignore PimResponse ACK and NACK
        if pim_command == PimResponse.UPDATE.value:
            reply_from, msg = decode(pim_data)
            if self._is_repeated_message(msg):
                LOG.debug("Repeated message; discarded.")
            else:
                if reply_from == self._awaiting_response_command:
                    _handled_response()
                self._notifier.notify(msg.msg_id, {"msg": msg})
        elif pim_command == PimResponse.ACCEPT.value:
            if not self._awaiting_response_command:
                _handled_response()
        elif pim_command == PimResponse.REGISTER_REPORT.value:
            _handled_response()
        elif pim_command == PimResponse.BUSY.value:
            await asyncio.sleep(PIM_BUSY_TIMEOUT)
            _handled_response(False)
        elif pim_command == PimResponse.ERROR.value:
            _handled_response()

[gwww]

If have never reliably received either ACK or NACK messages from the PIM on my network. Also, over the years the logs I’ve seen from other people’s networks also do not show ACK or NACK messages consistently. Based on that I have not found a use for either message that improves the reliability of the network.

Perhaps there’s something in your logs that indicates otherwise. If so I could consider exploring further.

[ludvikjerabek]

In my case outgoing commands, have ACK-Bit set according to UPB spec and every command to devices has an associated ACK response and failed deliveries trigger a NAK.

bit 6 - bit 4: - ACKRQ: Acknowledge Request

• xx1 = Acknowledge this UPB Packet with an ACK Pulse.
• x1x = Acknowledge this UPB Packet with an ID Pulse.
• 1xx = Acknowledge this UPB Packet with an Acknowledgement Message.

When I send a message, I set ACKRQ_PULSE in the UPB Packet Control Word which results in commands to UPB response of ACK (success) / NAK (failure).

byte ACKRQ_MSG = 0x40 // Message ACK (bit 6 = 1)
byte ACKRQ_ID = 0x20 // ID pulse ACK (bit 5 = 1)
byte ACKRQ_PULSE = 0x10 // Pulse ACK (bit 4 = 1)

As an example, this is an outgoing message

Outgoing Message: 0A14876C0022000001CC
PIM Response: PA
NAK/ACK: PK

[ludvikjerabek]

I should probably add that this is directly from my own driver from another personal project. I noticed that Home Assistant has UPB integration, which is why I looked at the UPB driver. From my own driver writing and some C++ for UPB, I know that the ACK pulses are indeed sent. I have tested against HAI, SAI, and PulseWorx devices as well.

[gwww]

Seems like exploring more might be useful. Here is a typical sequence when I communicate with a device on my network. I'm using the SAI PIM.

2025-10-08 09:06:29.735 DEBUG  Write TX_UPB_MSG '0700C20DFF30FB'
2025-10-08 09:06:29.783 DEBUG  got_data 'PA'
2025-10-08 09:06:30.071 DEBUG  got_data 'PN'
2025-10-08 09:06:30.503 DEBUG  got_data 'PU0800C2FF0D8600A4'
2025-10-08 09:06:30.504 DEBUG  Device status report: 'Outdoors Back Deck' level 0

Note that I receive a PN (NACK) message followed by a PU (Update) message. It is like this for every device. The update message is correct and always gives back the expected status.

I've looked at this many times and cannot figure out why I'm always receiving the NACK. Maybe your fresh eyes on this will help.

[gwww]

I just tried with setting all 3 bits as you describe and I now receive the ACK message. Previous testing I only set bit 4.

I could consider adding an flag (https://github.com/gwww/upb-lib#configuration flag) to request the the ACK pulse and to process ACK/NACK but this would be an opt-in option since no one is complaining that this does not work as is and there is already timeout/retry logic. Turning this handling on would speed up the current timeout processing, which is a positive, although I have never seen a timeout on my network (except for in testing when I use a upb.upe file with devices that don't exist).

The downside of setting all three bits is that in regular operation it takes about another 500ms to sync with a device.

[ludvikjerabek]

Very interesting. In my case only one bit is set for a direct messages. I may need to do some additional testing too. I've always seen the PIM respond with the PK/PN for the direct messages. When the bits were not specified the PN (NAK) is the response after PA. There is obviously no pressure on this, just thought I'd share my feedback from my own driver experience around UPB. What PIM device are you using? I'm using a PulseWork USB PIM but also have DB9 serial PIM which behaves the same. My outgoing code looks at outgoing message, if the message is set for ACK, I wait for ACK/NAC but there are options in the bit flags which have a heavier response, taking longer. The NAK/ACK basic confirmation doesn't seem to cause a massive delay in my case. Synchronization sync/async non solicited messages adds some complexity but overall it's been effective.

[gwww]

I have a Simply Automated PIM that’s about 20 years old.

I’ll poke at the code a bit more and see if anything else comes to mind. I spent a lot of time trying to figure out the ACK stuff when the code was first written and I finally settled on ignoring the bit of the spec. Especially since the code has been reliable.

But, always willing to try and improve!

[ludvikjerabek]

In the message you sent "0700C20DFF30FB" is the control word "0700" NID=C2, DID=0D, SID=FF COMMAND=30 (report state), CHK=FB?

[gwww]

Yah. I did some others with various ACK settings - just didn’t show those.

[ludvikjerabek]

I have a Simply Automated PIM that’s about 20 years old.

I’ll poke at the code a bit more and see if anything else comes to mind. I spent a lot of time trying to figure out the ACK stuff when the code was first written and I finally settled on ignoring the bit of the spec. Especially since the code has been reliable.

But, always willing to try and improve!

Yeah, I am really impressed with your dedication and timely responses. Similarly I got into this for my own selfish purposes in 2004, and worked on my own projects around UPB. I also think your library is quite beautiful and far easier to read than C++, Java, or Groovy which I have worked with around UPB. Personally, I still feel that UPB has an edge over all of the wireless automation switches on the market today. It may be an older technology with some flaws, but it's still running solid 20+ years later.