PhracturedBlue

PhracturedBlue

I have created a patch to enable the use of the RFM69 with a RaspberryPi gateway without the use of an Arduino gateway board.

It has only been tested with my configuration, but it seems to work well for me.

Pull request is here with configuration instructions:
https://github.com/mysensors/MySensors/pull/728

Note that it currently requires using some pin other than CS0/CS1 for the chip-select

PhracturedBlue

I'm sorry if this doesn't belong here as it is not strictly mysensors related...

While I have a bunch of RFM69 mysensors around my house, I decided t buy some Sonoff POW relays (with the intention to run Espurna on them) as their price is very good and they had the capabilities I needed. I was disappointed by the range compared to my RFM69 sensors though, and didn't have strong enough wireless to get them everywhere I needed them.

I decided to try to build a mesh network which could extend the range by allowing nodes to forward data through each other. I found a few toy projects, but nothing that seems like it would meet my needs, so I wrote my own. What resulted was my ESP8266MeshNetwork.

It is built around MQTT messaging. Nodes use a simple TCP protocol between themselves, but can also act as a gateway to publish/subscribe to messages from the MQTT broker on the wireless network. subscribed messages are forwarded to all nodes, whereas published messages are forward upstream until they reach the MQTT broker.

Each node creates a hidden access point (this is just to reduce the number of networks that appear visible, not for security). Each node has a list of known nodes (identified by MAC) and will connect to the best available node or the primary wireless network if possible. The MQTT broker maintains the list of all nodes on the network via persistent messages, so it is necessary for a node to connect directly to the wireless network at least once to know about existing nodes. After that, a node will automatically connect to the best node in the mesh, and will keep its list of nodes up to date by receiving MQTT notifications.

The nodes can each run their own firmware, as long as they all use the ESP8266MeshNetwork library for communication). OTA updates are supported via MQTT, and can be targeted to a specific node, or to all nodes running a given firmware.

I've only had it in operation for a couple of weeks, but it seems to be working well for me so far.

I'd like to use the mysensors library for the Sonoff POW, but it really wants to fully manage the connection, which won't work well for me. Perhaps I could implement the mesh as a Transport, but I don't think there is much likelyhood of my having such a patch accepted.

Anyhow, here is a link to the github repo:
https://github.com/PhracturedBlue/ESP8266MQTTMesh

PhracturedBlue

Yes, the github project above includes a 'sensor' example that runs fine on the POW (I actually use modified POWs that have DS18B20 temp sensors, but the code works with and without that). Note that we found that we require the 'staging' branch of the ESP8266 core, since WIFI_AP_STA mode isn't very reliable in the stable version (though for some reason, the stable release works really well if your WiFi is all on channel '1'). I also moved the project to platformio as it makes installing the dependencies easier.

PhracturedBlue

I think I got confused somewhere along the way. I do not think the protocol is actually MODBUS as Modbus does not appear to use a start-of frame bit and specifies a CRC rather than a simple checksum.

