NodeMCU ESP8266 RS485 EPEver Solar monitor DIY

[paulca]

Situation:
I have a solar charge controller which has a comms port running RS485.  I want to log data from it.

Options:
* I can connect it to the PC and view stuff with it's GUI program. 
* I could also use Python ModBus to write my own software to query it and log it.
* I could use a raspberry PI, USB power supply and create a data logger.
Meh.  Expensive, GUIs, power supplies etc. etc.

Opportunities:
I have a few NodeMCU boards and I have an already functioning generic network data logger on my network.  Can I make it wireless?

Inspiration:


While the video author does, kinda, what I want to, I'm not at all comfortable taking his work verbatim.  It's a bit "How you doing".  I'll invent my own wheel.  So I will go through the process myself and work out my solution.  I'll take some of the inspiration for the basic building blocks from the video and work from there.

First high level design idea:
EPever SCC <-[RS485]-> MAX485 <-[RS232]->NodeMCU<-[UDP over WiFi]->Network logger

Power:
The EPEver will supply about 50mA of 5V on the RS485 port.  Just enough to run the NodeMCU which will accept 5V on VIn. 

Signal voltage:
Here I hit a challenge.  The NodeMCU is 3.3V logic, the MAX485 and RS485 are 5V.  So I may need to insert a level shifter.

Revision 1:
EPever SCC <-[RS485]-> MAX485 <-[RS232]->Bi Directional Level Shifter<-[RS232]-> NodeMCU<-[UDP over WiFi]->Network logger

There are reports that people having been banging 5V signals into the NodeMCU for months in service reliably, but the documentation available states 3.3V logic level.  It's a YMMV thing.

Efficiency:
The NodeMCU will run from the solar battery.  I don't want it running 24/7 at full power. I can put the ESP8266 MCU to deep sleep between rough hours of dusk to dawn and stop logging data.  Either just a lookup table of sun/rise set times (I have tons of memory) or sensed and/or calculated times.  I will not be fetching data off the web (or uploading for that matter) with a REST request, 'thingspeak' 'cayenne' or any of that other millennial cloud non-sense.  I do not want to couple my functioning device to some crummy website and it's HTML formatting or REST API, which might be switched off or change tomorrow. </rant>

Integration:
The NodeMCU will send UDP packets containing the current data to an existing receiving hub/server. UDP because there is exactly zero the data sender can do if the data is received or not.  The frequency of my data logger system is one sample on all data sources per minute.  However the hub will accept and make available data at whatever rate you want to send it, within reason.  I normally send every 5 seconds.  This gives near realtime data for displays.  This data is sampled once a minute and logged 24/7.  Senders send as many values as they want, there are many senders, hub gobbles it all up and logs it.

Packaging:
Can I get it all to fit into a 150x35x25mm enclosure with a usable USB port hole and Ethernet cable plug on a rat tail.  Will it being in a case break the WiFi reception? 

Phase One:  Does the idea work?

This week end I will attack things in this order:
1. Test the MAX485 board through an Arduino to the solar charge controller.  This should be online example rich territory and I don't need the level shifter or WiFi, networking or other shenanigans.
2.  Test the level shifter (never used one) in it's new circuit, maybe a Arduino to NodeMCU serial test.
3.  Test the MAX485-level shifter-NodeMCU together
4.  Test with WiFi data sending.
5.  Test the NodeMCU Wifi functionality/range/signal strength from within an enclosure.

I'll try and take photos and measurements.

Phase Two: Software refinement
TBD
Phase Three: Hardware refinement
TBD
Phase Four:  Enclosing, tidying, finishing off.
TBD

Out of interest, I can make the data logger software open on gitlab, it's still very 'how you doing', but you are welcome to it.  There are I'm sure solutions available that are much better than mine.  Mine is simple.  As complicated as it needs to be to function and no more.  You will have to write your own sensor sender code, but I have examples.

[paulca]

So after a little frustration I managed to get the Arduino to read and display the basic solar stats.

I'm getting miss reads, most likely as I have no GND connection with the charge controller.

