Archived Forum

What type of feed are you trying to create? If it's one of the new ones, PHPFINA etc., make sure you've run:

sudo mkdir /var/lib/phpfiwa
sudo mkdir /var/lib/phpfina
sudo mkdir /var/lib/phptimeseries

sudo chown www-data:root /var/lib/phpfiwa
sudo chown www-data:root /var/lib/phpfina
sudo chown www-data:root /var/lib/phptimeseries

I had similar errors creating some feed types until I'd done this (from the current v8 readme).

However, I have the same error if I try to create PHPTIMESTORE. I just fixed that by deducing

sudo chown www-data:root /var/lib/timestore/

You should be able to verify your issue by looking in /var/log/apache2/error.log and see if you can see things like this:

PHP Warning:  fopen(/var/lib/timestore/0000000000000045.tsdb): failed to open stream: Permission denied in /usr/share/emoncms/www/Modules/feed/engine/PHPTimestore.php

PHP Warning:  fopen(/var/lib/phpfiwa/38.meta): failed to open stream: No such file or directory in /usr/share/emoncms/www/Modules/feed/engine/PHPFiwa.php

Thanks Dave, that has got the feeds working again!

Do your realtime graphs still work?

Mine don't seem to be since the update.

Paul

Hi Paul,

Glad to be of help... realtime also looks broken to me :(

Sadly I know virtually nothing about visualisation / graphics.

I've just pushed up a fix for the realtime graphs. I will add a note to documentation about ensuring permissions are correct for timestore data dir.

That's helped Trystan, however I think that there is still something adrift.

When you look at a realtime graph, and select 30 minute view, no data nodes are shown for the previous 3 or 4 minutes, and you just get a straight line.

But if you then return to a 5 minute view of the same graph, you can see the data which was displayed as a line in the 30 minute view;

I've cleared the browser cache, but it re-occurs everytime you switch to a view of 15 minutes or longer. 

Paul

Thanks Paul, Il look into that.

I've also fixed now the divide by zero error on the other visualisations that used daily kwh/d data: zoom, stacked, stackedsolar & orderbars

For those who may be using the debian packaged version already, what's been fixed so far is included in version 8.0.1

I've got another feed-creation related issue. I can create feeds (choice of FINA, FIWA, and phptimeseries only), in the sense that they show up in the interface, have a lastvalue etc., but I can't view them in visualisations. 

When I visualise one of the new feeds, here's the result from apache's errorlog:

[Mon Mar 17 07:29:41 2014] [error] [client 192.168.1.8] PHP Warning:  
fopen(/var/lib/phpfiwa/53_1.dat): failed to open stream: No such file 
or directory in /usr/share/emoncms/www/Modules/feed/engine/PHPFiwa.php 
on line 352, referer: http://192.168.1.210/emoncms/vis/auto?feedid=53

[Mon Mar 17 07:29:41 2014] [error] [client 192.168.1.8] PHP Warning:  
fseek() expects parameter 1 to be resource, boolean given in 
/usr/share/emoncms/www/Modules/feed/engine/PHPFiwa.php on line 353, 
referer: http://192.168.1.210/emoncms/vis/auto?feedid=53

[Mon Mar 17 07:29:41 2014] [error] [client 192.168.1.8] PHP Warning:  
fread() expects parameter 1 to be resource, boolean given in 
/usr/share/emoncms/www/Modules/feed/engine/PHPFiwa.php on line 354, 
referer: http://192.168.1.210/emoncms/vis/auto?feedid=53

[Mon Mar 17 07:29:41 2014] [error] [client 192.168.1.8] PHP Warning:  
fclose() expects parameter 1 to be resource, boolean given in 
/usr/share/emoncms/www/Modules/feed/engine/PHPFiwa.php on line 355, 
referer: http://192.168.1.210/emoncms/vis/auto?feedid=53

And then on the filesystem:

pi@raspberrypi ~/tmp $ ls -al /var/lib/phpfiwa/53_1.dat
ls: cannot access /var/lib/phpfiwa/53_1.dat: No such file or directory
pi@raspberrypi ~/tmp $ ls -al /var/lib/phpfiwa/
total 40
drwxr-xr-x  2 www-data root     4096 Mar 17 07:12 .
drwxr-xr-x 49 root     root     4096 Mar 16 06:53 ..
-rw-r--r--  1 www-data www-data   36 Mar 16 06:57 44.meta
-rw-r--r--  1 www-data www-data   36 Mar 16 22:40 47.meta
-rw-r--r--  1 www-data www-data   36 Mar 16 22:41 48.meta
-rw-r--r--  1 www-data www-data   36 Mar 16 22:42 49.meta
-rw-r--r--  1 www-data www-data   36 Mar 16 22:44 50.meta
-rw-r--r--  1 www-data www-data   36 Mar 16 22:44 51.meta
-rw-r--r--  1 www-data www-data   36 Mar 16 22:46 52.meta
-rw-r--r--  1 www-data www-data   36 Mar 17 07:12 53.meta

So it looks like some part of creating / using these feeds isn't working, but I guess it's not a permissions issue, since the meta files are being created OK. Any thoughts?

Same result even if I chmod the directories to 777.

I'm not sure why there would be an issue reading the file with fopen (rb), but nothing in the logs from the update_layer function failing to fopen (c+)

Interestingly, I can create a PHPTIMESERIES which seems to write to disk (and my existing TIMESERIES / MYSQL feeds are working fine) but I can't necessarily visualise the PHPTIMESERIES feeds - they work in raw data but not in multigraph, for instance.

I think I might have to downgrade to v7 to set up a few more feeds, as I'm in the process of trying to commission a couple of new 5+ sensor emonTHs :\

Dave, on the inputs page, how is the 'Key' described, for the input that you wish to create a feed.
Is it a numerical value, incrementing with each input within the node?

ie, like this;

Paul

Yep - nodes and keys look normal. I'm trying to get log4php up and running so I can add a bit of debug.

Interestingly, while my chromebook doesn't offer me any "other..." feed types, chrome on my mac allows the option to create the old feed types, so I may be able to get by.

It hadn't occurred to me to just try manually posting things to the feed. When I do that, I can visualise the data I submitted on PHPFINA feeds (the only one I've tried) and it does create the expected .dat file

