gantonel commented 4 years ago

I suggest the following potential improvement for consideration:- 1) Every time the node is restarted it should be reported in the log 2) The .env file may benefit from having two variables so that one decides the critical time of inactivity, before being notified & the other decides how often one should be notified if inactivity continues 3) Maybe there should be two logs one as in the original & another for all the output that is currently going to the terminal window 4) Maybe if the pump is stuck on for more than a certain number of minutes an alert should be emanated, similar to the excessive inactivity. Likewise one could chose how often to be alerted.

mchenier commented 4 years ago

I made the changes. I didn't have time to test it a lot so if you got any problem let me know.

gantonel commented 4 years ago

Thank you for the changes. I have been testing it. There were a couple of issues which I have managed to iron out. I have added a couple extra variables to make it work as I would like. The .env file will have an extra user defined constant, because an inactive pump alarm may not need to be repeated frequently, whereas an overacting pump alert may need to be repeated more frequently. I have not finished yet, but below is the app.js file that I am working on

require('dotenv').config() const powerThreshold = process.env.POWER_THRESHOLD; const aliasDevice = process.env.ALIAS_DEVICE; const userTpLink = process.env.USER_TPLINK; const passTpLink = process.env.PASS_TPLINK; const emailSender = process.env.EMAIL_SENDER; const passEmailSender = process.env.PASS_EMAIL_SENDER; const emailReceiver = process.env.EMAIL_RECEIVER; const waitBetweenRead = process.env.WAIT_BETWEEN_READ; const logFileName = process.env.LOG_FILENAME;

//const idleThreshold = process.env.IDLE_THRESHOLD; const maxIdle = process.env.IDLE_MAX;

//const repeatAlertEvery = process.env.REPEAT_ALERT_EVERY; const repeatMaxIdleAlertEvery = process.env.REPEAT_MAX_IDLE_ALERT_EVERY;

//const deviceRunningTimeThreshold = process.env.DEVICE_RUNNING_TIME_THRESHOLD; const maxRun = process.env.RUN_MAX; const repeatMaxRunAlertEvery = process.env.REPEAT_MAX_RUN_ALERT_EVERY;

//Init logger var log4js = require('log4js'); log4js.configure({ appenders: { out: { type: 'console' }, info: { type: 'file', filename: './' + logFileName + '.log' }, debug: { type: 'file', filename: './' + logFileName + '_debug.log' } }, categories: { default: { appenders: ['out','info'], level: 'info' }, debug: { appenders: ['out','debug'], level: 'info' } } });
const logger = log4js.getLogger('default'); const loggerDebug = log4js.getLogger('debug');

//Init nodemailer const nodemailer = require('nodemailer'); const transporter = nodemailer.createTransport({ service: 'gmail', auth: { user: emailSender, pass: passEmailSender } });

async function main() {
const { login } = require("tplink-cloud-api");

loggerDebug.info("-----Monitoring started!-----");
loggerDebug.info("Acceptable Inactivity             : " + (maxIdle/60).toFixed(2) + " minutes");
loggerDebug.info("Alert for  Inactivity every       : " + (repeatMaxIdleAlertEvery/60).toFixed(2) + " minutes");
loggerDebug.info("Acceptable Activity               : " + (maxRun/60).toFixed(2) + " minutes");
loggerDebug.info("Alert for Excessive activity every: " + (repeatMaxRunAlertEvery/60).toFixed(2) + " minutes");

logger.info("-----Monitoring started!-----");
logger.info("Acceptable Inactivity             : " + (maxIdle/60).toFixed(2) + " minutes");
logger.info("Alert for  Inactivity every       : " + (repeatMaxIdleAlertEvery/60).toFixed(2) + " minutes");
logger.info("Acceptable Activity               : " + (maxRun/60).toFixed(2) + " minutes");
logger.info("Alert for Excessive activity every: " + (repeatMaxRunAlertEvery/60).toFixed(2) + " minutes");

monitoredDevice.init();

try {
  var tplink = await login(userTpLink, passTpLink)
  await tplink.getDeviceList();
}
catch (err) {
  loggerDebug.info(err); 
  return;
} 

while (true) {
  try {
    var device = tplink.getHS110(aliasDevice);
  }  
  catch(err) {
    loggerDebug.info(aliasDevice + " " + err);
    break;
  }

  try {
    monitoredDevice.usage = await device.getPowerUsage();
    loggerDebug.info(JSON.stringify(monitoredDevice.usage));
    verifyStartStop();
    verifyLastTimeStarted();
    verifyRunningTime();
    await sleep(waitBetweenRead); 

  }
  catch (err) {
    loggerDebug.info(err);
    break; 
  }      
}

}

function getDate() { return Date.now()/1000; }

function sleep(s) { return new Promise(resolve => setTimeout(resolve, s*1000), rejected => {}); }

function readLogFile() { var fs = require('fs');

return new Promise(function(resolve, reject) { fs.readFile(logFileName + '.log', 'utf8', function(err, data) { if(err) { reject(err);
} else {
resolve(data); } }); }); }