As you can see it's a fairly dark gloomy morning.  A whole 30mA.

The power readings don't seem right, I have to look into those.

Code: [Select]

Moooooo!
VPanel: 13.43
IPanel: 0.02
PPanel: 0.00
VBatt: 12.45
Ibatt: 0.03
PBatt: 0.00


Miss read, ret val:227
VPanel: 13.40
IPanel: 0.02
PPanel: 0.00
VBatt: 12.45
Ibatt: 0.03
PBatt: 0.00


Miss read, ret val:227
Miss read, ret val:227
VPanel: 13.36
IPanel: 0.02
PPanel: 0.00
VBatt: 12.45
Ibatt: 0.03
PBatt: 0.00


Arduino Code:

Code: [Select]

#include <ModbusMaster.h>


#define MAX485_DE       2
#define MAX485_RE   3

#define PANEL_VOLTS     0x00
#define PANEL_AMPS      0x01
#define PANEL_POWER_L   0x02
#define PANEL_POWER_H   0x03
#define BATT_VOLTS      0x04
#define BATT_AMPS       0x05
#define BATT_POWER_L    0x06
#define BATT_POWER_H    0x07

// instantiate ModbusMaster object
ModbusMaster node;

#include <SoftwareSerial.h>

SoftwareSerial mySerial(10, 11); // RX, TX

void setup()
{
  Serial.begin(57600);
  while (!Serial) {
    ;
  }
  Serial.println("Moooooo!");

  pinMode(MAX485_RE, OUTPUT);
  pinMode(MAX485_DE, OUTPUT);
  // Init in receive mode
  digitalWrite(MAX485_RE, 0);
  digitalWrite(MAX485_DE, 0);

  // Modbus at 115200 baud
  mySerial.begin(115200);

  // EPEver Device ID 1
  node.begin(1, mySerial);

  // Callbacks
  node.preTransmission(preTransmission);
  node.postTransmission(postTransmission);
}

void loop()
{
  uint8_t result;

  // Read 8 registers starting at 0x3100)
  node.clearResponseBuffer();
  result = node.readInputRegisters(0x3100, 8);

  if (result == node.ku8MBSuccess)
  {
    Serial.print("VPanel: ");
    Serial.println(node.getResponseBuffer(PANEL_VOLTS)/100.0f);
    Serial.print("IPanel: ");
    Serial.println(node.getResponseBuffer(PANEL_AMPS)/100.0f);
    Serial.print("PPanel: ");
    Serial.println((node.getResponseBuffer(PANEL_POWER_L) +
                    node.getResponseBuffer(PANEL_POWER_H) << 16)/100.0f);
   
    Serial.print("VBatt: ");
    Serial.println(node.getResponseBuffer(BATT_VOLTS)/100.0f);
    Serial.print("Ibatt: ");
    Serial.println(node.getResponseBuffer(BATT_AMPS)/100.0f);
    Serial.print("PBatt: ");
    Serial.println((node.getResponseBuffer(BATT_POWER_L) +
                    node.getResponseBuffer(BATT_POWER_H) << 16)/100.0f);                   
    Serial.println();
    Serial.println();
  } else {
    Serial.print("Miss read, ret val:");
    Serial.println(result);
  }

  delay(2000);
}

void preTransmission()
{
  digitalWrite(MAX485_RE, 1);
  digitalWrite(MAX485_DE, 1);
}

void postTransmission()
{
  digitalWrite(MAX485_RE, 0);
  digitalWrite(MAX485_DE, 0);
}
Borrowed/Stolen/Adapted from:
https://www.arduino.cc/en/Tutorial/SoftwareSerialExample
https://www.reddit.com/r/esp8266/comments/59dt00/using_esp8266_to_connect_rs485_modbus_protocol/


Doh!  Never trust people's tutorials or code:

Code: [Select]

   Serial.println((node.getResponseBuffer(BATT_POWER_L) +
                    node.getResponseBuffer(BATT_POWER_H) << 16)/100.0f);

Should probably be:

Code: [Select]

    Serial.println((node.getResponseBuffer(BATT_POWER_L) |
                    node.getResponseBuffer(BATT_POWER_H) << 8)/100.0f);
Which give a more convincing reading.



Excuse the mess:

[paulca]

So I skipped testing the level shifter and watched a you tube video to prime myself.  Went straight to the ESP8266.

It works.

Code: [Select]

paul@localhost ~ $ nc -ul -p 9999
pV:13.84:V,pI:0.33:A,pP:4.56:W,bV:12.69:V,,bI:0.36:A,bP:4.56:W,lV:0.00:V,,lI:0.00:A,lP:0.00:W

My original Arduino sketch did not like the ESP8266.  I think there are bugs with the SoftwareSerial library and the ESP8266.

So I had to go for hardware serial.

I have not figured out how to use the HW serial for both the RS485 and debug over USB.  However, bizarrely it works.  Although I have garbage on the Serial console.
 It's not a big deal, I intend to delete all the serial debug and provide an HTTP port which will dump diagnostics and daily stats from the controller.

Code: [Select]

1?:VPanel: 13.89
IPanel: 0.32
PPanel: 4.58

VBatt: 12.73
IBatt: 0.36
PBatt: 4.58

VLoad: 0.00
ILoad: 0.00
PLoad: 0.00

New ESP8266 Code:

Code: [Select]

#include <ModbusMaster.h>
#include <ESP8266WiFi.h>
#include <WiFiUdp.h>

#define MAX485_DE       D2
#define MAX485_RE       D1

#define PANEL_VOLTS     0x00
#define PANEL_AMPS      0x01
#define PANEL_POWER_L   0x02
#define PANEL_POWER_H   0x03
#define BATT_VOLTS      0x04
#define BATT_AMPS       0x05
#define BATT_POWER_L    0x06
#define BATT_POWER_H    0x07
#define LOAD_VOLTS      0x0C
#define LOAD_AMPS       0x0D
#define LOAD_POWER_L    0x0E
#define LOAD_POWER_H    0x0F

#define HB D4

// instantiate ModbusMaster object
ModbusMaster node;
const char* ssid = "cmmwlan";
const char* password = "*********";

void setup()
{
  WiFi.begin(ssid, password);
 
  Serial.begin(115200);
  while (!Serial) {
    ;
  }
  Serial.println("Moooooo!");

  pinMode(MAX485_RE, OUTPUT);
  pinMode(MAX485_DE, OUTPUT);
  // Init in receive mode
  digitalWrite(MAX485_RE, 0);
  digitalWrite(MAX485_DE, 0);

  // Modbus at 115200 baud
  //mySerial.begin(115200);

  // EPEver Device ID 1
  node.begin(1, Serial);

  // Callbacks
  node.preTransmission(preTransmission);
  node.postTransmission(postTransmission);

   pinMode(HB, OUTPUT);     // Initialize the LED_BUILTIN pin as an output
}