The water heater is a Reliance DHPST hybrid water heater (electric + Heat Pump)
Data on RS485 is transmitted at 19200 baud
Data is 1 startbit, 8 data bits, 1 'start of frame' bit, and 1 stop bit/
The 'start of frame' bit is 1 for the 1st byte, and 0 for all remaining bytes.
The last byte is a single 1-byte sum of all previous bytes of the frame.
This represents most of the packets I have seen (I have removed the 'start of packet' bit:

(3)  : 90 00 90
(64)  : 40 08 1e 00 00 00 03 00 78 00 00 00 00 00 00 71 44 74 6a 49 47 30 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 69 cd 00 00 00 00 16 02 00 00 00 09 00 00 00 00 00 00 41 08 00 00 50 00 26
(30)  : 40 0b 0d 02 00 62 00 5a 00 5e 00 52 00 00 00 ff ff 00 00 00 00 00 00 00 00 00 01 00 02 c7
(3)  : 8c 00 8c
(3)  : 82 00 82
(8)  : 40 00 02 05 00 b2 00 f9
(28)  : 40 0d 0c 00 01 00 3c 00 00 00 10 00 78 00 78 01 01 00 00 00 00 00 01 00 00 00 00 99

For anyone interested, the easiest way to read this in linux is to set the
INPCK and PARMRK, and then read with 'SPACE' parity. this will generate an error whenever the parity bit is set, that can then be converted into a 'start of frame' bit.
Here is some example python code:

import serial
import termios
i
ser = serial.Serial(port, 19200, parity=serial.PARITY_SPACE)
iflag, oflag, cflag, lflag, ispeed, ospeed, cc = termios.tcgetattr(ser)
iflag |= termios.INPCK | termios.PARMRK
termios.tcsetattr(ser, termios.TCSANOW, [iflag, oflag, cflag, lflag, ispeed, ospeed, cc])

buf = []
while True:
    try:
        b = ord(ser.read(1))
        if b == 0xff :
            b = ord(ser.read(1))
            if b == 0x00:
                b = 0x100 | ord(ser.read())
        buf.append(b)
    except SerialException as e:
        print(e)

I'll follow-up with the bytes I've figured out so far.

PhracturedBlue

I have a hybrid hot water heater with what appears to be an AC CEA-2045 interface (which I assume is a USNAP interface). It looks like this:

https://usnap.memberclicks.net/assets/images/Connectors/ac_connector.png

It appears to have A120V AC on one side, and RS-485 on the other.

I snooped the RS485 @ 19200BPS And I can see data transmission. I haven't spent too much time analyzing it yet, but I believe I can see the target temperature, current temperature, and state info in the data stream. I don't expect it to be too hard to extract the relevant info and build a sensor to monitor the port. However, The heater has a 'power save' mode which apparently lets the Smart-grid control the water-heater (I assume switch it from efficiency to all-electric mode?). That sounds like something I want to play with. I'd love to be able to use some home-automation technology to control when the heater is in all-electric mode, and when it is in hybrid, efficiency or vacation mode.

But I don't know the protocol to change the state.

I found this document that indicates how to build a receiver, and that it is likely using a MODBUS protocol:
http://sunspec.org/wp-content/uploads/2015/07/SunSpec-CEA-2045-Inverter-Adaptor-Architecture.pdf

This seems to correlate to what I've seen as well (The data is 9N1, with the 1st bit indicating the start of a frame wth a checksum at the end...Figuring out how to read this with a UART was a little fun)

But I still don't know what (most of) the data in the packet means, and more importantly how to send data back to the heater.

Has anyone done any work with USNAP / CEA-2045?

PhracturedBlue

@gohan
I'm not sure I was asking a question. Just stating my solution in case anyone else ever encounters something similar since my searching didn't uncover anything.

Unless you are specifically talking about trying to use mysensors solely as a messaging API. I don't know that there is much point in discussing it since mysensors is designed as a complete system (which I really appreciate since I'm very satisfied using it with my RFM69 sensors). I guess I could emulate the mysensors gateway protocol via my MQTT setup (or as I mentioned try to write a Transport that could interface to my mesh library), but in the end, I'm feeding Home-Assistant, and it is configurable enough not to matter.

PhracturedBlue

I agree that mysensors isn't designed to be run over IP, but it has a well formed API for a variety of sensors. It would be ideal (for me) if the messaging API was independent of the backbone. I did actually start with Wifi repeaters, but they were expensive and I needed several. Then I thought I could make one using ESP8266 modules cheaply, then I figured I might as well go with something that was tailored to my needs...and then I got where I am now. I hadn't thought about X10 or a powerline AP...Not sure they would have worked for me due to my setup, but maybe I should have considered it. Oh well...in any case, I now have a useful mesh library I can play around with I guess.

PhracturedBlue