async function sendEmail(message) {

let dataLog = await readLogFile()
.then(data => { return data; }) .catch(err => { throw(err); });

main();

The final part of the .env file looks as follows

Thats the time between each poll to the power of the device in seconds

WAIT_BETWEEN_READ = 15

Filename of the log. It will be appended with a .log

LOG_FILENAME = Pump

Number of time in second the pump can be idle before you get an alert

IDLE_MAX = 30

Time in second between each of alert message in a period of alert threshold exceeded

REPEAT_MAX_IDLE_ALERT_EVERY = 120

Alert if the device running for more that threshold in second each time it starts

RUN_MAX = 30

Time in second between each of alert message in a period of alert run_max exceeded

REPEAT_MAX_RUN_ALERT_EVERY = 15

mchenier commented 4 years ago

Im glad you are working on improvement on your side but I had to change the API I was using. I was hitting quota on the cloud api. I have now integrated a new api that works locally. Your changes should be easy to reconduct but now the main() is split in half. main() and monitoringLoop(). I have also did the cleanup in the .env since some variable are useless with the new api.

gantonel commented 4 years ago

I am so glad that you made me aware of your project.

I am now not sure whether we should part ways, I would prefer not to. I have not encountered the quota that you mention. Was it the cloud API quota or was it an email quota? How often were you making calls? Are you sure that you did not have multiple "apps" running?

I like the fact that by using the cloud API one could run this from anywhere.

I will check out your current version and let you know what I think of it.

Extra suggestion: As the log could eventually become long, maybe the emails could contain only the last N lines of the log.

Regards

Giorgio Antonelli

mchenier commented 4 years ago

If you need the cloud api I think I can make both available. I was getting the quota when I read every 10sec. I changed to 45 sec and still got the message after a couple of hours. I tough about sending last 50 lines so it's I will do that too. You have great ideas so lets build this thing together :)

mchenier commented 4 years ago

It was easy. You can now use one or the other with a param. I also included the max number of line. See the example.env for detail.

gantonel commented 4 years ago

Things are moving quite fast. I am glad you are allowing both the cloud and the local APIs even though I am not sure which will be preferable in the long run. Before your latest commit I had a look and could not see things clearly. As soon as I get a chance I will look at your latest offerings. I am in Sydney. Where are you?

Regards

Giorgio Antonelli

gantonel commented 4 years ago

Hi MasterMartbob, I have installed your latest code and it seems to be working at a high level (with both APIs). I REALLY like the design choice of having 2 APIs to choose from. I am an amateur programmer and I appreciate your style of coding. Is coding your work?

We will have to decide how to bring across my work from yesterday and whether you or I should do it. No use both doing it.

Further suggestion the reporting and the .env files include measurements of time, voltage, current, power, etc :- I say we should report the units in the output and as far as time measurements, the user should be able to set both the value and the unit. So maximum allowed inactivity could be set at 48 "hours" or 2 "days" or 2880 "minutes" or 172800 "seconds"

An alternative method might be to keep units as seconds and allow the following type of input "22460*60" and to display output in the most appropriate units. I think I am getting a bit fancy, now! I guess the units issue can be handled last. Let us get the whole thing working first!

Further suggestion: in the email body where 50 lines of the log are presented, should we have the most recent lines up the top to reduce the need to scroll down?

mchenier commented 4 years ago

Hi gantonel,

Im in Canada! So that's why you mostly respond in the night :)

Yes I have been coding for a long time and it is my work, but I just learn javascript. I don't apply all the rule of clean coding either with that project. I prefer just retouching it time to time to make it better. I don't want it to feel like work.

Yes your suggestion of specifying the unit is a bit fancy I don't see the real value for now. But yeah reversing the log in the email is a good addition I'll do it.

Next big big would be to make a graph out of all the information but Im not sure how I would want this to be. Maybe you have ideas.

gantonel commented 4 years ago

Hi MasterMartbob,

As far as graphing is concerned, I would have used excel to read the log files, but I will leave that decision to you. Obviously one could do what jamesbarnett91/tplink-energy-monitor does. We could do what the app called Watt does. We may want to graph actual operation time rather than smart socket on-time

Would you like for me to structure the output as I organised in the code I sent last? Two alarms (each with its own repeat rate)? Regards

Giorgio Antonelli Sydney 2/4/2020 2:21PM

On 2 Apr 2020, at 1:16 pm, MasterMartbob notifications@github.com wrote:

Hi gantonel,

Im in Canada! So that's why you mostly respond in the night :)

Yes I have been coding for a long time and it is my work, but I just learn javascript. I don't apply all the rule of clean coding either with that project. I prefer just retouching it time to time to make it better. I don't want it to feel like work.

Yes your suggestion of specifying the unit is a bit fancy I don't see the real value for now. But yeah reversing the log in the email is a good addition I'll do it.

Next big big would be to make a graph out of all the information but Im not sure how I would want this to be. Maybe you have ideas.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MasterMartbob/tplink-hs110-pump-monitor/issues/2#issuecomment-607582383, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7U7MMDE42M5I5GTSPTL4TRKPYQTANCNFSM4LXDCQFA.

mchenier commented 4 years ago

So just a graphic started period with the running time.

Yes you can structure the output. You know how to do a branch. And doing a pull request. If not you can see how to do that. And if you rather me integrating it just send me the code in raw.

mchenier commented 4 years ago

The reverse log in email is done.

mchenier commented 4 years ago

I rename myself in github so if you were using git locally you will have to update your origin git remote set-url origin https://github.com/mchenier/tplink-hs110-pump-monitor.git

gantonel commented 4 years ago

I was quite happy that the logic was woking as expected and the output was as I liked it when I pasted the code for app.js in one of the comments above. I am new to github so I would have to learn about Branches Pull request and What you mean by “code in raw”

I tried to attach the app.js file to a comment, but only certain file types were allowed, hence the pasting

This is one of two projects I am working on. The other one is purely for fun. It is a competition found at AZsPCs.com http://azspcs.com/ and is called “sums of powers”

I have now tried to branch, unsuccessfully I have tried a Pull request to no avail So I am going to attach the app.js file to this message and see what happens I could not send .js attachments, so I added .txt to it!

Regards

Giorgio

On 2 Apr 2020, at 11:00 pm, MasterMartbob <notifications@github.com mailto:notifications@github.com> wrote:

So just a graphic started period with the running time.

Yes you can structure the output. You know how to do a branch. And doing a pull request. If not you can see how to do that. And if you rather me integrating it just send me the code in raw.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MasterMartbob/tplink-hs110-pump-monitor/issues/2#issuecomment-607802417, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7U7MK4GV2OJ5KERSWFYW3RKR46RANCNFSM4LXDCQFA.

require('dotenv').config() const powerThreshold = process.env.POWER_THRESHOLD; const aliasDevice = process.env.ALIAS_DEVICE; const userTpLink = process.env.USER_TPLINK; const passTpLink = process.env.PASS_TPLINK; const emailSender = process.env.EMAIL_SENDER; const passEmailSender = process.env.PASS_EMAIL_SENDER; const emailReceiver = process.env.EMAIL_RECEIVER; const waitBetweenRead = process.env.WAIT_BETWEEN_READ; const logFileName = process.env.LOG_FILENAME;

//const idleThreshold = process.env.IDLE_THRESHOLD; const maxIdle = process.env.IDLE_MAX;

//const repeatAlertEvery = process.env.REPEAT_ALERT_EVERY; const repeatMaxIdleAlertEvery = process.env.REPEAT_MAX_IDLE_ALERT_EVERY;

//const deviceRunningTimeThreshold = process.env.DEVICE_RUNNING_TIME_THRESHOLD; const maxRun = process.env.RUN_MAX; const repeatMaxRunAlertEvery = process.env.REPEAT_MAX_RUN_ALERT_EVERY;

//Init logger var log4js = require('log4js'); log4js.configure({ appenders: { out: { type: 'console' }, info: { type: 'file', filename: './' + logFileName + '.log' }, debug: { type: 'file', filename: './' + logFileName + '_debug.log' } }, categories: { default: { appenders: ['out','info'], level: 'info' }, debug: { appenders: ['out','debug'], level: 'info' } } });
const logger = log4js.getLogger('default'); const loggerDebug = log4js.getLogger('debug');

//Init nodemailer const nodemailer = require('nodemailer'); const transporter = nodemailer.createTransport({ service: 'gmail', auth: { user: emailSender, pass: passEmailSender } });

async function main() {
const { login } = require("tplink-cloud-api");

loggerDebug.info("-----Monitoring started!-----");
loggerDebug.info("Acceptable Inactivity             : " + (maxIdle/60).toFixed(2) + " minutes");
loggerDebug.info("Alert for  Inactivity every       : " + (repeatMaxIdleAlertEvery/60).toFixed(2) + " minutes");
loggerDebug.info("Acceptable Activity               : " + (maxRun/60).toFixed(2) + " minutes");
loggerDebug.info("Alert for Excessive activity every: " + (repeatMaxRunAlertEvery/60).toFixed(2) + " minutes");

logger.info("-----Monitoring started!-----");
logger.info("Acceptable Inactivity             : " + (maxIdle/60).toFixed(2) + " minutes");
logger.info("Alert for  Inactivity every       : " + (repeatMaxIdleAlertEvery/60).toFixed(2) + " minutes");
logger.info("Acceptable Activity               : " + (maxRun/60).toFixed(2) + " minutes");
logger.info("Alert for Excessive activity every: " + (repeatMaxRunAlertEvery/60).toFixed(2) + " minutes");

monitoredDevice.init();

try {
  var tplink = await login(userTpLink, passTpLink)
  await tplink.getDeviceList();
}
catch (err) {
  loggerDebug.info(err); 
  return;
} 

while (true) {
  try {
    var device = tplink.getHS110(aliasDevice);
  }  
  catch(err) {
    loggerDebug.info(aliasDevice + " " + err);
    break;
  }

  try {
    monitoredDevice.usage = await device.getPowerUsage();
    loggerDebug.info(JSON.stringify(monitoredDevice.usage));
    verifyStartStop();
    verifyLastTimeStarted();
    verifyRunningTime();
    await sleep(waitBetweenRead); 

  }
  catch (err) {
    loggerDebug.info(err);
    break; 
  }      
}

}

function getDate() { return Date.now()/1000; }

function sleep(s) { return new Promise(resolve => setTimeout(resolve, s*1000), rejected => {}); }

function readLogFile() { var fs = require('fs');

return new Promise(function(resolve, reject) { fs.readFile(logFileName + '.log', 'utf8', function(err, data) { if(err) { reject(err);
} else {
resolve(data); } }); }); }

async function sendEmail(message) {

let dataLog = await readLogFile()
.then(data => { return data; }) .catch(err => { throw(err); });

main();

mchenier commented 4 years ago

I compared the file and I have made the change I think you made. but there was some redundant variable. If you prefer having boolean instead of lastTimeRunning.... etc you could make function that returns a boolean from a calculation from the variable already present.
Also if you write exactly the same thing in both log we should probably consider reconfiguring them or merge then I don't know.

Tell me if I got something wrong.

Thanks for your work.

gantonel commented 4 years ago

I thank YOU for YOUR great work. I will be checking it out soon. Regards

Giorgio

gantonel commented 4 years ago

the file https://github.com/mchenier/tplink-hs110-pump-monitor/blob/master/README.md still refers to git clone https://github.com/**MasterMartbob**/tplink-hs110-pump-monitor.git && cd tplink-hs110-pump-monitor

mchenier commented 4 years ago

Good catch. Fixed.

gantonel commented 4 years ago

However, it worked even with the old reference

Sent from my iPhone

On 3 Apr 2020, at 11:04 pm, mchenier notifications@github.com wrote:

Good catch. Fixed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

gantonel commented 4 years ago

Hi there,

Our work is nearly done. Below is a sample of the way I have customised your latest code. You will notice that the alarm times have been set very short and the power values are consistent with a lamp which I was manually operating while debugging

As you have previously said the loggerDebug can eventually be eliminated, but can be left active for a while As you will notice from the output the usage record seems different between the two APIs. Given that the LAN version only has extra units-conversion fields after the err_code, we may choose to eliminate them for conformity!

The .env file could be changed a little to make it more consistent with the variable names in the App.js At the moment it contains

Use tplink-cloud-api if true otherwise use tplink-smarthome-api. Other parameters below only usefull for cloud API.

cloud and lan should be use

API_SELECTION = not cloud

I think “true” should be changed to “cloud”

It required a lot of work for me to get it back to what I had before, but I am happy with the results. I have had to reintroduce some variables that may have seemed superfluous, but to get the output I prefer I could not do without them. I am very happy that we have 2 APIs to chose from. If we could somehow organise a pull request I would be very happy to get to you the modified 2 files (example.env and App.js) Until we get the files to you, I would prefer if you let me know which changes to make to my files, rather than having to re-implement my logic to get the output below, which BTW should be quite acceptable. I hope you like it There could be a space needed here and there, but it is almost a finished job. Without the structure that you created and modified I would have had no chance of getting to this stage. BTW I have never coded in JS Obviously it would be the logger to be emailed (not the loggerDebug)

Extra thought: At the beginning of each run as well as the 6 lines of output we should print out how often we are sampling the HS110 Once we agree that we are there, I would not mind doing some tidying up if or where required The test log below shows that the alarms are working well

[2020-04-04T05:47:16.339] [INFO] default - Acceptable Inactivity : 0.50 minutes [2020-04-04T05:47:16.339] [INFO] default - Alert for Inactivity every : 1.00 minutes [2020-04-04T05:47:16.339] [INFO] default - Acceptable Activity : 0.50 minutes [2020-04-04T05:47:16.339] [INFO] default - Alert for Excessive activity every: 0.25 minutes [2020-04-04T05:47:16.382] [INFO] default - -----Monitoring started!----- [2020-04-04T05:47:16.383] [INFO] default - ----- using CLOUD API ----- [2020-04-04T05:47:55.504] [INFO] default - Pump didn't start for the last 0.65 minutes [2020-04-04T05:49:04.325] [INFO] default - Pump didn't start for the last 1.80 minutes [2020-04-04T05:49:15.638] [INFO] default - Pump Started{"voltage_mv":235279,"current_ma":145,"power_mw":19913,"total_wh":78,"err_code":0} [2020-04-04T05:49:50.412] [INFO] default - Pump running for more then 0.58 minutes [2020-04-04T05:50:13.492] [INFO] default - Pump running for more then 0.96 minutes [2020-04-04T05:50:36.535] [INFO] default - Pump running for more then 1.35 minutes [2020-04-04T05:50:59.851] [INFO] default - Pump running for more then 1.74 minutes [2020-04-04T05:51:22.621] [INFO] default - Pump Stopped{"voltage_mv":233791,"current_ma":18,"power_mw":0,"total_wh":79,"err_code":0} [2020-04-04T05:51:57.306] [INFO] default - Pump didn't start for the last 0.58 minutes [2020-04-04T05:53:47.139] [INFO] default - Acceptable Inactivity : 0.50 minutes [2020-04-04T05:53:47.139] [INFO] default - Alert for Inactivity every : 1.00 minutes [2020-04-04T05:53:47.139] [INFO] default - Acceptable Activity : 0.50 minutes [2020-04-04T05:53:47.140] [INFO] default - Alert for Excessive activity every: 0.25 minutes [2020-04-04T05:53:47.177] [INFO] default - -----Monitoring started!----- [2020-04-04T05:53:47.177] [INFO] default - ----- using LAN API ----- [2020-04-04T05:54:17.408] [INFO] default - Pump didn't start for the last 0.50 minutes [2020-04-04T05:55:27.458] [INFO] default - Pump didn't start for the last 1.67 minutes [2020-04-04T05:55:37.597] [INFO] default - Pump Started{"voltage_mv":234701,"current_ma":145,"power_mw":19995,"total_wh":79,"err_code":0,"current":0.145,"power":19.995,"total":0.079,"voltage":234.701} [2020-04-04T05:56:17.539] [INFO] default - Pump running for more then 0.67 minutes [2020-04-04T05:56:37.511] [INFO] default - Pump running for more then 1.00 minutes [2020-04-04T05:56:57.482] [INFO] default - Pump running for more then 1.33 minutes [2020-04-04T05:57:17.453] [INFO] default - Pump running for more then 1.66 minutes [2020-04-04T05:57:27.592] [INFO] default - Pump Stopped{"voltage_mv":235039,"current_ma":18,"power_mw":0,"total_wh":80,"err_code":0,"current":0.018,"power":0,"total":0.08,"voltage":235.039} [2020-04-04T05:58:07.542] [INFO] default - Pump didn't start for the last 0.67 minutes

Regards

Giorgio

On 3 Apr 2020, at 11:04 pm, mchenier notifications@github.com wrote:

Good catch. Fixed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mchenier/tplink-hs110-pump-monitor/issues/2#issuecomment-608395942, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7U7MP4U4JCM342ZCZJZR3RKXGDDANCNFSM4LXDCQFA.

gantonel commented 4 years ago

I have managed to create a pull request

mchenier commented 4 years ago

Hi,

I don't see the pull request.

For the fix in example.env with the cloud thing. Fixed

For the standardisation of the output of both api I don't see the need for now. I need to learn REACT in a few months so I will probably need to output something more standard so I can graph something with the output. Until then it's only debug output so I leave it alone.

By the way the LAN api is strong and the app didn't crash during the night like with cloud api. So I don't know how if you still have zero problem with the cloud api but I don't understand why you don't hit the quota.

gantonel commented 4 years ago

Hi Maybe the crashes I had were misinterpreted by me. I though my network had gone down. I will see what happens when I run it again. I have not been running the program while debugging, because I had the socket on my desk rather than near the sump-pump I will have to work out how to do a pull request On my GitHub page you should be able to see both of the files I have modified.

Thanks again.

Giorgio

On 4 Apr 2020, at 7:05 am, mchenier notifications@github.com wrote:

Hi,

I don't see the pull request.

For the fix in example.env with the cloud thing. Fixed

For the standardisation of the output of both api I don't see the need for now. I need to learn REACT in a few months so I will probably need to output something more standard so I can graph something with the output. Until then it's only debug output so I leave it alone.

By the way the LAN api is strong and the app didn't crash during the night like with cloud api. So I don't know how if you still have zero problem with the cloud api but I don't understand why you don't hit the quota.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mchenier/tplink-hs110-pump-monitor/issues/2#issuecomment-608633915, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7U7MKYYB6H4UJCIWAE24LRKY6RVANCNFSM4LXDCQFA.

gantonel commented 4 years ago

Hi M Chenier,

I apologise for possibly misleading you. I have got the same error as other nights and I now realise that it could be the quota error that you refer to. I thought they were errors due to my WiFi having problems. Here are the first few lines of the error report Error: connect ENETDOWN 18.136.180.38:443 - Local (192.168.0.8:59630) at internalConnect (net.js:917:16) at defaultTriggerAsyncIdScope (internal/async_hooks.js:311:12) at GetAddrInfoReqWrap.emitLookup [as callback] (net.js:1059:9) at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:69:10) { errno: 'ENETDOWN', code: 'ENETDOWN', syscall: 'connect', address: '18.136.180.38', port: 443,

Which part of the error report reveals the quota issue? Where would I look to confirm that we are having the same issue?

Maybe, I will have to reconsider and revert to the LAN API.

In logToEmail() I made the following changes to avoid the commas splitting the data in smaller lines

dataLog = dataLog.slice(Math.max(dataLog.length - nbLineLogEmail, 0)); for (let i = 0; i < dataLog.length; i++){ dataLog[i] =dataLog[i].toString().replace(/,/g,";"); console.log(dataLog[i]);
} dataLog = dataLog.reverse(); dataLog = dataLog.toString().replace(/,/g, "\n"); dataLog = dataLog.replace(/;/g, ",");
return dataLog;

Regards

Giorgio

On 4 Apr 2020, at 7:05 am, mchenier notifications@github.com wrote:

Hi,

I don't see the pull request.

For the fix in example.env with the cloud thing. Fixed

For the standardisation of the output of both api I don't see the need for now. I need to learn REACT in a few months so I will probably need to output something more standard so I can graph something with the output. Until then it's only debug output so I leave it alone.

By the way the LAN api is strong and the app didn't crash during the night like with cloud api. So I don't know how if you still have zero problem with the cloud api but I don't understand why you don't hit the quota.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mchenier/tplink-hs110-pump-monitor/issues/2#issuecomment-608633915, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7U7MKYYB6H4UJCIWAE24LRKY6RVANCNFSM4LXDCQFA.

gantonel commented 4 years ago

Hi again,

Looking at 2 Debug logs, I can now see that when polled every 10 seconds the responses stop coming promptly after 6 hours in one case and 15.5 hours in the other. The responses then come at short bursts after approximately 1 or 2 hours and after several responses terminate altogether.

Regards

GA

On 5 Apr 2020, at 7:33 am, Giorgio Antonelli antonelli.giorgio@gmail.com wrote:

Hi M Chenier,

I apologise for possibly misleading you. I have got the same error as other nights and I now realise that it could be the quota error that you refer to. I thought they were errors due to my WiFi having problems. Here are the first few lines of the error report Error: connect ENETDOWN 18.136.180.38:443 - Local (192.168.0.8:59630) at internalConnect (net.js:917:16) at defaultTriggerAsyncIdScope (internal/async_hooks.js:311:12) at GetAddrInfoReqWrap.emitLookup [as callback] (net.js:1059:9) at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:69:10) { errno: 'ENETDOWN', code: 'ENETDOWN', syscall: 'connect', address: '18.136.180.38', port: 443,

Which part of the error report reveals the quota issue? Where would I look to confirm that we are having the same issue?

Maybe, I will have to reconsider and revert to the LAN API.

In logToEmail() I made the following changes to avoid the commas splitting the data in smaller lines

dataLog = dataLog.slice(Math.max(dataLog.length - nbLineLogEmail, 0)); for (let i = 0; i < dataLog.length; i++){ dataLog[i] =dataLog[i].toString().replace(/,/g,";"); console.log(dataLog[i]);
} dataLog = dataLog.reverse(); dataLog = dataLog.toString().replace(/,/g, "\n"); dataLog = dataLog.replace(/;/g, ",");
return dataLog;

Regards

Giorgio

On 4 Apr 2020, at 7:05 am, mchenier <notifications@github.com mailto:notifications@github.com> wrote:

Hi,

I don't see the pull request.

For the fix in example.env with the cloud thing. Fixed

For the standardisation of the output of both api I don't see the need for now. I need to learn REACT in a few months so I will probably need to output something more standard so I can graph something with the output. Until then it's only debug output so I leave it alone.

By the way the LAN api is strong and the app didn't crash during the night like with cloud api. So I don't know how if you still have zero problem with the cloud api but I don't understand why you don't hit the quota.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mchenier/tplink-hs110-pump-monitor/issues/2#issuecomment-608633915, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7U7MKYYB6H4UJCIWAE24LRKY6RVANCNFSM4LXDCQFA.

mchenier commented 4 years ago

Yes this is probably due to the quota on the cloud API.

I have made some changes: .env is no longer use. I transfer everything to a config.json like it should be. Now everything is explain in the README.

I also made some release package for people who don't want to understand everything about npm. I will try to update them when I make important changes.

I also added a file that I write in csv format the Start and Stop time also the running time. You should probably use that file for your excel graph. I was able to have graph I wanted in Google Sheet. I will see if I go further with that graph thing.

gantonel commented 4 years ago

Are the instructions still as follows?

Usage

You will need node.js to run this. https://nodejs.org/en/download/

$ git clone https://github.com/MasterMartbob/tplink-hs110-pump-monitor.git && cd tplink-hs110-pump-monitor
$ npm install

Rename example.env to .env Edit the .env to match your needs every parameter is explained in the file.

Just run this command after to start the app.


npm start

gantonel commented 4 years ago

How do I start the new package? Is it still "npm start"? I have set waitbetweenreads to be 30 but it still waits only 10 seconds

mchenier commented 4 years ago

The procedure was change I don't know why you still have the old one. Readme is up to date. You have to edit config.json instead.

Yes the rest is the same. You don't need to use the package if you don't want to.

The waitbetweenreads is only for cloud. There is no such option for lan api it just update when it gets new data. Since there is no limit it should'nt be a problem on LAN.

mchenier commented 4 years ago

Example of type of graph I will try to do. https://i.imgur.com/NB1yeHp.png

This is the data i got today. So the pump runs about 4 times an hour for 75 minutes

gantonel commented 4 years ago

Thanks

Sent from my iPhone

On 7 Apr 2020, at 7:18 am, mchenier notifications@github.com wrote:

The procedure was change I don't know why you still have the old one. Readme is up to date. You have to edit config.json instead.

Yes the rest is the same. You don't need to use the package if you don't want to.

The waitbetweenreads is only for cloud. There is no such option for lan api it just update when it gets new data. Since there is no limit it should'nt be a problem on LAN.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

gantonel commented 4 years ago

Do you simply double click the package? How does it show up in Activity Monitor on OSX?

Sent from my iPhone

On 7 Apr 2020, at 7:18 am, mchenier notifications@github.com wrote:

The procedure was change I don't know why you still have the old one. Readme is up to date. You have to edit config.json instead.

Yes the rest is the same. You don't need to use the package if you don't want to.

The waitbetweenreads is only for cloud. There is no such option for lan api it just update when it gets new data. Since there is no limit it should'nt be a problem on LAN.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

mchenier commented 4 years ago

I use a utility to make the package and Im on Windows so I could only test that one. You just put the config.json file just beside it and run the program.

gantonel commented 4 years ago

I understand, and I think I have tried. When you say run the program do you mean App.js or package.json? Where would I find instructions to “make the package”?

On 7 Apr 2020, at 7:41 am, mchenier notifications@github.com wrote:

I use a utility to make the package and Im on Windows so I could only test that one. You just put the config.json file just beside it and run the program.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mchenier/tplink-hs110-pump-monitor/issues/2#issuecomment-610052106, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7U7MNB4J4M6HWCFNX463TRLJECPANCNFSM4LXDCQFA.

gantonel commented 4 years ago

That would be great. Would that be time of operation or power used?

On 7 Apr 2020, at 7:23 am, mchenier notifications@github.com wrote:

Example of type of graph I will try to do. https://i.imgur.com/NB1yeHp.png https://i.imgur.com/NB1yeHp.png This is the data i got today. So the pump runs about 4 times an hour for 75 minutes

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mchenier/tplink-hs110-pump-monitor/issues/2#issuecomment-610044093, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7U7MNLFR7R566ZCUXQWX3RLJB45ANCNFSM4LXDCQFA.

mchenier commented 4 years ago

I added a section package in the README. Hope it's clear.

Don't forget this part is totally optional. You can still run npm start. I just wanted to offer something more user friendly.

gantonel commented 4 years ago

Thanks

Sent from my iPhone

On 8 Apr 2020, at 12:04 am, mchenier notifications@github.com wrote:

I added a section package in the README. Hope it's clear.

Don't forget this part is totally optional. You can still run npm start. I just wanted to offer something more user friendly.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

gantonel commented 4 years ago

Hi I had not noticed the releases until few minutes ago. I have tried to download and install tplink-hs110-pump-monitor-macos but it did not work. Even when I gave permission to install the package, it looks like it is treated as a txt file!

I have continued to test the cloud api and even though I increased the interval between polls to 30 seconds I still got an error, but this time it was ECONNRESET, rather than the ones I have received in the past ( i.e. Error: connect ENETDOWN)

I will continue testing the cloud by increasing the interval ( I have just made it 60 seconds) The following is the read me file. I have made my suggested changes bold italic and underlined I also suggested reordering the description of the 4 alert parameters

TPLink HS110 Pump Monitor Monitor a HS110 power so you can get notification on device start and stop. There is also an alert if the device is idle for a long period of time. Usefull for a sump pump but could serve other needs. Written in Node.js using https://github.com/plasticrake/tplink-smarthome-api https://github.com/plasticrake/tplink-smarthome-api and https://www.npmjs.com/package/tplink-cloud-api https://www.npmjs.com/package/tplink-cloud-api. You can select if you prefer using the cloud API or Lan API. The cloud API has some limitation on the number of calls you can do per day so it may be best to use the LAN if possible. Usage Package Take a copy of the file example.config.json. Rename example.config.json to config.json. Edit the config.json to match your needs Every parameter is explained in the config section. Go in the release section and take the latest version. https://github.com/mchenier/tplink-hs110-pump-monitor/releases https://github.com/mchenier/tplink-hs110-pump-monitor/releasesRun the program with the config.json in the same folder. Using Node.js Install Node.js if you don't have it. https://nodejs.org/en/download/ https://nodejs.org/en/download/$ git clone https://github.com/mchenier/tplink-hs110-pump-monitor.git && cd tplink-hs110-pump-monitor $ npm install Rename example.config.env to config.json. Edit the config.json to match your needs every parameter is explained in the config section. Just run this command after to start the app. Go in command line in the project directory and type npm start Config This is all parameters you must configure to make the application run. There is a file example.config.json giving you good start to setup your instance.

powerThreshold the device is detected to be started (I think the unit is watt). Power at which the device is detected to be started (I think the unit is watt) . . aliasDevice Name of your device in the TPLink app. Name of your device in the TPLink app . emailSender https://hotter.io/docs/email-accounts/secure-app-gmail/ https://hotter.io/docs/email-accounts/secure-app-gmail/ Gmail account you will be using to send email. I strongly recommend creating a new gmail account for this app since you will have to give permission to that account for unauthorized google app. https://hotter.io/docs/email-accounts/secure-app-gmail / https://hotter.io/docs/email-accounts/secure-app-gmail/ / https://hotter.io/docs/email-accounts/secure-app-gmail/ passEmailSender Password for the sender email. Password for the sender email . emailReceiver you will received the alerts. I use the same but it could be another one. Email to which you will received the alerts. I use the same but it could be another one . . logFileName Filename of the log. It will be appended with a .log. Filename of the log. It will be appended with a .log .

idleThreshold

the pump can be idle before you get an alert. Length of time in seconds the pump can be idle before you get an alert . .

repeatIdleAlertEvery Time in second between each of idle alert message in a period of alert threshold exceeded.

deviceRunningTimeThreshold Alert if the device running for more that threshold in second each time it starts. Alert if the device running for more that threshold in second each time it starts . repeatRunningAlertEvery Time in second between each of running alert message in a period of alert threshold exceeded.

nbLineLogEmail Number of line of the log to send in the email. Number of line of the log to send in the email .

Cloud API related

apiSelection Use tplink-cloud-api if set to cloud otherwise use tplink-smarthome-api. Other parameters below only usefull for cloud API. cloud and lan should be use Use tplink-cloud-api if set to cloud otherwise use tplink-smarthome-api. Other parameters below only usefull for cloud API. cloud and lan should be us e userTpLink Username to connect in TPLink app. Username to connect in TPLink app . passTpLink Password to connect in TPLink app. Password to connect in TPLink app . waitBetweenRead Thats the time between each poll to the power of the device in second. Thats the time between each poll to the power of the device in second .

Package

If you want to make a package. I used the pkg utiliy (https://github.com/zeit/pkg https://github.com/zeit/pkg)

npm install -g pkg Go in command line in the project directory and type the following.

pkg . Just have a config.json in the same directory has the executable and execute it.

Alert / Log

Every time the device start or stop there will be an entry in a log file of the name you choose. There will also an email sent to the email you choose. The entire log will be sent in the email. There is also an alert if the device didn't start for a period of time.

Improvement

I made this little project because the need of monitoring my pump is important for me and didn't find anything else that work like I wanted. If you want to contribute or have a good idea please let me know.

On 8 Apr 2020, at 12:04 am, mchenier notifications@github.com wrote:

I added a section package in the README. Hope it's clear.

Don't forget this part is totally optional. You can still run npm start. I just wanted to offer something more user friendly.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mchenier/tplink-hs110-pump-monitor/issues/2#issuecomment-610406234, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7U7ML5U6ZGAXY2ZV6443LRLMXGXANCNFSM4LXDCQFA.

vdasilva commented 4 years ago

Just want to thank you both for the effort put into this. I've just successfully configured it to monitor my pool pump for excessive and insufficient run time. My last wish is for it to be able to run in a docker container. I might start that adventure one of these weekends! thanks again!

gantonel commented 4 years ago

You are welcome. Mchenier is the real mastermind here, but I have enjoyed collaborating with him and learning.

Sent from my iPhone

On 12 Apr 2020, at 3:05 pm, vdasilva notifications@github.com wrote:

Just want to thank you both for the effort put into this. I've just successfully configured it to monitor my pool pump for excessive and insufficient run time. My last wish is for it to be able to run in a docker container. I might start that adventure one of these weekends! thanks again!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

mchenier commented 4 years ago

Im really glad it helps other people with other situation :)

Running it in docker should be really simple. May I ask why you prefer docker over just the npm start or even the release package ?

Docker in production environnement is really usefull but for the home app I didn't think it could improve the situation. Also since the cloud API have it's limit I don't think it would be a good idea to run this app in a app cloud service.

gantonel commented 4 years ago

Hi,

Thanks, I did not even know anything about docker. I agree that the cloud API was unreliable enough for me to abandon it. However, I have noticed that the LOCAL API generally gets data every 10 seconds or so, but during the night the log contained the following lines

2020-04-12T21:42:38.513 12/4/20 21:42:38 12/4/20 21:42 0.000115741 2020-04-12T21:42:48.521 12/4/20 21:42:48 12/4/20 21:42 0.000115741 2020-04-12T21:42:58.529 12/4/20 21:42:58 12/4/20 21:42 0.000115741 2020-04-12T21:43:08.536 12/4/20 21:43:08 12/4/20 21:43 0.000115741 2020-04-12T21:43:18.597 12/4/20 21:43:18 12/4/20 21:43 0.000115741 2020-04-12T23:23:12.693 12/4/20 23:23:12 12/4/20 23:23 0.069375 2020-04-12T23:23:18.238 12/4/20 23:23:18 12/4/20 23:23 6.94444E-05 2020-04-12T23:23:22.407 12/4/20 23:23:22 12/4/20 23:23 4.62963E-05 2020-04-12T23:23:32.417 12/4/20 23:23:32 12/4/20 23:23 0.000115741 2020-04-12T23:23:42.430 12/4/20 23:23:42 12/4/20 23:23 0.000115741 2020-04-12T23:23:52.443 12/4/20 23:23:52 12/4/20 23:23 0.000115741 2020-04-12T23:24:02.461 12/4/20 23:24:02 12/4/20 23:24 0.000115741 2020-04-12T23:24:12.466 12/4/20 23:24:12 12/4/20 23:24 0.000115741 2020-04-13T01:24:29.401 13/4/20 1:24:29 13/4/20 1:24 0.083530093 2020-04-13T01:24:39.350 13/4/20 1:24:39 13/4/20 1:24 0.000115741 2020-04-13T01:24:49.364 13/4/20 1:24:49 13/4/20 1:24 0.000115741 2020-04-13T01:24:59.374 13/4/20 1:24:59 13/4/20 1:24 0.000115741 2020-04-13T01:25:09.649 13/4/20 1:25:09 13/4/20 1:25 0.000115741 2020-04-13T03:25:16.360 13/4/20 3:25:16 13/4/20 3:25 0.083414352 2020-04-13T03:25:26.290 13/4/20 3:25:26 13/4/20 3:25 0.000115741 2020-04-13T03:25:36.303 13/4/20 3:25:36 13/4/20 3:25 0.000115741 2020-04-13T03:25:46.712 13/4/20 3:25:46 13/4/20 3:25 0.000115741 2020-04-13T03:25:56.723 13/4/20 3:25:56 13/4/20 3:25 0.000115741 2020-04-13T03:26:06.736 13/4/20 3:26:06 13/4/20 3:26 0.000115741 2020-04-13T03:26:16.973 13/4/20 3:26:16 13/4/20 3:26 0.000115741 2020-04-13T05:26:23.315 13/4/20 5:26:23 13/4/20 5:26 0.083414352 2020-04-13T05:26:28.231 13/4/20 5:26:28 13/4/20 5:26 5.78704E-05 2020-04-13T05:26:33.096 13/4/20 5:26:33 13/4/20 5:26 5.78704E-05 2020-04-13T05:26:43.107 13/4/20 5:26:43 13/4/20 5:26 0.000115741 2020-04-13T05:26:53.120 13/4/20 5:26:53 13/4/20 5:26 0.000115741 2020-04-13T05:27:03.260 13/4/20 5:27:03 13/4/20 5:27 0.000115741 2020-04-13T06:12:14.073 13/4/20 6:12:14 13/4/20 6:12 0.031377315 2020-04-13T06:12:24.035 13/4/20 6:12:24 13/4/20 6:12 0.000115741 2020-04-13T06:12:34.043 13/4/20 6:12:34 13/4/20 6:12 0.000115741 2020-04-13T06:12:44.044 13/4/20 6:12:44 13/4/20 6:12 0.000115741 2020-04-13T06:12:54.050 13/4/20 6:12:54 13/4/20 6:12 0.000115741 2020-04-13T06:13:04.140 13/4/20 6:13:04 13/4/20 6:13 0.000115741

It would seem that the regular reporting of the LOCAL API takes a brake for an hour or two or 40 minutes. In spite of this issue, the app keeps running, whereas the cloud API issues used to stop the app! Does anybody get similar brakes in the log?

On 13 Apr 2020, at 3:14 am, mchenier notifications@github.com wrote:

Im really glad it helps other people with other situation :)

Running it in docker should be really simple. May I ask why you prefer docker over just the npm start or even the release package ?

Docker in production environnement is really usefull but for the home app I didn't think it could improve the situation. Also since the cloud API have it's limit I don't think it would be a good idea to run this app in a app cloud service.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mchenier/tplink-hs110-pump-monitor/issues/2#issuecomment-612647617, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7U7MP2TSJIP32JOCQO6B3RMHZHZANCNFSM4LXDCQFA.

gantonel commented 4 years ago

The lines quoted above had been manipulated in Excel to compare times on different lines. Here are some of the lines from the debug log [2020-04-12T23:23:52.443] [INFO] debug - {"voltage_mv":232969,"current_ma":18,"power_mw":0,"total_wh":86,"err_code":0,"current":0.018,"power":0,"total":0.086,"voltage":232.969} [2020-04-12T23:24:02.461] [INFO] debug - {"voltage_mv":232502,"current_ma":18,"power_mw":0,"total_wh":86,"err_code":0,"current":0.018,"power":0,"total":0.086,"voltage":232.502} [2020-04-12T23:24:12.466] [INFO] debug - {"voltage_mv":232884,"current_ma":18,"power_mw":0,"total_wh":86,"err_code":0,"current":0.018,"power":0,"total":0.086,"voltage":232.884} [2020-04-13T01:24:29.401] [INFO] debug - {"voltage_mv":235742,"current_ma":18,"power_mw":0,"total_wh":86,"err_code":0,"current":0.018,"power":0,"total":0.086,"voltage":235.742} [2020-04-13T01:24:39.350] [INFO] debug - {"voltage_mv":235894,"current_ma":18,"power_mw":0,"total_wh":86,"err_code":0,"current":0.018,"power":0,"total":0.086,"voltage":235.894} [2020-04-13T01:24:49.364] [INFO] debug - {"voltage_mv":235335,"current_ma":18,"power_mw":0,"total_wh":86,"err_code":0,"current":0.018,"power":0,"total":0.086,"voltage":235.335} [2020-04-13T01:24:59.374] [INFO] debug - {"voltage_mv":235451,"current_ma":18,"power_mw":0,"total_wh":86,"err_code":0,"current":0.018,"power":0,"total":0.086,"voltage":235.451} [2020-04-13T01:25:09.649] [INFO] debug - {"voltage_mv":235990,"current_ma":18,"power_mw":0,"total_wh":86,"err_code":0,"current":0.018,"power":0,"total":0.086,"voltage":235.99} [2020-04-13T03:25:16.360] [INFO] debug - {"voltage_mv":237279,"current_ma":18,"power_mw":0,"total_wh":94,"err_code":0,"current":0.018,"power":0,"total":0.094,"voltage":237.279} You will notice that activity was not detected, BUT the “total_wh” changed from 86 to 94. For this reason I would suggest that "total_wh”:94 and or "total”:0.094 be reported on log as activity having taken place. Every log line would contain cumulative power used In cases of noticed increased cumulative power (especially after a brake) be treated as activity and reset appropriate flags and timers

Regards

On 13 Apr 2020, at 7:20 am, Giorgio Antonelli antonelli.giorgio@gmail.com wrote:

Hi,

Thanks, I did not even know anything about docker. I agree that the cloud API was unreliable enough for me to abandon it. However, I have noticed that the LOCAL API generally gets data every 10 seconds or so, but during the night the log contained the following lines

2020-04-12T21:42:38.513 12/4/20 21:42:38 12/4/20 21:42 0.000115741 2020-04-12T21:42:48.521 12/4/20 21:42:48 12/4/20 21:42 0.000115741 2020-04-12T21:42:58.529 12/4/20 21:42:58 12/4/20 21:42 0.000115741 2020-04-12T21:43:08.536 12/4/20 21:43:08 12/4/20 21:43 0.000115741 2020-04-12T21:43:18.597 12/4/20 21:43:18 12/4/20 21:43 0.000115741 2020-04-12T23:23:12.693 12/4/20 23:23:12 12/4/20 23:23 0.069375 2020-04-12T23:23:18.238 12/4/20 23:23:18 12/4/20 23:23 6.94444E-05 2020-04-12T23:23:22.407 12/4/20 23:23:22 12/4/20 23:23 4.62963E-05 2020-04-12T23:23:32.417 12/4/20 23:23:32 12/4/20 23:23 0.000115741 2020-04-12T23:23:42.430 12/4/20 23:23:42 12/4/20 23:23 0.000115741 2020-04-12T23:23:52.443 12/4/20 23:23:52 12/4/20 23:23 0.000115741 2020-04-12T23:24:02.461 12/4/20 23:24:02 12/4/20 23:24 0.000115741 2020-04-12T23:24:12.466 12/4/20 23:24:12 12/4/20 23:24 0.000115741 2020-04-13T01:24:29.401 13/4/20 1:24:29 13/4/20 1:24 0.083530093 2020-04-13T01:24:39.350 13/4/20 1:24:39 13/4/20 1:24 0.000115741 2020-04-13T01:24:49.364 13/4/20 1:24:49 13/4/20 1:24 0.000115741 2020-04-13T01:24:59.374 13/4/20 1:24:59 13/4/20 1:24 0.000115741 2020-04-13T01:25:09.649 13/4/20 1:25:09 13/4/20 1:25 0.000115741 2020-04-13T03:25:16.360 13/4/20 3:25:16 13/4/20 3:25 0.083414352 2020-04-13T03:25:26.290 13/4/20 3:25:26 13/4/20 3:25 0.000115741 2020-04-13T03:25:36.303 13/4/20 3:25:36 13/4/20 3:25 0.000115741 2020-04-13T03:25:46.712 13/4/20 3:25:46 13/4/20 3:25 0.000115741 2020-04-13T03:25:56.723 13/4/20 3:25:56 13/4/20 3:25 0.000115741 2020-04-13T03:26:06.736 13/4/20 3:26:06 13/4/20 3:26 0.000115741 2020-04-13T03:26:16.973 13/4/20 3:26:16 13/4/20 3:26 0.000115741 2020-04-13T05:26:23.315 13/4/20 5:26:23 13/4/20 5:26 0.083414352 2020-04-13T05:26:28.231 13/4/20 5:26:28 13/4/20 5:26 5.78704E-05 2020-04-13T05:26:33.096 13/4/20 5:26:33 13/4/20 5:26 5.78704E-05 2020-04-13T05:26:43.107 13/4/20 5:26:43 13/4/20 5:26 0.000115741 2020-04-13T05:26:53.120 13/4/20 5:26:53 13/4/20 5:26 0.000115741 2020-04-13T05:27:03.260 13/4/20 5:27:03 13/4/20 5:27 0.000115741 2020-04-13T06:12:14.073 13/4/20 6:12:14 13/4/20 6:12 0.031377315 2020-04-13T06:12:24.035 13/4/20 6:12:24 13/4/20 6:12 0.000115741 2020-04-13T06:12:34.043 13/4/20 6:12:34 13/4/20 6:12 0.000115741 2020-04-13T06:12:44.044 13/4/20 6:12:44 13/4/20 6:12 0.000115741 2020-04-13T06:12:54.050 13/4/20 6:12:54 13/4/20 6:12 0.000115741 2020-04-13T06:13:04.140 13/4/20 6:13:04 13/4/20 6:13 0.000115741

It would seem that the regular reporting of the LOCAL API takes a brake for an hour or two or 40 minutes. In spite of this issue, the app keeps running, whereas the cloud API issues used to stop the app! Does anybody get similar brakes in the log?

On 13 Apr 2020, at 3:14 am, mchenier <notifications@github.com mailto:notifications@github.com> wrote:

Im really glad it helps other people with other situation :)