void loop()
{
  uint8_t result;

  // Read 16 registers starting at 0x3100)
  node.clearResponseBuffer();
  result = node.readInputRegisters(0x3100, 16);

  if (result == node.ku8MBSuccess)
  {
    float pV = node.getResponseBuffer(PANEL_VOLTS)/100.0f;
    float pI = node.getResponseBuffer(PANEL_AMPS)/100.0f;
    float pP = (node.getResponseBuffer(PANEL_POWER_L) |
                    (node.getResponseBuffer(PANEL_POWER_H) << 8))/100.0f;

    float bV = node.getResponseBuffer(BATT_VOLTS)/100.0f;
    float bI = node.getResponseBuffer(BATT_AMPS)/100.0f;
    float bP = (node.getResponseBuffer(BATT_POWER_L) |
                    (node.getResponseBuffer(BATT_POWER_H) << 8))/100.0f;

    float lV = node.getResponseBuffer(LOAD_VOLTS)/100.0f;
    float lI = node.getResponseBuffer(LOAD_AMPS)/100.0f;
    float lP = (node.getResponseBuffer(LOAD_POWER_L) |
                    (node.getResponseBuffer(LOAD_POWER_H) << 8))/100.0f;
                   
    Serial.print("VPanel: ");
    Serial.println(node.getResponseBuffer(PANEL_VOLTS)/100.0f);
    Serial.print("IPanel: ");
    Serial.println(node.getResponseBuffer(PANEL_AMPS)/100.0f);
    Serial.print("PPanel: ");
    Serial.println((node.getResponseBuffer(PANEL_POWER_L) |
                    (node.getResponseBuffer(PANEL_POWER_H) << 8))/100.0f);
    Serial.println();

    Serial.print("VBatt: ");
    Serial.println(node.getResponseBuffer(BATT_VOLTS)/100.0f);
    Serial.print("IBatt: ");
    Serial.println(node.getResponseBuffer(BATT_AMPS)/100.0f);
    Serial.print("PBatt: ");
    Serial.println((node.getResponseBuffer(BATT_POWER_L) |
                    (node.getResponseBuffer(BATT_POWER_H) << 8))/100.0f);                   
    Serial.println();
    Serial.print("VLoad: ");
    Serial.println(node.getResponseBuffer(LOAD_VOLTS)/100.0f);
    Serial.print("ILoad: ");
    Serial.println(node.getResponseBuffer(LOAD_AMPS)/100.0f);
    Serial.print("PLoad: ");
    Serial.println((node.getResponseBuffer(LOAD_POWER_L) |
                    (node.getResponseBuffer(LOAD_POWER_H) << 8))/100.0f);   
    Serial.println();
    Serial.println();

    WiFiUDP Udp; 
    Udp.beginPacket("10.0.0.199", 9999);

    char data[1024];
    memset(data, 0, 1024);
    int len = snprintf(data, 1024, "pV:%.2f:V,pI:%.2f:A,pP:%.2f:W,bV:%.2f:V,,bI:%.2f:A,bP:%.2f:W,lV:%.2f:V,lI:%.2f:A,lP:%.2f:W", pV, pI, pP, bV, bI, bP, lV, lI, lP);
   
    Udp.write(data, len);
    Udp.endPacket();
   
  } else {
    Serial.print("Miss read, ret val:");
    Serial.println(result, HEX);
  }

  digitalWrite(HB, HIGH);   
  delay(200);               
  digitalWrite(HB, LOW); 
  delay(2000);
}

void preTransmission()
{
  digitalWrite(MAX485_RE, 1);
  digitalWrite(MAX485_DE, 1);
}

void postTransmission()
{
  digitalWrite(MAX485_RE, 0);
  digitalWrite(MAX485_DE, 0);
}

Lunch time!  Code needs quite a bit of protection for failed Wifi etc.  Also need to create an HTTP diagnostics and stats port.

[paulca]

Just a small sample of the output from today:

The start of the logged data for battery charge power.


The raspberry PI display module showing panel current and outdoor temp.


See: https://www.eevblog.com/forum/beginners/finally-got-my-first-project-actually-complete/msg1365705/#msg1365705

[paulca]

Update and progress.

So it's been running for a week on breadboards successfully logging the solar charge controller data.

Here is the best days solar power graph:


Tonight I started the work of putting it all together and into an enclosure.  I found the NodeMCU will sit in the case with one of the screw pillars as support.  I used a drill to lower that screw pillar down a bit and the NodeMCU gets caught perfectly with the enclosure screw through it's mounting hold when the lid is put in place.

Luckily/conveniently this lines the USB port up with the edge of the enclosure.  Cut a notch in the case for the micro usb power and tested that I can connect to the port with the case screwed shut and.. the Wifi still works.

I had to painstakingly desolder all the header pins on the NodeMCU, level shifter and MAX485 board.  After a bit of a faff I got into a rhythm and tidied it up with some desoldering wick.

I soldered the RJ45 tail via a hole drilled in the enclosure onto the MAX485 and then soldered some small stranded wire onto +5V and GND which I then soldered into a Y to give me 5V for the level shifter and the NodeMCU Vin. 

