Error while receiving package

[michapr]

Hi,

I get an error while receiving package from Hoppe Window handle (rorg=0xF6func=10, type=00):

root@raspberrypi:/home/pi# python3.4 /usr/local/bin/enocean_example.py
2017-02-06 19:57:19,529 - enocean.communicators.SerialCommunicator - INFO - SerialCommunicator started
2017-02-06 19:57:19,529 - enocean.protocol.packet - WARNING - Replacing Packet.optional with default value.
2017-02-06 19:57:19,630 - enocean.communicators.SerialCommunicator - INFO - Sending packet
2017-02-06 19:57:19,630 - enocean.communicators.SerialCommunicator - DEBUG - 0x05 ['0x8'] [] OrderedDict()
2017-02-06 19:57:19,732 - enocean.communicators.SerialCommunicator - DEBUG - 0x02 ['0x0', '0xff', '0xb2', '0x78', '0x80'] ['0xa'] OrderedDict()
The Base ID of your module is FF:B2:78:80.
.....

2017-02-06 19:58:05,549 - enocean.communicators.SerialCommunicator - DEBUG - 01:8E:56:0D->FF:FF:FF:FF (-74 dBm): 0x01 ['0xf6', '0xe0', '0x1', '0x8e', '0x56', '0xd', '0x20'] ['0x2', '0xff', '0xff', '0xff', '0xff', '0x4a', '0x0'] OrderedDict()
Traceback (most recent call last):
File "/usr/local/bin/enocean_example.py", line 52, in
for k in packet.parse_eep(0x02, 0x02):
File "/usr/local/lib/python3.4/dist-packages/enocean/protocol/packet.py", line 272, in parse_eep
provides, values = self.eep.get_values(self._profile, self._bit_data, self._bit_status)
File "/usr/local/lib/python3.4/dist-packages/enocean/protocol/eep.py", line 199, in get_values
output.update(self._get_enum(source, bitarray))
File "/usr/local/lib/python3.4/dist-packages/enocean/protocol/eep.py", line 97, in _get_enum
'value': value_desc['description'].format(value=raw_value),
TypeError: 'NoneType' object is not subscriptable
2017-02-06 19:58:05,655 - enocean.communicators.SerialCommunicator - INFO - SerialCommunicator stopped

receiving a package from not defined device (D2-06-01) I get normal debug messages - without errors.

Any idea what can be wrong?

I have used the Zip file and extracted, because installed files were older (and shorter)

Michael

[msinn]

Hi,

I am just starting with enocean on Python. I am getting the same error. I have installed v0.39 (from the master branch)

[zpfvo]

Without having dived into this problem very deep, i have a guess: EEP F6-02-02 defines two enums 'R1' and 'R2' which have 3 Bits reserved for each of them, but only have defines for value 0...3. So if in the bitstream these 3 Bits have a higher value then 3. the program does not know what to do with this.

So this error can always occur when you parse packages with this EEP that are not conform with the EEP. A solution could be to introduce a not specified enum value for the values 4..7. i did this for another Profile here: https://github.com/kipe/enocean/blob/master/enocean/protocol/EEP.xml#L32

on the other hand this actually should not happen, and maybe its better to raise this error because it is clearer that there went something wrong and you probably parsed a package with the wrong eep.

[kipe]

Yeah, what @zpfvo pointed out seems to be the most logical source.

The example codes currently assume that the RPS packages are F6-02-02, and try to parse it as such. We do have the implementation of F6-10-00, so you could try altering the line 56 of enocean_example.py to use 0x10, 0x00 instead.

[msinn]

I think you should alter the implementation to return an empty packet.parsed string in such an error condition instead of killing the program with an exception, only if someone misconfigured his application.

In the meantime I modified my application as a precaution. I modified all calls to packet.parse() and packet.parse_eep() in the following way:

    try:
        packet.parse_eep()
    except:
        pass

to keep the application from aborting. This way I get an empty parsed string, what is perfectly fine for me.

[michapr]

so you could try altering the line 56 of enocean_example.py to use 0x10, 0x00 instead.

Great, it is working ;)

Thanks,
Michael

[kipe]

Great! Unfortunately the devices don't report their profiles in the message, so the code "just needs to be correct". There's an attempt to fix this in another branch, which would save the learned devices and parse the EEP based on that information, but unfortunately I haven't had the time to properly implement it.