forum

This topic has been touched on in one of the "release" threads. I think it is better to start a new thread per topic. Hope that is OK

I work with release 1.7.0-rc3, which I updated today with the develop branch for automation.
With the interface http://raspberry:8083/z-way-ha/ using - Preferences - Automation, I selected module Sensors value logging. Next choose the kWh sensor of my Fibaro plugin switch to be recorded as JSONFile.

I cannot find the file JSONFile anywhere. Not surprising as the log reports:
What is wrong? The earlier "release thread" had solution for this. I noticed the same lines have been drastically changed in the newer version I have now.

Change appears here

https://github.com/Z-Wave-Me/home-autom ... a967260057

This line appear wrong and always evaluate to TRUE (unless deviceType can be both types at the same time)
if ("sensorBinary" !== deviceType || "sensorMultilevel" !== deviceType)

Can you try changing it to
if ("sensorBinary" !== deviceType && "sensorMultilevel" !== deviceType)

Edit,

The stop method also appears to be broken and requires the following line added (unless self should be set to something else!)

var self = this;

@n0ahg: thanks, fixed this too.

No problem, I wasn't sure if there was a reason the variable called 'self' existed or if was was simply a 'cut and paste' remnant. We've all been there and done that :->

Please can you confirm if there is still an issue or not with line 38 in the same file always evaluating to true?

I've can confirm that 1.7.0 release (and 1.7.1-rc1) still has this issue with the SensorValueLogging module and making the change below resolves the issue

(changing line 38)

if ("sensorBinary" !== deviceType || "sensorMultilevel" !== deviceType)

to

if ("sensorBinary" !== deviceType && "sensorMultilevel" !== deviceType)

n0ahg wrote:if ("sensorBinary" !== deviceType && "sensorMultilevel" !== deviceType)

Got it working with this little patch. The resulting file is stored under
automation\storage\SensorValueLogging...
First reading returns the correct value of 0.12 for the device: Thanks for your efforts

indeed

I've noticed something else weird, Using 1.7.0 release with the fix to SensorValueLogging above.

If I create a OpenWeather module and set a up a SensorValueLogging module to save it's values I see the following error in the log file only if it is enable as z-way service is started

[2014-05-23 17:57:52.133] Notification: error (core): Can not init module SensorValueLogging: TypeError: Cannot read property 'get' of undefined
[2014-05-23 17:57:52.260] TypeError: Cannot read property 'get' of undefined
at SensorValueLogging.init (automation/modules/SensorValueLogging/index.js:35:28)
at AutomationController.instantiateModule (automation/classes/AutomationController.js:224:22)
at automation/classes/AutomationController.js:251:18
at Array.forEach (native)
at AutomationController.instantiateModules (automation/classes/AutomationController.js:250:24)
at AutomationController.start (automation/classes/AutomationController.js:72:10)
at automation/main.js:127:16

If the SensorValueLogging module is disabled and I start the service and then enable the SensorValueLogging module I don't see an error. Is the initialisation path different if a module is loaded at service startup compared to starting later?

Edit, Upon further investigation it looks like the OpenWeather module vDev isn't created in the init method and therefore doesn't exist until the first time the fetchWeather method is called whereas other modules (such as RGB) create the vDev in the init method. Also it looks like the SensorValueLogging module is created before the OpenWeather module it depends on. I'm trying to get my head around the code

You caught a good one

OpenWeather indeed creates the vDev only after fetching the data. This can be changed, but the main idea was not to have fake data until we fetch the real one (otherwise listeners will receive a change of level of the sensor from fake value to the correct one). How to overcome this? Don't know...

This is indeed a problem if logics will be used based on this widget - no way to bind to it until it is loaded.... May be a good idea to remember it's last state and start from it. Or accept that first value after boot up can be wrong.

But why do you need to log OpenWeather data if it is available online?

Mainly I'm just testing the different modules with each other

I agree with the reasoning and I think the best solution would be to save the state when retrieved from OpenWeather and if the service is restated for some reason then initialise the state of the OpenWeather module to the last known good values.