I then soldered more connections back from the NodeMCU 3V and GND to the level shifter.

Probably the most delicate and fiddly bit of work I have done in electronics and soldering fine stranded wire into desoldered holes is frustrating and time consuming.  The epiphany was that using a breadboard wire and the soldering iron I could punch through the solder and ream out the holes much better before attempting to push the stranded wire through.

I was hoping to finish it, but it's 9 o'clock, most of my fingers are burnt and I have experienced the smell of burning hair and flesh too many times.  I need a break. 

I'll hopefully get the remaining Tx, Rx, and two control wires soldered to the level shifter and NodeMCU tomorrow evening.... hopefully before the beer has time to take effect.

Obviously of most importance, when I connect it to the charge controller the Max485 and NodeMCU power on, I can only assume the level shifter is also powered correctly, though it has no LED.

[paulca]

And the hardware is now complete.



and in operation




I can still plug a USB plug into it to program it, so the only thing remaining is to tidy up the software.  Which I'll get to soon.

Presently, it flashes the LED off on a successful read and send and flashes it rapidly 3 times on a failed read or send.  I want to add a few more error codes and a Wifi connection sync rapid flashing on power on.

It's also currently sending every 2 seconds which a bit OTT but not a concern.

I'll post the code when I'm done.  It's beer time.

Outtakes.... I pulled a pad off the ESP8266   Luckily it was for the "DE" control pin, on D2, so I could just move it to D4.  The pad probably got popped when I pushed the breadboard wire though to clear the pcb hole, maybe I was too aggressive and it wasn't quite hot enough.  Well, not to worry, I got lucky it has 14 odd digital pins to play with and I only need 2.

[paulca]

Quick basic block diagram:

[paulca]

A self review of the hardware would include a note that the whole thing could have been reduced to one PCB.  Purchasing a MAX485 chip, a few mosfets for the level shifter and a smaller ESP8266 daughter board.  This would have involved a USB to serial adapter or headers for it to get in-situ program-ability of the MCU.

[paulca]

So it works.  I decided to use the little solar I got the in last day and charge the eCig and general use LiIon 3S pack.

Now normally I would get up and look to check the battery voltage.  I'd have to have enough light to read the solar charge contoller's screen and press the "Next" button until I get to battery voltage.

Tonight I got up and realised thing were easier now, I typed into a terminal:

Code: [Select]

paul@localhost ~ $ /mnt/hub_home/lcd_test/sh/query.sh | sort | egrep "^l"
lI:     2.99 A
lP:     35.61 W
lV:     11.91 V

This info is automagically displayed on the raspberry pi 16x2 oLed sitting in the living room.  I don't want to go lower than 11.8V under load, which will recover to 12.0V.  I can write a shell one liner right now to do that and beep when I hit 11.8V.

Edit:: this turned out easier.

Code: [Select]

paul@localhost ~ $ watch '/mnt/hub_home/lcd_test/sh/query.sh | egrep "^lV"'

Another first tonight, although fairly unrelated.  I spent the later part of the evening lit purely by solar.  Simply running a 20W halogen bulb off my bench supply as an uplighter... which is powered by a LiPo, charged from solar.  For a basic 50W beginner setup that's progress!  A constant 3A more or less.

The PC however is drawing MANY watts for both PC and monitors.  A long term goal is to power the PC and monitors from solar.

[paulca]

Grrr.  So "deep sleep" is a bit of a faff.  I can get the board to go to sleep, but in order to wake itself up I need to connect D0 to RST.  When I do that however I can't program the chip as the programmer uses RST and the thing just hangs.

If I disconnect the jumper I can program it again.

Without the jumper between D0 and RST the chip looks like it might wake up anyway, however it promptly hangs.

There are examples of this issue around on line, but they say different things, some say you need to hold some pins low and other say you need to hold some pins high.  This is exagerated by there being so many different flavours of ESP8266 boards around.  I've shelved it for now.

