Query about zbhub about pyalertme

[jamesleesaunders]

@jrjefferies Another good spot!

I am glad you have managed to untangle my possibly confusing web of function names and inheritance. This I feel could possibly do with a little untangling once understood. The idea was that all ‘zb’ classes inherited from zbnode could be written in such a way that they perform different functions on receiving a message (I.e the hub creates a list of known end devices, whereas the SmartPlug simply records its hub address).

I haven’t got my kit up and running at the moment but from what you describe it looks like we are potentially sending discovery messages ( from device_obj_from_addr) before the expected replies therefore possibly confusing the end device? Or worse causing a cycle of repeating messages.

Like you say we have a couple of options...

1. zbnode.py Swap the ‘Update any attributes’ and ‘Send any replies’ over to become:

def receive_message(self, message):
        """
        Receive message from XBee.
        Parse incoming message.
        Process parsed result.

        :param message: Dict of message
        :return:
        """
        ret = self.parse_message(message)

        if message['id'] == 'rx_explicit':
            source_addr_long = message['source_addr_long']
            source_addr_short = message['source_addr']

            # Send any replies which may need sending           <-- swapped over with 
            for reply in ret['replies']:
                message_id = reply['message_id']
                if 'params' in reply.keys():
                    params = reply['params']
                else:
                    params = {}
                reply = self.generate_message(message_id, params)
                self.send_message(reply, source_addr_long, source_addr_short)
                time.sleep(0.5)

            # Update any attributes which may need updating       <-- swapped over
            self.process_message(source_addr_long, source_addr_short, ret['attributes'])

Or

2. zbhub.py Remove the send_message code from device_obj_from_addr() but we loose the sending of type discovery messages.

Remove:??
            # if not device_obj.type:
                # The device has to receive these two messages to stay joined.
                # message = self.generate_message('mode_change_request', {'mode': 'normal'})
                # self.send_message(message, device_addr_long, device_addr_short)
                # message = self.generate_message('version_info_request')
                # self.send_message(message, device_addr_long, device_addr_short)

To be honest I’d be interested in your view and your testing, but both sound plausible. The advantage of solution 1 is that it maintains the rudimentary force discovery of new unknown device types. I will attempt to get my kit setup again, but in the mean time, if you do come to a solution please feel free to pop it in a PR and I'll happily merge it in @andydvsn may also be interested.

All the best,

Jim

[jrjefferies]

Jim,
I tried option 1 - moving the process_message. It looks better, the plug seemed to join, then went back to range finding mode. I intend try and identify what message the zbhub sent to cause it to step back. If I find a problem, we may be good.

If not, I am thinking about putting a statemachine in the zbhub process_packets. It will work something like this

• new node_obj joining_status variable that will migrate through unknown -> zdo_stage1 -> zdo_stage2 -> Alertme_stage1 -> Alertme_stage2 -> fully_joined
• pass message queue into the process_message, so we can add the messages we want
• process_message will have if statements to add in additional message on the end of the message queue.
  E.g. when we get Match_Descriptor_request the zbnode will add Match_descriptor_response, and then we add Active_Endpoint_Request to trigger the switch to move to the next state
• we could also reorder the packets in the message queue if needed.

[NOTE - stages to be worked out - I am still trying to get my head around all the steps needed for proper joining of the hub]

This would keep the zbnode parse_message for generic message responses and move the specific coordinator responses in the zbhub process_message

Tell me what you think.
Cheers James

PS - I will commit the changes I made on this issue - even though its not completely fixed the issue.
This includes to formatting changes to the zbnode static variables, correction on the short broadcast variable, and some documentation