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.
Posts made by PhracturedBlue
RE: A mesh network for use with ESP8266 and MQTT
RE: USNAP (ANSI/CEA-2045) Smart-Grid interface
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.
USNAP (ANSI/CEA-2045) Smart-Grid interface
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:
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:
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?
RE: A mesh network for use with ESP8266 and MQTT
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.
RE: A mesh network for use with ESP8266 and MQTT
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.
A mesh network for use with ESP8266 and MQTT
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:
FYI, I didn't check the work done by tekka, but I didn't file a pull request for my 'sleep' code. I have support for using low power mode (reduce current from ~40mA to 4mA during sleep) but I had issues with reliable wakeup, so I've just switched my code to all using delay loops.
Initially I was using these boards for my sensors, but there is very little benefit compared to a 3.,3V pro-mini for my usage cases, and the power is 10x more when running (and 100x more when idle without my sleep patches that don't work)
I don't have any sensors that need the extra horsepower of the STM32 personally. The one benefit I did realize is having a USB serial port which removes the need for USB->TTL.
RE: Mains energy meter node
I had seen the sonoff stuff, but not the sonoffpow before. I had dismissed them due to not having wifi where I want them, but it's probably cheaper and easier to install esp8266 repeaters than to try to manufacture my own boards. Thanks for pointing these out.
RE: Mains energy meter node
Sorry, I thought by 'mains' you meant the entrance to the home. You're really talking about something similar to a sensor-connected kill-a-watt. I've been planning to build something like this (specifically incorporating a current sensor into a sensor controlled AC/switch). Something similar to this:
Though that above link can only handle a few amps...not enough for my needs. (It also includes some other logic for detecting an external switch, so I'm using it more for reference than advocating this precise solution).
Edit: If you do find something that will work for you, please keep us posted.
RE: 💬 RFM69 Relay Actuator Node (mains powered)
Is there a reason you chose to use the AMS1117 vs directly using an HLK-PM03? Are you worried about P/S ripple?
Also, did you consider using a thermal fuse? As far as I know the HLK-PM01 does not have any thermal protection
Nice board. I'll be awaiting your results.
RE: Recommended setup for MQTT and RFM69
Thanks for the input.
The node.js solution doesn't seem any different than what I already have in python. If mysensors officially supported one of these options it would seem preferable to relying on a forum post somewhere. My concerns would mostly be about long-term support as the Mysensors API may change again in the future. As noted, it seems that the previous incarnation (PerlMQTTGateway) has basically been deprecated. Having already written a serial<->MQTT bridge, there wasn't much to it, so maybe there isn't really much risk for forward compatibility though.
It seems the ESP8266 option might be a reasonable recommendation, though I personally wanted a hardwired connection to the gateway since wireless signal is not too strong where I'd like to put the gateway.It doesn't appear that there is a serial gw<->ethernet bridge option either. So as far as I can tell, the code distributed with mysensors seems to assume to gateway is directly connected to the radio (with the exception of the 'serial' gateway running on RPi)?
I guess most users who decide to use RFM69 just use the serial interface?
Recommended setup for MQTT and RFM69
What is the recommended setup to use an RFM69 Module with MQTT Gateway?
I am using an Arduino serial gateway configured for RFM69 hooked directly to the UART of an RPi.
I would like to use MQTT to communicate with my controller (this makes it easy to send messages to the sensors via multiple sources, which is convenient for me)
I first did this by modifying the RPi gateway code to speak to the RFM69 and directly wiring the RFM69 module to the RPi. This worked, but I was missing messages, and I wasn't sure if possibly the RPi wasn't servicing the SPI quickly enough.
So I switched to a serial gateway, and I've had much better reliability of receiving messages (I also changed some other things at the same time, so I'm not going to claim this was actually necessary), but now I have a serial interface to the gateway, and I need a MQTT to Serial converter. the only thing I found was this:
But it seems to be abandoned. In the end, I wrote a simple python utility using paho-mqtt which does the same thing as the above script, and works well, so I don't actually have any problem at the moment, but I'm wondering what the preferred way to use an RFM69 with MQTT is given that Mysensors2.1 doesn't yet officially support the RPi gateway with this module (I realize it will be likely be available in 2.2...as I said, I already implemented it myself).
I have looked at the documentation on gateways as well as the RPi documentation, but I didn't find a clear answer to this.
Booting sensors without Gateway connection?
I am designing sensors that do data-logging in addition to sending that data back to a gateway via mqtt. Today, the sensor does not begin to execute until it has established communication with the gateway. This may make sense if the sensors only purpose is transmitting data, but in my case, I want to ensure that the data-logging activates as soon as the sensor powers on, even if a gateway isn't found.
Is it possible to defer configuration to the main loop such that my sensors can collect data while trying to establish communication with the gateway?
I am using RFM69W sensors if it is relevant. From what I can tell, the sensors seem to get stuck in an ACK loop waiting for gateway response, but I am not 100% sure whether this happens for all radios or not.
RE: 💬 Building a Raspberry Pi Gateway
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:
Note that it currently requires using some pin other than CS0/CS1 for the chip-select