Evotouch/Evohome support in culfw

Begonnen von colintd, 06 Februar 2017, 10:39:36

Vorheriges Thema - Nächstes Thema

colintd

Back in 2013 I hacked a boiler relay to act as an EvoHome sniffer, and reported the details in this thread https://www.domoticaforum.eu/viewtopic.php?f=7&t=5806&p=62892#p62892

However, I wanted to get a system working with a CC110x board, ideally as part of culfw.

After much delay, I have written a culfw module which allows sending and receiving EvoHome messages.  The code includes message delimiting on the CUL (so low interrupt rate on the host) and checksum generation/validation (so you only receive valid messages, and when sending the board will automatically add the checksum).

At present I'm just using it as part of my EvoHome protocol sniffer, but wonder if anyone would be interested in:

a) testing on a broader range of hardware (currently I've got it running on a tweaked COC v1, and a stock CUL V3),
b) helping integrate as an access device for fhem (I've looked at the source, but haven't yet had time to get a build/test system setup)?

As of yesterday (and with the kind help of Rudolf) it is merged into a culfw trunk which can be retrieved via svn.  Currently (for space reasons, and due to limited hardware for testing) it only builds into the CUL_V3_ZWAVE firmware.

The syntax of the new culfw command for EvoHome is currently as follows:

Zitat
v[<func>][<hex>] Honeywell EvoHome/EvoTouch mode.

<func> is one of:
◾ l
Listen for EvoHome messages.
Only EvoHome messages with a valid checksum will be returned in this mode.
Messages are reported on receipt as vr<hex> with the valid checksum byte removed.
◾ d
Listen for EvoHome messages as above, but also report aborted receives as v!<code>[<hex>].
This extra information can be useful for debug purpose.
Codes include:

      Interference related
      ◾ F - Framing error, where received data doesn't decode to 1start-8data-1stop at 38,400bps
      ◾ M - Manchester coding error in received data
      ◾ C - Checksum error over completed message

       Firmware problem
      ◾ L - Message exceed expected maximum length
      ◾ O - Overrun, where a second data byte arrived before the ISR processing the first was able to complete

◾ s<hex>
Send out an EvoHome message. No checking is performed on sent data, but a valid checksum is automatically added.

◾ If no <func> is specified, EvoHome reception is disabled.

Responses
◾va - Successful acknowledgement to request
◾vb - Attempt to send whilst device busy receiving a message (small timing window, just retry)
◾v? - Unknown command



And an example of listening output is:


vr18112BD9112BD910600300FF01
vr1812BF85049C153150020B4C
vr181199CB049C1510600303FF01
vr181199CB1199CB10600300FF01
vr1836D07F36D07F3EF00300C8FF
vr0C7857BF049C1523490101
vr3C049C157857BF2349070105DC00FFFFFF
vr181249B71249B730C903000637
vr1812890712890730C903000662
vr1812890012890030C903000686
vr0C7857BF049C1523490102
vr3C049C157857BF23490702060E00FFFFFF
vr18112BD5112BD530C9030005F2
vr18128900049C1510600303FF01
vr1812890012890010600300FF01
vr181382C3049C152309030A0578
vr0C7857BF049C1523490103
vr3C049C157857BF23490703064000FFFFFF
vr181199D3049C15230903030640
vr0C7857BF049C1523490104
vr3C049C157857BF23490704064000FFFFFF
vr18112BD9049C1510600303FF01
vr18112BD9112BD910600300FF01
vr18128910049C15230903060578
vr0C7857BF049C1523490105
vr3C049C157857BF23490705057800FFFFFF
vr18112BED049C151060030BFF01
vr18112BED112BED10600300FF01



H3nr1

#1
Great work. I flashed my nanocul with the latest r562 firmware. If the firmware is ready for the nanocul i can test it for you.
Thanks