Disconnecting the Wifi and reconnecting it every 5 seconds produced some incredibly weird results.  In fact the whole WiFi status return codes are bonkers and don't appear to match the documentation.  I ended up so confused I removed all the checks, assume success and ... it works fine.

I'm fed up with it.  It should use less power only sending every 5 seconds instead of every 2 and the LED remaining mostly off.  The WiFi should auto "modem sleep" on it's own.

[chickey]

Just thought i'd say hello as that's my youtube channel.  Not sure what "How you doing" is but glad it provided even a little bit of inspiration.  I've had my little setup going for quite some time and it works very well, it's reporting into grafana now which provides some great stats.

Col

[paulca]

Just thought i'd say hello as that's my youtube channel.  Not sure what "How you doing" is but glad it provided even a little bit of inspiration.  I've had my little setup going for quite some time and it works very well, it's reporting into grafana now which provides some great stats.

Please don't take any offence and mine isn't exactly any further from "How you doing".

"How you doing" is a Dave (EEVBlog founder and Youtube blogger) term he uses to mean a bit "knocked together", "rough around the edges".

It seems we both have working devices, that's the main thing.

Lowering the power consumption... have you made any progress with that?  I tried getting the NodeMCU to sleep, but with the wake pin connected to reset I couldn't program it.  Without the wake pin connected to reset it tried to wake up and crashes.

[chickey]

No offence taken, my aim was to make it as easy and accessible as possible which is why i kept with the components i chose, a friend and youtuber Adam Welch took this a step further and made a PCB to make assembly even easier as well as a 3D enclosure.

Re the power draw I've found it insignificant compared to the load draw so I've never made any inroads to lower it.  I have 600w of panels and 4.4Kwh of battery storage in the form of a home made powerwall so it's been fine, even in winter with little/no sun.

[paulca]

Ah, yes.  I only have 50W.  I found the charge controller with the NodeMCU pulls between 50 and 75mA.  I expect it's 50mA and 75mA while it's doing an update over Wifi.

I took a look at Grafana, thanks for that.  My little raspberry PI monitor is logging all it's data automatically as RRDs, but I was struggling with generating graphs manually and was considering using Cacti.  Grafana looks much better, assuming I can get it installed locally.

If you are interested in the automatic network data logger setup I made check my other thread:
https://www.eevblog.com/forum/beginners/finally-got-my-first-project-actually-complete/msg1365705/#msg1365705

The data output appears to be compatible with Grafana and Cacti and probably others.  If not data can be extracted as XML.

[chickey]

Thanks for the info, i'm running grafana on a pi.  The same pi actually that runs socat to get a serial connection to the Epever charge controller.  I wrote a php script which inputs the data into grafana using php library written for interrogating the charge controller.  I'm also working balancers which report the individual cell voltages back into grafana but still finishing that up.  Is the vampire draw causing issues at 75ma? i was originally running with just a 100w panel with this setup and never had issues.  In one of my later videos i've documented the grafana/epever integration.

[paulca]

It only causes issues when there is a dark rainy day when the panel is only producing circa 100mA for a small part of the day.  So on those days my battery voltage doesn't rise at all.  The system only produces what it consumes itself.  I even switch is off at night now.  Once the mornings start to get brighter before I get up I'll need to start leaving it on all night.

I have to look into Grafana or Graphite to see how well they integrate with RRD files.

My datalogger thing abstracts away the data, so it logs everything and anything into RRDs and then provides it back out to any other node that wants it.  It's simple sent as text, as above in one of the posts.

So it currently logs, 3 indoor temperatures, 1 outdoor, air presssure, humidity, the temp of the raspberry PI and all the solar stats.  Anything I can send to it as one of those strings.

[ajitnayak87]

Dear sir,

The job is excellent. I would like few thing here.

You have configured MPPT as Slave or master.
How many devices can be connected at same time
weather library function attached is working wELL.
I Have modbus rtu device , can u suggest how can make connection to work out

[PeteKnight]

Hi paulca, many thanks for the the very informative post. It's exactly what I was looking for to get me started with my solar monitoring project.

