raintonr / hormann-hcp Goto Github PK

Hi,

as you sucessfully communicated with the motor (#1) would you give a bit more information on your setup?
Also, do you plan on building some kind of ESP32 device that interfaces with the Hormann drives?

The master does perform bus scan, and after replying to this, would have thought it would then move on to issue status requests for slaves that responded to it's scan. But this doesn't happen.

According to Bouni's protocol findings it should be possible to have the status of a door signalled. This is in fact the main reason I am so interrested in this project. Open/close the door can be done with I/O of a ESP easily but not receiving the actual status.

So can you pls. add a output to see the actual status of the door (open/closed) and maybe other infos (lightning,..) too?

I strugle a bit to understand how to use the tool.

When I start it with nodejs hormann-hcp.js, I get some output:

Setting up port...
Initiating parser...
Opening port...

When I then press a number key (1 up to 8) I can set the according bit for the response to the master (the drive) which is stored in ourStatus

Sending command 4
OurStatus: 1000
Sending command 2
OurStatus: 1010
Sending command 2
OurStatus: 1000

Is it even possible to send an answer with multiple bits set at a time?
Your comment in the code says:

// Command mask for LineaMatic P:
// +------- (0x80) Unknown
//  +------ (0x40) Unknown
//   +----- (0x20) Unknown
//    +---- (0x10) Moves to 'H' (whatever that means)
//     +--- (0x08) Unknown
//      +-- (0x04) Impulse toggle
//       +- (0x02) Impulse close
//        + (0x01) Impulse open

So I guess replying with Impulse close and impulse open at the same time does not work, right?
Wouldn't it make more sense to clear ourStatus before setting the bit tha is requested by key press?

@raintonr Do you have access to a logic analyzer or an oscilloscope?
I'm really interested how the signal looks when you send something using your baud rate switching trick!
If you coud provide a trace / picture that would be awesome!

As discussed #3 (comment) BRK can be detected but is inelegant to say the least. Find a better way.

Do you think we can describe the protocoll in either the README.md or a sepearte .md file to an extend that allows to easily understand the protocoll?

Ideally with timing graphics and detailed explanations of the pitfalls like the sync break and how to overcome them.

I'll help you with that obviously!