It seems then that when the input updates, this isn't passed on to PHPFINA feeds, but is to PHPTIMESERIES.

Aha. If I restart rfm12piphp... it looks happy. What a fail!

Hi.

I (at last) migrated to v8 (master).

Before trying new stuff (FIWA, redis,...), I'd like to reproduce my old setup, with only mySQL.

When creating a new feed, I'm not offered MYSQL, but only FIWA, FINA, VINA.

I set

$redis_enabled = false;

I didn't touch

$feed_settings = array(

        'creatable_engines'=>array('MYSQL','TIMESTORE','PHPTIMESERIES','GRAPHITE','PHPTIMESTORE'),

'timestore'=>array(
            'adminkey'=>"_TS_ADMINKEY_"
        ),

        'graphite'=>array(
            'port'=>0,
            'host'=>0
        ),

        // The default data directory is /var/lib/phpfiwa,phpfina,phptimeseries on windows or shared hosting you will likely need to specify a different data directory.
        // Make sure that emoncms has write permission's to the datadirectory folders

        'phpfiwa'=>array(
            //'datadir'=>'/home/username/emoncmsdata/phpfiwa/'
        ),
        'phpfina'=>array(
            //'datadir'=>'/home/username/emoncmsdata/phpfina/'
        ),
        'phptimeseries'=>array(
            //'datadir'=>'/home/username/emoncmsdata/phptimeseries/'
        )
    );

Should I do something specific ? Do I have to use FIWA, FINA, VINA ? What about old feeds ? They seem to work.

Other questions :

$enable_password_reset = _ENABLE_PASSWORD_RESET_;

What if I don't want that ? Should I write this ?

$enable_password_reset = _DISABLE_PASSWORD_RESET_;

And what about this ?

// Log4PHP configuration
    $log4php_configPath = '/etc/emoncms/emoncms_log4j.xml';

Isn't this specific to the .deb version ?

Thanks.

Hello Jerome, yes you can add the option to save to MYSQL by modifying the engines available property for the different input processors in: Modules/input/process_model.php. For example to enable MYSQL as an option for the power_to_kwhd input processor, change the line:

$list[5] = array(_("Power to kWh/d"),ProcessArg::FEEDID,"power_to_kwhd",1,DataType::DAILY,"Power",array(Engine::PHPFINA));

to:

$list[5] = array(_("Power to kWh/d"),ProcessArg::FEEDID,"power_to_kwhd",1,DataType::DAILY,"Power",array(Engine::PHPFINA,Engine::MYSQL));

$enable_password_reset should be set to false if you don't want it and true if you do. _DISABLE_PASSWORD_RESET_ is associated with the deb installer.

Dave (schism): is $log4php_configPath = '/etc/emoncms/emoncms_log4j.xml'; ignored on non debian systems?

Hi Trystan. Thank you for the answers.

I now understand a bit better how available feed engines are defined. I suppose I have no reason not to move on to PHPFINA, so I'll give it a try. I don't mind losing my old data, anyway, this is just a test setup. I just wanted to know where I was stepping in. Out of curiosity, is there a possible migration for people moving from MYSQL to anything else and wanting to keep their data ? Or more generally to change from an engine to another ?

And now, I also understand that all variables appearing with underscores are meant to be filled by the installation script when installing through apt (.deb). Perhaps the version in master, the one pulled from github, could be kept as it was for users configuring manually. I felt this was misleading.

Or if we don't want to maintain two versions, deal with merges and all, just add comments like

// To enable / disable
// $enable_password_reset = true
// $enable_password_reset = false
$enable_password_reset = _ENABLE_PASSWORD_RESET_;

(BTW, I noticed emails from me being marked as spam by gmail in a friend's mailbox, so you may not have seen my reply to your email request.)

The logging is available to git and apt installations alike, but only if you also install log4php and point the config file at a valid log configuration. It's not a dependency, so if you don't do this it will just be ignored (like redis, except you don't need to supply explicit true/false).

--

The difficulty with the config file placeholders in general is a question of maintenance responsibility:

We could have two config files, one held in emoncms/emoncms and the other in pkg-emoncms, but it would require someone from the emoncms repo to submit a pull request against pkg-emoncms to update the duplicate config file every time it changes.

My original thinking was that since /something/ needs to go in the bundled config file, it may as well be a placeholder that the debian installer can seek out, so long as it's also human readable. This means that I can run just a couple of dumb commands when emoncms 8.0.10 is released and it will immediately be available to apt installs, and we avoid tricky bugs where people have odd behaviour due to outdated / mismatched config.

It would be simple enough to have a section in the readme listing the different placeholders to be filled out. Alternatively we could revert it and try to maintain a duplicate in the other repo. I don't really mind trying either way.