device discovery about openhab-addons HOT 11 OPEN

Hi, actually I already gave a quick look to your code ;-), but since I am not a python programmer and the class abstracts a lot from the OWN messages, I did not understand so much.....
It would be great if you could guide me in the main principles and OWN messages to be used.
On the other side, I understand your code does not support HMAC auth, which I indeed implemented in Java. I am also using a Node.js OWN server emulator to test my Java implementation, so your nodejs implementation looks interesting to me... it would be great to have a base nodejs module with the protocol primitives, and then one client and one separate server implementation...

from openhab-addons.

ah... sure.
the interesting bits are here :

• https://github.com/sxpert/myhomepy/tree/master/docs
  containing my reverse engineering notes so far
• https://github.com/sxpert/myhomepy/tree/master/myopen/commands
  with readable (I hope) implementation of those things the Bticino myhome_suite is doing.

in any case, you can also look into the OPEN.db sqlite database for more protocol insight (that's where I got some of the info)

as for the HMAC auth, I need another F454 to fsck with ;-)

as an extra note, I am interested with one of those SCSGate things ;-)

from openhab-addons.

Ok thanks. Could you please specify better this issue then? (or sperate it few ones?) Discovery is already supported by the binding but not on all devices and not using the same approach you use. Could you be more specific in what you suggest to improve ?

from openhab-addons.

my code actually requests information from the gateway about which devices are on the bus, and then is able to get the entire configuration for each device out...
my java is too bad to understand how yours work but "BUS/SCS Dimmers must be ON and dimmed (20-100%) at time of discovery, otherwise they will be discovered as simple On/Off switches." sounds like passive listening of some sort
do you need me to write documentation about the process ?

from openhab-addons.

there, I have written the documentation of scanning the system the way MyHomeSuite does it (suppose it's the right way)
https://github.com/sxpert/myhomepy/blob/master/docs/device-programming.md

from openhab-addons.

yes as for now the binding implements "passive listening" to discover devices. This causes some problems with scenarios, users report, plus is not entirely applicable to Thermoregulation (WHO=4). So another approach must be preferred. Thanks for the input, I will look at that and do some testing if it works for WHO=4 to start with.

from openhab-addons.

I followed suit, and implemented the hmac authentication...
(it turns out they're doing wierd things with hex strings, that you have to get exactly right for the sha2 algorithm to apply properly, not what you'd expect from using SHA2 !!

from openhab-addons.

yeah the way they use and document sha2 is very strange

I read your full documentation but I wanted a suggestion: what would you do to discover and distinguish:

1. a normal on/off switch from a dimmer?
2. a temp probe sensor from a thermostat (with temp/modes control) ?

from openhab-addons.

easy... (not)
look into your installation of myHomeSuite, you'll find a file "MHCatalogue.db" which is a sqlite instance
in there you'll find a bunch of tables
EN_DEVICE will give you product_code -> item_id
AS_ITEM_SYSTEM will give you item_id -> modobj
devices have this model_id field.
F411U1 is 79
F411/2 is 129
F411/4 is 130
F418U2 (item_id 2065) is 77
and so on... (be careful though, each system (automation - 1, heating - 4) can have overlapping numbers
each device has multiple slots (say, one per relay) that is set for a particular KO, describing the behavioral caracteristics.
for this, you first need to find the firmwares related to your item_id in EN_FIRMWARE, for instance F418U2 has only one firmware with id_firmware 590
then you look into AS_OBJECT_FIRMWARE which tells you that you can have either id_key_object 8 or 631
finally in EN_KEY_OBJECT, you learn that 8 is key_object 8, Dimmer actuator and 631 is key_object 136, Double dimmer actuator (probably when both outputs are bridged to use as one for more power)
for instance, relays in F411/4 can be either
KO 1 (Takes the 4 slots, because it needs 4 relays): blinds actuator, with 2 motors
KO 6 (1 relay): single light actuator
KO 7 (2 relays): rolling shutter actuator with 1 motor

after that, each ko has a series of parameters that can be set...

you can also look into my device_catalog.db where I tried making this simpler but I am far from having it all...

from openhab-addons.

Update: I am still not able to use your suggested method.
Maybe an example trace of messages during a discovery would help.

Still I can use *#1001*0*7## directly without any other previous "discovery start" command..
It works most of the time, but not correctly with F429 Dali-interface dimmers.
The strange thing is 3 out of the 8 connected dimmers to the same F429 are never discovered, not even using the official OpenWebNet client and sending *#1001*0*7##.
The other 5 dimmers connected to the same F429 are discovered correctly.

Do you have any cloud what could be the problem?
I also posted on the MyHome forum.

from openhab-addons.

ok, lets take it slowly ;-)
open a command ( *99*0## or *99*9# connection
note: below, who is 1001, but could be 1004 for heating, 1018 for energy management or 1023 for access control (no idea what that particular one is)

start with resetting the scanning system
*[who]*12*0##
next, request a scan
*#[who]*0*13##
you'll get a series of *#[who]*[where]*13*[id]## on both the command and the monitor session, terminated with an ack
at this point, send a reset command again.
you will have mac addresses of all automation devices on your bus

your f429 is among those...

you now need to send the diag by ID command
*[who]*10#[id]*0##
this will answer ack ack on the command, and spew all sorts of config values on the monitor session, terminated by *[who]*4*[_junk]##
(just ignore the *[who]*3*0##, they appear to be filler
once that's done, send *#[who]*0*38#0##
this will then reply on the command session a lot of *#[who]*[where]*35#[index]#[slot]*[val_par]## which are the parameters to the slots.
this ends with an ack.
at this point, be sure to return *[who]*6*0## otherwise the device stays in limbo and appears to have lost it's configuration. you also should attempt to do this in case some error occurs

see https://github.com/sxpert/myhomepy/blob/master/myopen/subsystems/diag_scannable.py
for more information.

traces and stuff are available in this folder:
https://github.com/sxpert/myhomepy/tree/master/docs

hope this helps !

from openhab-addons.