Running it in docker should be really simple. May I ask why you prefer docker over just the npm start or even the release package ?

Docker in production environnement is really usefull but for the home app I didn't think it could improve the situation. Also since the cloud API have it's limit I don't think it would be a good idea to run this app in a app cloud service.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mchenier/tplink-hs110-pump-monitor/issues/2#issuecomment-612647617, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7U7MP2TSJIP32JOCQO6B3RMHZHZANCNFSM4LXDCQFA.

vdasilva commented 4 years ago

Hi mchenier, for me, I'm currently running the packaged application using the local API on my Netgear NAS (runs debian linux operating system). Since I'm already running docker on the same NAS (Pi-hole and github's jamesbarnett91/tplink-energy-monitor) it would just be nice to also run your app in the same eco system without having to script this with cron jobs etc etc. On a different topic and if you'll allow me, I'd like to contribute a timing chart diagram that shows how the timer settings and events take place (was not very clear for me without a bit of experimentation). Im in Australia so should be able to sketch it up today for your consideration into the readme. Cheers and hope you all had a good Easter!

vdasilva commented 4 years ago

Pump Notification.docx Pump Notification.xlsx

Gents, Have attached a simple timing diagram above - for me a picture always helps to see the problem better! (word file has images and the source Excel doco is also attached). The thing that was a bit counter-intuitive for me was the excessive idle delay - it seems to start counting down at the last known start operation, not when the pump is detected off. I indicated how I had assumed it worked in the timing diagram on the third sketch. Let me know if you have any questions and once again thanks for your app!

vdasilva commented 4 years ago

@gantonel, I've also done a quick analysis on polling interval since yesterday afternoon. Image attached shows how frequently the device is being polled and count of each interval. Certainly some outliers in there but the bulk pings are between 9 and 20 seconds as you can see.

cheers!

gantonel commented 4 years ago

Hi mchenier and vdasilva,

I understand that for the cloud API we can set the time between readings. I think I heard that the readings come without our intervention in the case of the local API. I do not understand how that happens, but it seemed curious that some intervals were multiple of sixty minutes and by chance the pump must have been activated in that hiatus.

I really wanted the email feature to be able to go downstairs and check that the pump is doing its job. Now that I have a new pump and a way to monitor it, emails are excellent and will be used indefinitely, but not critical. The emails for excessive activity will only be repeated after a long time and will not be triggered quickly, since the new pump has an internal floating switch which is unlikely to be stuck on. Also, the pumps have a cut off mechanism if they are overheating. Knowing that the pump has not started in 7 days might be useful and to be told again any more frequently than once a day might be an overkill unless it’s rainy season.

Now that I understand the the APIs a little better, I wonder wether rather than having readings as frequently as every 10 seconds, it might not be sufficient to ask once per day and get the usage statistics that are available ( for each day of the month, for each month of the year and for each year since activated).

I think with total power used on the log I will be very happy. There may be slight improvements to the naming and the description, but I have not checked the latest version thoroughly. I am very happy that several of my suggestions were incorporated in the code. Any tidying up is going to be easy, but I did not want to seem too pedantic. I am vary happy with mchenier’s brilliant work. I am an amateur programmer and would have got nowhere on my own. I don’t even know JS, but I managed to follow and modify some code. I am very happy with that.

I am not happy at all with the cloud API I am very happy with mchenier. Big applause for mchenier!

Regards

Giorgio

On 13 Apr 2020, at 11:55 am, vdasilva notifications@github.com wrote:

@gantonel https://github.com/gantonel, I've also done a quick analysis on polling interval since yesterday afternoon. Image attached shows how frequently the device is being polled and count of each interval. Certainly some outliers in there but the bulk pings are between 9 and 20 seconds as you can see.

https://user-images.githubusercontent.com/2160958/79085859-6c533d80-7d7d-11ea-98a8-0327525128ad.png cheers!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mchenier/tplink-hs110-pump-monitor/issues/2#issuecomment-612714061, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7U7MOELVFJHIFQNIPEU4LRMJWJLANCNFSM4LXDCQFA.

vdasilva commented 4 years ago

Dear @gantonel, I'm a programmer, but in a bit of a different branch. I'm a Control System Engineer mainly working with Industrial Automation (PLC programming, SCADA programming, industrial communications, etc). I am an amateur when it comes to JS / .Net / C / Github, [insert other languages here], etc, etc..

In my line of work it is always good practice to define your feature-set up front (software specification), but at the same time, to have enough forethought about how the system you design may be used/expanded in the future.

The way this normally pans out, is that you end up with software objectization and features/parameters to influence and modify the application's behaviour. For example, when I program an electrical motor interface in the PLC, it may need the ability to interface with many Vendor's motors (I don't want to create a different type of motor for every possible model and vendor combination!). Motors from different vendors will always have a common set of attributes, but inevitably, some may have more or less features that have to be switched in and out of the logic.

This same concept is kind of how I see @mchenier 's application to be used. In your use case, you may not care about notifications for a long period of time and that's your specific scenario. In my case, I DO want to know much sooner than that; guess what, we can both meet our requirements because there is a parameter that allows us to specify our time delay appropriately.

Maybe if you don't need to log at each of the 10 sec (or other random value!) that too may be able to be implemented with the use of a parameter to keep the application non-specific and flexible.

I'm currently investigating the option to modify the application's behaviour with an extra parameter so that I don't receive an email on each of the "start" and "stop" transitions - In my use-case, that's 4 emails per day when things are normal! I'm more concerned about the excessive run/idle alerts because my pool timer/relay has been 'sticky' lately. This resulted in the pump running flat-out for 7 days without anyone noticing! (damn pump too quiet!) However, if I did this, I would like to implement some sort of "heart-beat" email once per day that lets me know "system is healthy and communicating".

I would love to see the email and notification features in this application being merged with the GUI and graphs from @jamesbarnett91 's jamesbarnett91/tplink-energy-monitor - (that's where I originally found out about this project!)

Sorry for the rambling, just thought I'd add my 2cents... and also my applause for @mchenier cheers!

mchenier commented 4 years ago

Ok there is a lot of information in all that conversation.

Let me dress a list of what could be improved:

Add a docker file so you can build your image using your own config.json
Add a config so you can select what alerts you want.
Add an alert for no read for a period of time.

For the graphic part I tough it would be a little easier I tried some library that I found but it's really not trivial for me I have more study to do if I want to have a good result but I'm not sure if it's really worth it since using the graph.csv output I could get all the graph I wanted in Google Sheets. Btw JS is new to me too and my first language is french so if you see english errors it's normal but you can correct me :)

