Archived Forum

Radek 

I'm not really clued up enough to help in any depth but in the absence of those that can I thought it was at least worth you exploring the suggestions in the error message mentioned in your comments in the "EMONCMS: Allow New Input processes Feeds in MySQL engine as option from UI" thread

It would seem clearing the browser cache plays a part so have you tried switching to v8.4.0 and clearing the cache? if it is still an issue try "git checkout v8.3.6" from the emoncms folder to revert back to a known good version.

Paul, I think, I recognized potential issue. I have compared my working installation 8.0.8 with freezing 8.5 and I found difference in MAX / MIN function declaration. Look at /Modules/input/process_model.php and there is around row 550 definition of MAX and later MIN function. difference is in rows:

$feedtime = $this->getstartday($time_now);

$time_check = $this->getstartday($last_time);

In old version 8.0.8 are $feedtime and $time_check declared another way:

$feedtime = mktime(0, 0, 0, date("m",$time_now), date("d",$time_now), date("Y",$time_now));

$time_check = mktime(0, 0, 0, date("m",$last_time), date("d",$last_time), date("Y",$last_time));

When I use that old version, input and feed are not frozing now, when I create MAX or MIN feed. I think, that problem could be in definition of private function getstartday at the end of this file, but my knowledge of php is not strong enough to localize what exactly is wrong. So now Im testing 8.5 with old definition of MAX and MIN functions and we will see, how it works. But at least it is not freezing now.

Radek

Looking at github those changes have been in place since the getstartday() function was added for improved timezone support in May2014 (v8.2) so it's not likely to be that directly, however, March this year the getstartday() function was edited for the "Fix all Timezone issues. Plus merging with latest and minor bug fixing." so I suspect that may be closer to the root of the issue since those functions do work in v8.3.6 (emoncms.org current version).

But those changes are only present in v8.5 and extended so v8.4 should be ok, therefore my suggestion above still stand to determine if the issue is present in v8.4 or not.

Among the changes in the latest timezone revisions the way the offset is defined was changed and you may well find reselecting (select another and then change back) might help if you have carried over your settings from a v8.4 or earlier version. ( I assume you have backed up prior to starting the upgrades if not you probally should)

Paul

As I have new installation without historical data at my new VPS, I can try various scenarios without any worries. So now, I switched back to 8.4.0 and process_model.php file is now without modifications (getstartday() function acting). I cleared browser cache and restarted Apache. Created MAX and MIN feeds and it works. Now I will go forward again to 8.5 and to 8.5.1 XT and we will see, when that issue is going to appear (I hope :-)). At least we have a reference point now. Stay tuned.

Radek

Seems to be clear, Paul. Im switching between 8.4.0 (master) and 8.5.0 (v8.5). Clearing browser cache each time. No other changes. With 8.4 I can create MAX and MIN value and everything works fine. With 8.5, or MAX/MIN feeds created before in 8.4, or created now in 8.5, are freezing input update of ALL inputs/feeds. Only way how to keep MAX/MIN feeds alive under 8.5 is to modify process_model.php as described in above. Probably some bug between these two versions. 

For current 8.5+, replace :

     $last_time = strtotime($last['time']);

With :

     $last_time = $last['time'];

on the /Modules/input/process_model.php arrounf lines 610 and 619, if it works i will make a fix later as it's bad in other place.s

I confirm chaveiro, it works and MAX/MIN feeds are no freezing EMONCMS 8.5.1 XT more. But, there is another issue - Im unable to create Multigraph in 8.5.1 XT (there si no selection of feeds for multigraph available). It works in 8.4 and in 8.5, but not in 8.5.1 XT

Radek

Digging into this a bit more. The feed last times are currently saved as date strings in redis. The set_timevalue method converts unix time to date string and then after the get_timevalue is called the last time is usually converted back to unix time with strtotime(). This is a non ideal remnant of an earlier version of emoncms in which I wanted the meta data to be human readable in the mysql database.

The error with the min/max processes appear to be being caused by trying to call get_timevalue when the feed has no last value, i.e when the feed has just been created it has no last value, rather than returning a date string $last['time'] is just an empty string "".

I've added a fix to emoncms v8.5 where it now checks for this condition after the line:

$last_time = strtotime($last['time']);
if ($last['time']=="") $last_time = 0;

This fixes the problem for me and I've pushed this fix up to the v8.5 branch.

I have already removed the use of a date string for storing the last time in the low-write branch of emoncms, Im not sure why I didnt implement the same change in emoncms v8.5. I will look into it.
 

I've update emoncms v8.5 to use unix time instead of date strings for last time value and the latest update includes a bit of code that will convert existing last time meta data over from date string to unix time.

I've tested: log_to_feed, power_to_kwh, power_to_kwhd, kwh_to_kwhd, wh_accumulator, max, min, allow positive and allow negative. All appear to be working ok.

Trystan, I can confirm, that after pulling updated 8.5 it works fine (MAX/MIN feeds), Thanks for fixing this unpleasant bug!

Radek

Fixed on XT, merge waiting.

Can work now with mysql engine also if active on config.

Refactored some code from 8.5 -> Instead of if (!is_numeric($lastvalue['time'])) in feed_model.php i fixed the reason it may not be.
Also some minor fix on getstartday function on process_model.php