VM201 sends wrong relay output status when toggling relay

Hello,

According to the VM201 protocol, the status of the relays will be sent whenever the status of a relay changes. And it does. But! The status that is sent seems to contain the previous state of the relay.

Is the below expected behavior?

Please copy the content below in a text editor. I don’t manage to get it formatted nicely here.

  1. Status request -> Relay 1 is OFF.

14:09:04.715 INFO Request channel 1 status.
14:09:04.716 DEBUG Encoded command: b’R’ and data: b’\x01’ to: b’\x02\x06R\x01\xa5\x03’
14:09:04.739 DEBUG Decoding VM201 packet: b’\x02\x08S\x00\x00\x00\xa3\x03’
14:09:04.739 INFO Output: 0, Timer: 0, Input: 0.
14:09:04.776 DEBUG Decoding VM201 packet: b’\x02\x16N\x01Relay 1\x00\x00\x00\x00\x00\x00\x00\x00\x00K\x03’
14:09:04.801 DEBUG Decoding VM201 packet: b’\x02\x16N\x02Relay 2\x00\x00\x00\x00\x00\x00\x00\x00\x00I\x03’
14:09:04.801 DEBUG Decoding VM201 packet: b’\x02\x16N\x03Relay 3\x00\x00\x00\x00\x00\x00\x00\x00\x00G\x03’
14:09:04.827 DEBUG Decoding VM201 packet: b’\x02\x16N\x04Relay 4\x00\x00\x00\x00\x00\x00\x00\x00\x00E\x03’
14:09:04.827 DEBUG Decoding VM201 packet: b’\x02\x16N\x05Relay 5\x00\x00\x00\x00\x00\x00\x00\x00\x00C\x03’
14:09:04.859 DEBUG Decoding VM201 packet: b’\x02\x16N\x06Relay 6\x00\x00\x00\x00\x00\x00\x00\x00\x00A\x03’
14:09:04.860 DEBUG Decoding VM201 packet: b’\x02\x16N\x07Relay 7\x00\x00\x00\x00\x00\x00\x00\x00\x00?\x03’
14:09:04.886 DEBUG Decoding VM201 packet: b’\x02\x16N\x08Relay 8\x00\x00\x00\x00\x00\x00\x00\x00\x00=\x03’
14:09:04.886 DEBUG Decoding VM201 packet: b’\x02\x16N\tInput\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x81\x03’

  1. Switch channel 1 ON -> Reports that relay 1 is OFF

14:09:05.982 INFO Switching on channel 1.
14:09:05.983 DEBUG Encoded command: b’O’ and data: b’\x01’ to: b’\x02\x06O\x01\xa8\x03’
14:09:05.983 DEBUG Decoding VM201 packet: b’\x02\x08S\x00\x00\x00\xa3\x03’
14:09:05.983 INFO Output: 0, Timer: 0, Input: 0.

  1. Switch channel 1 OFF -> reports that relay 1 is ON

14:09:05.985 INFO Switching off channel 1.
14:09:05.985 DEBUG Encoded command: b’F’ and data: b’\x01’ to: b’\x02\x06F\x01\xb1\x03’
14:09:06.014 DEBUG Decoding VM201 packet: b’\x02\x08S\x01\x00\x00\xa2\x03’
14:09:06.014 INFO Output: 1, Timer: 0, Input: 0.

VM201 firmware version: 1342

Hello @hussein

I discussed your question with the project developer of this VM201.
Our R&D engineer asks whether it is possible to test with the VM201 mobile application.

Check (debug) whether the status is correctly sent as a packet via the app this when you press manually onto the tactile switches of relaycard. If this status is sent correctly via the app, You can use the send values of this packet, for any self-written software.

Best regards,
Velleman Support

Hi and thanks for the response velleman support!

How can I fetch (sniff) the packet that is sent from the VM201 mobile application? (If that is what you are proposing)

I just want to make it clear that the problem is not setting the relay status. When our application (python) sets relay channel 1, we can see that the “light bulb” turns red in the VM201 browser http:///index.html) as expected.

Could you show the development team the following trace and ask them whether it is correct or not. Especially step 2 below.

  1. Client -> Server: b’\x02\x06O\x01\xa8\x03’ (switch on channel 1)
  2. Server -> Client: b’\x02\x08S\x00\x00\x00\xa3\x03’ (status: channel is off ‘0’. Shouldn’t it be ‘1’?)
  3. Client -> Server: b’\x02\x06R\x01\xa5\x03’ (request status)
  4. Server -> Client: b’\x02\x08S\x01\x00\x00\xa2\x03’ (status: channel is on ‘1’)

Hello @hussein
I do not have these devices and I do not know the protocol used.
But in most cases, you have to properly cut, convert and apply a binary mask to decode and correctly interpret this kind of data …
Can you show us the code you are currently using to interpret this data?
Have you the correct binary mask ?
something like https://stackoverflow.com/questions/54702593/how-to-write-a-bit-mask-in-python-for-clean-bits-between-index-j-and-i ?

Hi and thanks for the response @PPAC

I am confident that the binary mask is fetching the correct bits. The code below fetches the status for a specific channel.

The data I provided in the previous reply is raw data and just by looking at it I can confirm that VM201 responds (acknowledges) with the wrong status.

I want velleman to confirm or at least state what the expected behavior is. The documentation is lacking that information. So velleman please have a look at my previous reply.

def _status_response(self):

        """Get the status response for the specific channel.

        

        The status response consists of output-, timer and input status.

        * Relay status | 0x81 ('10000001' = relays 1 and 8 are on)

        * Timer status | 0x13 ('00010011' = timers 1, 2 and 5 are set to 'RUN')

        * Input status 0x01 (=input on) 0x00 (=input off)

        ``return`` a tuple of output-, timer and input status.

        """

        try:

            packet = self.__sock.recv(self.commands['LEN_CMD_STATUS'])

        except timeout:

            raise timeout("No status response received.")

        command, data = self._packet_handler.decode(packet)

        output_status = (data[0] & (1 << self.channel_nr)) >> self.channel_nr

        timer_status = (data[1] & (1 << self.channel_nr)) >> self.channel_nr

        input_status = (data[2] & (1 << self.channel_nr)) >> self.channel_nr

        logging.info("Output: {}, Timer: {}, Input: {}.".format(output_status, timer_status, input_status))

        return  output_status, timer_status, input_status

docs I’ve used:
protocol_vm201.pdf (velleman.eu)
VM201 TCP protocol.pdf (velleman.eu)

1 Like

Greetings! I would just like to mention that this case has been solved.

The issue was that:

  1. I did not fetch the status after authenticating (only the channel names). The status is thus still in the recv buffer
  2. When I requested the status, I fetched the status first (that were still lying in the recv buffer after authentication) and then I fetched the channel names. Which is also the wrong order, it should be first channel names and then status. Thus resulting in status message still laying in the recv buffer.

in short I was reading the old status!

1 Like

Well done !
And thanks for giving the solution for the next one !
Have a nice day !