Announcement

Collapse
No announcement yet.

Waiting for ACK?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Waiting for ACK?

    Hi Stipus

    I enabled debug mode of the PLCBUS plugin because I having an issue. All commands arive perfectly at the modules but it seems that the plugin is expecting an ACK. The log is full of "PLCBUS Error : Too long wait for interface response to command" messages. The module responds to the command given but I can see by the flashing of the blue led on the module that the command is sent more than once.
    The ACK setting is disabled in the pluging.
    Below is a piece from the log where I switch module A11 OFF.
    Why is the plugin sending the command more than once? Is it still waiting for an ACK? How can I suppress these extra transmissions, the module is responding so they are not necessary.
    Restarted HS, unplugged the PLCBUS transceiver, but it didn't help.

    <table border="0" cellpadding="0" cellspacing="2" width="100%"><tbody><tr><td colspan="1" class="LOGDateTime0" align="left" nowrap="nowrap">20-7-2011 21:09:35 </td><td colspan="3" class="LOGType0" align="left"> PLCBUS Debug </td><td colspan="8" class="LOGEntry0" align="left">PLCBUS Error : Too long wait for interface response to command: (255) A11 Off Data1:0 Data2:0 Tx:False AckReq:False Ack:False IDreq:False Id:False 3PhReq:False RiscOK:False PlcBusOK:False</td></tr> <tr> <td colspan="1" class="LOGDateTime1" align="left" nowrap="nowrap">20-7-2011 21:09:33 </td><td colspan="3" class="LOGType1" align="left"> PLCBUS Debug </td><td colspan="8" class="LOGEntry1" align="left">Sending: (255) A11 Off Data1:0 Data2:0 Tx:False AckReq:False Ack:False IDreq:False Id:False 3PhReq:False RiscOK:False PlcBusOK:False</td></tr> <tr> <td colspan="1" class="LOGDateTime0" align="left" nowrap="nowrap">20-7-2011 21:09:31 </td><td colspan="3" class="LOGType0" align="left"> PLCBUS Debug </td><td colspan="8" class="LOGEntry0" align="left">Sending: (255) A11 Off Data1:0 Data2:0 Tx:False AckReq:False Ack:False IDreq:False Id:False 3PhReq:False RiscOK:False PlcBusOK:False</td></tr> <tr> <td colspan="1" class="LOGDateTime1" align="left" nowrap="nowrap">20-7-2011 21:09:29 </td><td colspan="3" class="LOGType1" align="left"> PLCBUS Debug </td><td colspan="8" class="LOGEntry1" align="left">Sending: (255) A11 Off Data1:0 Data2:0 Tx:False AckReq:False Ack:False IDreq:False Id:False 3PhReq:False RiscOK:False PlcBusOK:False</td></tr> <tr> <td colspan="1" class="LOGDateTime0" align="left" nowrap="nowrap">20-7-2011 21:09:27 </td><td colspan="3" class="LOGType0" align="left"> PLCBUS Debug </td><td colspan="8" class="LOGEntry0" align="left">Sending: (255) A11 Off Data1:0 Data2:0 Tx:False AckReq:False Ack:False IDreq:False Id:False 3PhReq:False RiscOK:False PlcBusOK:False</td></tr> <tr> <td colspan="1" class="LOGDateTime1" align="left" nowrap="nowrap">20-7-2011 21:09:25 </td><td colspan="3" class="LOGType1" align="left"> PLCBUS Debug </td><td colspan="8" class="LOGEntry1" align="left">Sending: (255) A11 Off Data1:0 Data2:0 Tx:False AckReq:False Ack:False IDreq:False Id:False 3PhReq:False RiscOK:False PlcBusOK:False</td></tr> <tr> <td colspan="1" class="LOGDateTime0" align="left" nowrap="nowrap">20-7-2011 21:09:25 </td><td colspan="3" class="LOGType0" align="left"> Device Control </td><td colspan="8" class="LOGEntry0" align="left">Device: Spare (A11) OFF</td></tr> <tr> <td colspan="1" class="LOGDateTime1" align="left" nowrap="nowrap">20-7-2011 21:09:25 </td><td colspan="3" class="LOGType1" align="left"> PLCBUS Debug </td><td colspan="8" class="LOGEntry1" align="left">SetIO() called HC=A DC=11 COMMAND=3 BRIGHTNESS=0 DATA1=0 DATA2=0</td></tr></tbody></table>

    #2
    It looks like there is a problem with your transceiver.

    When the plugin sends a command to the PLCBUS interface, the interface should send the command back to the plugin, as an acknowledgement.

    From the debug log, it looks like the plugin doesn't receive anything from your PLCBUS interface, and retries the command until a timeout elapses.
    --
    stipus

    Comment


      #3
      Thanks Stipus for your thoughts on a possible cause.

      In the meanwhile I have done some testing.
      Going through the logs I could figure out when this all started, so I thought what has changed since then.
      Well, I received a new kitchen for which a separate circuit breaker was installed.
      There are 8 circuit breakers in the fuse box and if I switch off one of 2 specific circuit breakers all the PLCBUS errors are gone. The other 6 do not have any impact.

      The 2 circuitbreakers are for a microwave oven and for a induction kooking plate. So when I switch off one of these the errors are gone.

      The situation with the new circuit breaker is not entirely different from what it was before my new kitchen. In my old kitchen there was also a microwave oven and a non induction kooking plate. The microwave oven was connected to the same circuit breaker as the rest of the kitchen where in the new situation the microwave oven has its own circuitbreaker.
      The kooking plate always had its own double circuitbreaker and this is still the case.

      The PLCBUS errors occur regardless whether the microwave oven and kooking plate are being used. They have power connected to them but are not in use to prepare food and still produce PLCBUS errors in the logs.


      How can the new situation have an impact on the PLCBUS ACK signal where it is not that much different than before?
      Is there a way to polish the PLCBUS signal so that the ACK signal will be received again?


      Did some more testing.
      Even with a plugin PLCBS module plugged in next to the PLCBUS transceiver module and as far away as possible from the kitchen, the errors still occur. So the equipment in the kitchen must produce a huge disruption on the PLCBUS signal.

      When I use a PLC4023 module and press a button on the PLC4060 remote controll to activate a light there are no retransmits. Activating the same light using the PC transceiver module gives PLCBUS errors.
      Maybe the PC transceiver module always asks for an ACK where the PLC4023 doesn't. Maybe you can shed some light on this matter.

      Comment


        #4
        There are 2 kinds of PLCBUS ACKs:

        1) ACK between the PLCBUS interface and the PLUGIN.

        Each time the plugin sends a command to the PLCBUS interface, the interface sends the command back to the plugin. This is to acknowledge the command has been received by the PLCBUS interface.

        The plugin error message "Too long wait for interface response to command" is when the interface doesn't echo the commands back to the plugin.

        This kind of ACK is mandatory. Commands are always echoed back to the plugin.

        2) ACK between the PLCBUS interface, and PLCBUS modules.

        Each time the PLCBUS interface sends a command to a PLCBUS module, it CAN ask the module to reply with an ACK.

        This kind of ACK is optional. You can select from the plugin web configuration interface if you want ACK requests to be sent to modules.

        ----

        Now the weird thing is that switching ON/OFF one of your circuit breaker has an influence on the first kind of ACKs: communication between the PLCBUS interface and the plugin !

        What's happening is that your PLCBUS interface does not ECHO the commands back to the plugin, and I'm clueless about the reason

        I can understand that an electric device could generate noises on your power network, and prevents commands and/or ACKs from reaching modules but here we are talking about the communication between your host PC and the PLCBUS interface !!!

        The only reason I can see, is that your microwave or cooking plates are generating so much noise (or something else? bad wiring somewhere?) that your PLCBUS interface crashes in some way (maybe it's be very busy trying to decode that noise?), and it doesn't have CPU time to do anything else, like ECHOing commands back to the plugin.

        The day you find the real reason, I would be very interested to know, as it could help other plugin users with the same problem.
        --
        stipus

        Comment


          #5
          Switch off the microwave oven so that I could see the proper sequence.
          I switched module A2 on:



          <table border="0" cellpadding="0" cellspacing="2" width="100%"><tbody><tr> <td colspan="1" class="LOGDateTime0" align="left" nowrap="nowrap">23-7-2011 14:53:03 </td><td colspan="3" class="LOGType0" align="left"> PLCBUS Debug </td><td colspan="8" class="LOGEntry0" align="left">Sent: (255) A2 On Data1:100 Data2:0 Tx:True AckReq:False Ack:False IDreq:False Id:False 3PhReq:False RiscOK:True PlcBusOK:True</td></tr> <tr> <td colspan="1" class="LOGDateTime1" align="left" nowrap="nowrap">23-7-2011 14:53:02 </td><td colspan="3" class="LOGType1" align="left"> PLCBUS Debug </td><td colspan="8" class="LOGEntry1" align="left">Sending: (255) A2 On Data1:0 Data2:0 Tx:False AckReq:False Ack:False IDreq:False Id:False 3PhReq:False RiscOK:False PlcBusOK:False</td></tr> <tr> <td colspan="1" class="LOGDateTime0" align="left" nowrap="nowrap">23-7-2011 14:53:02 </td><td colspan="3" class="LOGType0" align="left"> Device Control </td><td colspan="8" class="LOGEntry0" align="left">Device: 1st floor Livingroom Clock (A2) ON</td></tr> <tr> <td colspan="1" class="LOGDateTime1" align="left" nowrap="nowrap">23-7-2011 14:53:02 </td><td colspan="3" class="LOGType1" align="left"> PLCBUS Debug </td><td colspan="8" class="LOGEntry1" align="left">SetIO() called HC=A DC=2 COMMAND=2 BRIGHTNESS=0 DATA1=0 DATA2=0</td></tr></tbody></table>
          Is the first line that starts with Sent: (255) the ACK from the transceiver back to the Homeseer plugin?

          What does PlcBusOK mean? First line says True, second line says False.

          Comment


            #6
            When I request signal and noise level for module A2, the module returns signal level 31 and noise level 0 with microwave connected to the power lines. Report in use addresses reports and error.

            When I request signal and noise level for module A2, the module returns signal level 24 and noise level 0 with microwave not connected to the power lines. Report in use addresses reports the proper A addresses that are in use.

            So no noise in both cases and a higher signal level when the microwave is connected but then I get PLCBUS errors in the log. I don't get it.

            The same results appear with the induction kooking plate.
            Switching off one of these 2 kooking devices is enough to make all work fine.
            How can a combination of 2 devices give errors where one device doesn't?

            Comment


              #7
              Did some more testing, now with opensource domotica software which supports PLCBUS.

              Initial testing shows no retransmits when both the microwave and induction kooking plate are connected.


              Is there a possibility in the Homeseer plugin to log the raw data going to and coming from the PC transceiver so that we can see if anything is reported back from the transceiver?

              Comment


                #8
                The PLCBUS plugin, when in debug mode, logs everything received from the interface.

                Correct sequence of events should be SENDING first (logged when the plugin is sending a command to the interface), then SENT when the interface reports it actualy sent the PlcBus command.

                The PLCBUS HomeSeer plugin has an internal timeout. If the PLCBUS INTERFACE doesn't reply with a SENT event after a SENDING event, the plucbus plugin retries several times, then you get an error message.

                The domotoca software may not have a timeout like this, and it doesn't try to retransmit if a SENDING event doesn't get a SENT event back from the interface.


                The meaning of other plcbus debug log parameters is the following:

                - 255 is the PlcBus UserCode.

                - A2 is the PlcBus HouseCode/DeviceCode.

                - On is the PlcBus command Name.

                - Data1 and Data2 are command parameters (usualy brightness level and ramp rate)

                - TX is true when this is a command that has been sent by the interface. TX is false when the command has been received by the interface.

                - AckReq= Acknowledgement requested. This is set by the plugin if you ask the PlcBus command to be Acknowledged by the PlcBus device. If the plugin sends a PlcBus command with AckReq= true, the PlcBus device should send the command back with Ack=True. This only works with commands directed to a specific module. This doesn't work with house-code wide commands such as AllUnitsOff or Scene commands that do reach several modules.

                - Ack: Acknowledgement. This is set to True on some received commands. This is usualy when the plugin previously sent a command with AckReq=True. Then the device sends the command back with Ack=True, and the interface should catch this. The plugin would then log a "Received Ack" event.

                - IdReq. This is when the plugin sends a special house-code wide command such as requesting the list of PlcBus addresses on a specific HouseCode, or the list of ON devices on a specific HouseCode. The plugin uses this when you set PlcBus polling on.

                - Id. This is set to True when the received message is a list of PlcBus addresses. This should be received after a PlcBus message with IdReq=True has been sent.

                - 3PhReq. This is set to True if you setup 3-phase mode. Those commands are directed to the 3-phase coupler. The 3-phase-coupler then sends the command to each phase with 3PhReq=False.

                -RiscOK. This is set to True on received commands, if the command is compliant with the RISC protocol. (The RISC protocol is the Home-Automation protocol running on top of the PlcBus protocol).

                - PlcBusOK. This is set to True on received commands, if the command is compliant with the PlcBus protocol. This might be set to False if the interface received garbled bytes from the power line.
                __________________
                --
                stipus

                Comment


                  #9
                  I meant this setting:

                  Config/hspi_plcbus.ini in the settings section:

                  [Settings]
                  DebugReceivedBytes=True


                  Can this shed some light on everything that is received?
                  Is it easy to extend the timeout the plugin waits for and acknowledgement from the transceiver?


                  The opensource software displays the command sent twice in the logs. I have to go through the source to see if this is the command sent and then the acknowledge received.

                  Comment


                    #10
                    Hi Stipus,

                    You wrote: Each time the plugin sends a command to the PLCBUS interface, the interface sends the command back to the plugin.

                    Is this true?
                    I read the PLCBUS protocol document and this says nothing about this kind of ACK. There are some examples in this document and these also do not show this ACK going from the PLCBUS interface back to the PC.

                    The command that the PC sends to the PLCBUS interface has to be send twice to the PLCBUS interface with a time interval between the two times of 12.5ms.
                    There is no reference that the command is sent back to the PC.

                    I looked at the open source domotica software as well and I couldn't find in the source that the command is replied by the interface. I could find the command being sent twice with a delay of 12.5ms between them. This is in line with what I read in the protocol documentation.


                    Where this echo is coming from that the plugin expects as an ACK, I do not know. I remember those good old modems which we all used for years and years. There was an AT command to echo all characters sent to the modem back to the PC. Granted, the PLCBUS interface is not a modem and doesn't know anything about AT commands but it sounds to me like an echo instead of an ACK.


                    Is there a slight possibility that your plugin is not handling the PLCBUS protocol properly for the part where it expects an ACK from the PLCBUS interface?
                    If you are willing to try, could you make a test version of the plugin that doesn't wait on the ACK from the PLCBUS interface and send it to me so that I can try that?
                    I would very much appreciate this. If it works you can try it with some of the other people that seems to have persistent errors that cannot be explained.

                    Comment


                      #11
                      In fact it's not really an ECHO. It's a confirmation the command has been sent.

                      The plugin queues commands, and always wait until a previous command has been sent by the interface before sending the next one.

                      It's very difficult to remove that part from the plugin, as it would break some HomeSeer scripts sending several PLCBUS commands in one shot)
                      --
                      stipus

                      Comment


                        #12
                        Hi Stipus

                        Hmm that is sad news. It means that this issue probably will not be solved.

                        You say it is a confirmation that the command has been sent. This cannot be found in the protocol that it is a confirmation. There is no reference that a confirmation exists. I'm not blaming you, I'm only trying to help but cannot do this alone because you have the source code.

                        The protocol documentation says the transmitting time is 400ms. Instead of waiting for the confirmation it is enough to keep at least 400ms distance between commands. It depends on the command sent if you need more time because of a response from modules so you may have to delay more if a response is expected before you can send the next command.
                        You could end up with overlapping commands if you only wait for a response from the PLCBUS interface that a command has been sent.

                        I am requesting that you create a testversion of your plugin where the confirmation routine is disabled so that I and if you like probably other too, can test if this solves some of the issues out there.
                        I will keep enough space between the commands to be send if the plugin doesn't keep enough distance between commands.
                        Or you could add a delay of at least 400ms, maybe to keep it safe add a delay of 600-800ms, in the routine that empties the command queue. This shouldn't be that hard.

                        As you said yourself: The day you find the real reason, I would be very interested to know, as it could help other plugin users with the same problem.
                        So let's try something to find the real reason. If it doesn't help, we will search further. Work with us to find the reason.
                        If you want I can have a look at the source code of the plugin but again I need your help because you are the one that has the source code. I understand that you are probably not willing to give the source code to someone, but help us finding the real reason things do not work as it should.

                        Comment


                          #13
                          I'm going to have a look... I need to find some spare time.
                          --
                          stipus

                          Comment


                            #14
                            I found a bug that could prevent a second transmission after 12.5ms in some cases.

                            Here is a new version 1.36.2.4 with this bug fixed.
                            I hope this is the cause for your problem.
                            Attached Files
                            --
                            stipus

                            Comment


                              #15
                              I will have go with it this weekend and will report back.

                              Comment

                              Working...
                              X