But if I have time I may invest more time in the graph part. But using jamesbarnett91/tplink-energy-monitor should be a better option for now.

The only time I had problem with the LAN api is that one night it just stopped. I had to reboot router and HS110 for the program to rediscover the HS110. So maybe more a hardware problem. But there was no alert for that and that could probably be improved too. I added it to my todo list.

Thanks for helping me make this app great for anyone who needs this.

mchenier commented 4 years ago

Ok I did some changes.

Docker option is now possible check the README
There is new config param: enableIdleAlert enableRunningAlert enableStartAlert enableStopAlert deviceIP

Device IP is to solve problem I had with the discovery of the api that stop working for no reason. I strongly recommend fixing the IP of your device with the DHCP of your router and using this feature to solve discovery problem. I still support discovery but I can't test it since it was not working when I tested it.

Now the waitBetweenRead is working for LAN and CLOUD api. I found the way to do it :)

Again I will gladly take your feedback to improve the app. The app.js is starting to get a little convoluted a refactor may come if we have to make more changes or add more features.

I'm thinking of removing some feature tell me your opinion about:

The cloudAPI
LAN discovery feature

mchenier / tplink-hs110-pump-monitor

improvement to log and inactivity notice #2

Thats the time between each poll to the power of the device in seconds

Filename of the log. It will be appended with a .log

Number of time in second the pump can be idle before you get an alert

Time in second between each of alert message in a period of alert threshold exceeded

Alert if the device running for more that threshold in second each time it starts

Time in second between each of alert message in a period of alert run_max exceeded

Use tplink-cloud-api if true otherwise use tplink-smarthome-api. Other parameters below only usefull for cloud API.

cloud and lan should be use

Usage