@harry-van-der-wolf Did you manage to solve the issue?
-
pimatic@0.9.47
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
At first I removed pimatic-sysinfo from
pimatic-app/node_modules
. Later I found also apimatic-app/.npm/pimatic-sysinfo
which I also removed, but that did only helped that the pimatic-sysinfo was correctly installed.But it still hangs upon starting. Now I switched the sysinfo plugin to false
{
“plugin”: “sysinfo”,
“active”: false
},Now pimatic starts, but I really want the sysinfo plugin.
The config for the systemsensor is
{ "id": "sysinfo", "name": "RPi3 sysinfo", "class": "SystemSensor", "attributes": [ { "name": "cpu" }, { "name": "dbSize", "interval": 300000 }, { "name": "temperature" }, { "name": "uptimeDHM", "interval": 120000 } ], "xAttributeOptions": [ { "name": "dbsize", "displaySparkline": false } ] },
I guess it hangs on
{ "name": "uptimeDHM", "interval": 120000 }
This is what I entered in my git repo as the uptime in seconds is totally useless after a few days, so I wanted it in DaysHoursMinutes. But that was already quite some time ago so I forgot.
When I remove that entry pimatic runs fine.
So it is obviously my own entry, but it would be more user-friendly if pimatic would display an error message like
You specified an unsupported value "uptimeDHM". pimatic will ignore it"
or something like that.I did that only Yesterday.
Tonight or tomorrow I will fork the pimatic-sysinfo again and do a pull request for a “systemUptimeDHM” and a “pimaticUptimeDHM”. -
I created a pull request that adds “systemUptimeDHM” and “pimaticUptimeDHM” that displays these uptimes as “days hours minutes”.
When less then an hour it only displays59 minutes
When less than a day it displays23 hours, 59 minutes
When more than a day it displays999 days, 23 hours, 59 minutes
in the config.json
{ "name": "systemUptimeDHM", "interval": 120000 }, { "name": "pimaticUptimeDHM", "interval": 120000 }
Example (just created from “fresh code” so pimatic uptime is extremely low)
Example 2:
-
@harry-van-der-wolf said in pimatic@0.9.47:
I created a pull request that adds “systemUptimeDHM” and “pimaticUptimeDHM” that displays these uptimes as “days hours minutes”.
Thank you very much for you PR! I am not sure, however, whether or not this is still required as there is the new
uptime
format as part of thedisplayFormat
xAttributeOptions
released with v0.9.14 of the front. For this reason I cherry picked your earlier PR (see my comments included in the PR). Note, beyond, I am planning to extend theuptime
format to let the user choose among several format options.See also:
- https://github.com/pimatic/pimatic-sysinfo/pull/13
- https://forum.pimatic.org/topic/4580/pimatic-mobile-frontend-0-9-14
- https://pimatic.teamemo.com/Advanced-Configuration/Attribute-Value-Formats
Please give it a try and let me know what you think. Nevertheless, I am open to accept your PR if that is the preferred solution.
When I remove that entry pimatic runs fine.
So it is obviously my own entry, but it would be more user-friendly if pimatic would display an error message like
You specified an unsupported value “uptimeDHM”. pimatic will ignore it"
or something like that.That’s odd. I’ll reproduce this case. If the error message indicates that “pimatic will ignore it”, it shall not cause pimatic to fail.
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
I’m glad your memory is better than mine. I could not even remember I already had provided a PR, even though it was from 2016.
I will look at the displayFormat and xAtrributeOptions.
I said "if pimatic would display an error message like
"You specified an unsupported value “uptimeDHM”. pimatic will ignore it"
There was no error message at all. Just a halt.So again: it would be nice if pimatic could display such an error message and then ignore the value.
-
@harry-van-der-wolf said in pimatic@0.9.47:
So again: it would be nice if pimatic could display such an error message and then ignore the value.
Thanks for the clarification on the absence of an error message as you said.
EDIT: Well, actually it does provide error messages!
15:50:03.883 [pimatic] Invalid config of device "sysinfo": Property "#/attributes/10/name" Should have enum cpu,usedMemory,usedMemoryPercent,freeMemory,freeMemoryPercent,processes,temperature,temperatureF,dbSize,diskUsagePercent,systemUptime,wifiSignalLevel,nwThroughputReceived,nwThroughputSent,pimaticRss,pimaticHeapUsed,pimaticHeapTotal,pimaticUptime, was: uptimeDHM in /attributes/10/name 15:50:03.913 [pimatic] Error loading device "sysinfo": name in [
The second message “Error loading device “sysinfo”: name in [”, however, is misleading and it causes the abortion. It is a runtime assertion in the code which I will replace with something more user-friendly and robust Btw, the assertion has been part of plugin code since the early beginnings.
EDIT 2: I also get a runtime exception at the end. I am wondering why this is not shown if the debug mode is disabled. The runtime exception is also misleading as following error in the exception hander chain
Fatal TypeError: Cannot read property 'pimaticUptime' of undefined at SystemSensor.Device.logAttributeError (C:\Users\marcus\Documents\Devel\PIDEV\node_modules\pimatic\lib\devices.coffee:246:36) at C:\Users\marcus\Documents\Devel\PIDEV\node_modules\pimatic\lib\devices.coffee:238:14 at tryCatcher (C:\Users\marcus\Documents\Devel\PIDEV\node_modules\pimatic\node_modules\bluebird\js\release\util.js:16:23) at Promise._settlePromiseFromHandler (C:\Users\marcus\Documents\Devel\PIDEV\node_modules\pimatic\node_modules\bluebird\js\release\promise.js:512:31) at Promise._settlePromise (C:\Users\marcus\Documents\Devel\PIDEV\node_modules\pimatic\node_modules\bluebird\js\release\promise.js:569:18) at Promise._settlePromise0 (C:\Users\marcus\Documents\Devel\PIDEV\node_modules\pimatic\node_modules\bluebird\js\release\promise.js:614:10) at Promise._settlePromises (C:\Users\marcus\Documents\Devel\PIDEV\node_modules\pimatic\node_modules\bluebird\js\release\promise.js:689:18) at Async._drainQueue (C:\Users\marcus\Documents\Devel\PIDEV\node_modules\pimatic\node_modules\bluebird\js\release\async.js:133:16) at Async._drainQueues (C:\Users\marcus\Documents\Devel\PIDEV\node_modules\pimatic\node_modules\bluebird\js\release\async.js:143:10) at Immediate.Async.drainQueues [as _onImmediate] (C:\Users\marcus\Documents\Devel\PIDEV\node_modules\pimatic\node_modules\bluebird\js\release\async.js:17:14) at processImmediate [as _immediateCallback] (timers.js:396:17) Process finished with exit code 2
EDIT 3: https://github.com/pimatic/pimatic-sysinfo/commit/fb3621d48e9cc19c672c38136af6ab71f9f42b0c
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
Thanks for Pimatic-Update - the process itself finished without problems but after restarting my Homdeduino is ‘dead’, means it’s not showing any values since…
Anybody else?Thanks in advance
-
@daddycool Did you check the log for error messages?
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
I had the same, just restarting the Pi solved it.
The port was not found… -
Serialport ACM0 is available, Homeduino reports ‘connected’ but the device isn’t showing any Data (No Data to Display) - what the heck…
edit: after several restarts of Rpi i got the error message:
error [pimatic-homeduino,HomeduinoDHTSensor]: Error getting attribute value dht.humidity: timeout_error 16:24:53error [pimatic-homeduino,HomeduinoDHTSensor]: Error getting attribute value dht.temperature: timeout_error