v246: Issue with TMPO [solved]

by gebhardm on

After upgrade to firmware v2.4.6 I recognized today that no more TMPO data was registered; the persisted information seems to have stopped at the time of the upgrade.
ps shows that the tmpo-daemon is running
684 flukso    5280 S    /usr/sbin/fluksod -u flukso
but there is no activity in the storage folders
/usr/share/tmpo/sensor/0
There is actually a difference to a backup I made prior to the update, but this "newer" content seems to stop at timestamp 1436876800 (14.07.2015 14:26:40) - no more readings persisted after this point in time... (luckily I have my parallel MQTT tracker running, so I know there were readings)
(also a reboot did not change this behavior - everything else seems to run smoothly)

‹ Query sensors (iPhone app) watthour of the night ›
gebhardm's picture
gebhardm |

May this be a user:group issue? The /usr/share/tmpo folder and its subfolders are owned by flukso:flukso, everything else is root:root?!

icarus75's picture
icarus75 |

I'll look into this later today. Make sure to keep your FLM online.

icarus75's picture
icarus75 |

Could you patch tmpod.lua with this commit? Let me know whether the patch fixes the issue at your side.

gebhardm's picture
gebhardm |

This one alone didn't do it, I had to change line 131 in the same manner...

  1.                 if tonumber(section) -- sensor entries only
  2.                 and params.enable
  3.                 and params.enable == 1

But now it seems to work again :-)

gebhardm's picture
gebhardm |

Hmm, it registered three MQTT messages and went silent again (also after full reboot) :-/

gebhardm's picture
gebhardm |

I tried by deleting the content of the /usr/share/tmpo/sensor/<sensor id>/0/8 folders, as they where empty prior to the patch, but this after reboot had also no effect - tmpod restart "works", but no readings are saved.

icarus75's picture
icarus75 |

Can you undo the change you made to line 131 and try again? Please note that it can take up to 256secs for a block8 to be written to flash.

gebhardm's picture
gebhardm |

Undone the line 131 change and restarted the tmpo-daemon; now there are indeed readings again; I'll keep watching for the night...

gebhardm's picture
gebhardm |

Seems solved - the "it can take up to 256secs" cured my errorenous gut feeling misbehaviour which is fed by keeping in parallel my store on second base ;-)
I hereby declare the issue closed :-)

For all others:

  1. Log into your FLM via ssh: ssh root@<your FLM IP address>
  2. Provide password (default: root)
  3. root@flukso:# cd /usr/sbin
  4. root@flukso:/usr/sbin# vi tmpod.lua
  5. Use arrow down key to go to line 154
  6. Go via right arrow key to the "1" - press i for <insert>
  7. Change the "1" to 1 using backspace and arrow keys (trust yourself) - it should read now:
  8.      and params.enable == 1
  9. Press ESC
  10. Press :
  11. Type wq to write and quit vi (lovely editor, isn't it?)
  12. At the command prompt type
  13. root@flukso:/usr/sbin# ps | grep tmpod
  14. root@flukso:/usr/sbin# kill <process id of  /usr/sbin/tmpod -u flukso>
  15. Type now at the prompt
  16. root@flukso:/usr/sbin# /usr/sbin/tmpod -u flukso
  17. to start the tmpo-daemon again.

That should fix it.

icarus75's picture
icarus75 |

Better still: I'll shortly release a 247 fixing this one.

gebhardm's picture
gebhardm |

Still registers readings, so everything fine for now :-)
By the way, my query script also works as a daemon, exactly like the tmpod - so https://github.com/gebhardm/flmlocal/blob/master/usr/sbin/queryd.lua may be an alternative to the tmpod-integration of a query functionality (and already available); a ln -s /usr/sbin/queryd /usr/sbin/luad makes it automatically startable, if you dare to integrate it into the startup routine...