My plan is to use an ESP89266 to update Blynk (www.Blynk.io) with battery condition, charging and power consumption data. Blynk is a mobile app that runs on iOS and Android and it has some very nice graphing and display options built-in.

Did you make any progress with your deep sleep issues? I've used deep sleep quite a bit in some applications, but at this stage I can't make my mind up whether it would be helpful to have constant 2-way communication with the charge controller or to simply have it wake-up ever so often and upload the latest readings. Any thoughts on this?

The system will be used to power garden lights at out holiday home in Spain. We won't be there most of the time, but we'd like to have the garden lights running whether we're there or not.
They are currently a collection of individual lights all with their own small solar panels and batteries, some of which are better than others. The plan is to expand this with some additional lights and to convert the existing lights to run from a centralised solar system. I've not yet worked-out how big my solar panel or battery needs to be, but some tests on the power consumption of the lights we'll be using should give me some ideas, and the remote power monitoring will tell me if I've got my sums right during the time that we aren't there.

Thanks again for the helpful article.

Pete.
 

[paulca]

Hi,

I never revisited deep sleep, just left the thing running.  It's been doing it's job constantly since I made the post.  The device consumes about 40-50mA average.  So even a modest 12V battery could supply it for months without sun.  Only once was this an issue, in January I ran the battery quite low and then after two weeks of short dark rainy days the solar charge controller shut off. 

One recommendation is to make sure the solar charge controller is set to power off with the battery at a sensible voltage.  Mine made it all the way down to 10V which is not good for lead acid batteries.  10.8V or 11V would be better for them.  Note this is not the voltage the load cuts off at, but the charge controller itself.

That said in Spain you should not have the same January weather as me!

[paulca]

Just as a way of update I have updated this collection of bits and bobs to use JSON as it's interchange format, instead of comma separated strings.

This provides an ability to tag more information into each "Datum" such as proper names for things and the hub will timestamp data as it arrives so the display (lcd_heating_monitor.py) can flag stale data by prefixing it with a * on the display.

This was a pre-cursor, call it V1.1 for adding a scheduler and writing data back out to devices, such as, a central heating controller.  It needs to get data by name from the hubs data, test some conditions and then write a named value back, such as "heating_switch":"True".  This upgrade will hopefully come in the next week or two.

The early parts of the scheduler and conditions framework is present in scheduler.py but not hooked up to anything yet.  Basically the scheduler has an ordered set of schedules.  Each schedule has a set of Conditions with modifiers which form a logic chain.  These are evaluated and the schedule returns "True" if it's conditions match.  The scheduler will then call "activate()" on the schedule allowing it to do what it needs to.  If it's conditions return false, the it calls "deactivate()" to allow the schedule to set up it's trigger data.

As an example, a schedule for my base heating value might be:
OR TimeCondition( 06:30, 07:30 )
OR TimeCondition( 17:00, 23:00 )
AND DataCondition( "OR", [("livingRoom", "lessThan", 22), ("bedroom","lessThan",20),("garage","lessThan",1 )] )

The later DataCondition will run the given tests as an OR operation.  If all of these conditions match this schedule will return True and the scheduler will call activate() which will insert/update a Datum item with the key heating_switch: True.

For now I'm aiming at a single active schedule.  Schedules will be in order of priority with the highest first.  Upon finding an active schedule the scheduler will activate it and proceed to deactivate the remaining schedules.  This does require care and attention to not create loops or feedback in the schedules, but certainly much easier to deal with than multi-schedules.

Longer finger I might consider multi-zoning, but I'm currently thinking this will be done a bit crudely with just one independent scheduler per zone.  Of course all schedulers have access to each others data so can cross communicate.

The gitlab for the project should be accessible here:
https://gitlab.com/paulcam/home_heating

[encore2097]

For anyone else who finds this post in 2023, this project makes getting and logging data from Epever ready to go: https://github.com/chickey/RS485-WiFi-EPEver the author also sells an RS485 to WiFi adapter. Saves a lot of time!