Another strange behavior ...
-
- Posts: 57
- Joined: Fri Mar 17, 2023 9:45 am
Another strange behavior ...
Suddenly stops Automagically and will not deliver any data. Nor to Xively or in the Signal trace. If I make a turn off and a turn on in Signal trace it will NOT update the tracking. This happens with no regularity. First I see it in Xively, the graph i just flat with no changing. If I connect with Putty, the Pi will respons on commands. The image is a clean image from the Wiki with the recommended updates. Size of SD card = 8Gb.
Any idea whats going wrong? Automagically? Pi? Anybody else having same problem?
To get it work again, I must reboot the Pi.
/misterleffe
Any idea whats going wrong? Automagically? Pi? Anybody else having same problem?
To get it work again, I must reboot the Pi.
/misterleffe
Re: Another strange behavior ...
From time to time i have experienced that the tellstick duo is stopping to deliver any inputs but it still works to send commands. This has been observed by me on Linux in general (not only automagically).
Anyone with similar observations?
Anyone with similar observations?
My home automation software: Automagically @ Raspberry Pi http://automagically.weebly.com
Re: Another strange behavior ...
This is the same behavior I mentioned in a parallel thread. My system stabilized by disabling live and has now been up an feeding Xively for more than 10 days. Can you try to disable live and see if it gets better?
Is may be possible to check the condition David mentions by tdtool -l
If you do this a few times for a number of minutes you can see if telldus daemon is to blame, your sensors should change.
Instead of reboot, this works for me:
Marcus
Is may be possible to check the condition David mentions by tdtool -l
If you do this a few times for a number of minutes you can see if telldus daemon is to blame, your sensors should change.
Instead of reboot, this works for me:
Code: Select all
sudo service automagically stop
sudo service automatically start
Re: Another strange behavior ...
Does sounds a little bit like this issue, doesn't it ?
http://www.switchking.se/forum/viewtopi ... =10&t=1527
http://www.switchking.se/forum/viewtopi ... =10&t=1527
-
- Posts: 57
- Joined: Fri Mar 17, 2023 9:45 am
Re: Another strange behavior ...
Ok Marcus, to stop/start Automagically will make no difference. Telldus Live is disabled and make no difference. So I made an own solution... Don't know for how long it will last, but so far so good.KHolm wrote:This is the same behavior I mentioned in a parallel thread. My system stabilized by disabling live and has now been up an feeding Xively for more than 10 days. Can you try to disable live and see if it gets better?
Is may be possible to check the condition David mentions by tdtool -l
If you do this a few times for a number of minutes you can see if telldus daemon is to blame, your sensors should change.
Instead of reboot, this works for me:
MarcusCode: Select all
sudo service automagically stop sudo service automatically start
I took one of mine "Clean" images and started from that point. From now I start to fill Automagically slow, with 5 tempsensors and live energy metering. Feed it all to Xively and it's coming up nicely there. Further on, I will complete with your energy calculations and I will also give the Googlespread a chance. All these facts, will not explain the odd behavior of the clean image from you Marcus... Seems very strange. Maybe Automagically "has a lot to do" and go into some kind of cycle?
But there is another thing that I'm not complete familiar with ...
I had it in anotehr topic and it's about calculations. This is what I want to do (because I have TO_MANY_LOST_PACKAGES from time to time):
1. Add all TO_MANY_LOST_PACKAGES in a variable and feed Xively
2. Timestamp for the last TO_MANY_LOST_PACKAGES
/misterleffe
Re: Another strange behavior ...
I did not fully understand if you had overcome with a fresh image or not.
I cannot recommend googlespread, underlying components are not stable an google spread is not ready for these volumes of data.
To count too many, follow the previous instructions but use other variables an transforms.
I don't think there is a way to pick up the time for the too many lost packages.
/Marcus
I cannot recommend googlespread, underlying components are not stable an google spread is not ready for these volumes of data.
To count too many, follow the previous instructions but use other variables an transforms.
I don't think there is a way to pick up the time for the too many lost packages.
/Marcus
-
- Posts: 57
- Joined: Fri Mar 17, 2023 9:45 am
Re: Another strange behavior ...
As I wrote earlier, the mentioned problems came with when I installed your clean torrent-imgage. Seems very strange ...
Now I'm running a, from scratch, clean image of my own. I've 6 tempsensors, live energy metering, 2 devices (just on/off). Beside these, I have statistics for TO_MANY_LOST_PACKAGES.
For this a made a variable (in Core) and then in Store global variable I have Pattern to match: TO_MANY_LOST_PACKAGES. In Store this constant instead ... set to 1.
I also have Store global variable Pattern to match: OK. In Store this constant instead ... set to 0. Both will update the same variable made in Core.
Both is tapped at Pattern is a regular expression. These will now react on TO_MANY_LOST_PACKAGES (=1) or OK (=0). This will feed Xively and give a graph with 2 modes, 1 and 0. On the timeline I can now see when the change came.
/misterleffe
Now I'm running a, from scratch, clean image of my own. I've 6 tempsensors, live energy metering, 2 devices (just on/off). Beside these, I have statistics for TO_MANY_LOST_PACKAGES.
For this a made a variable (in Core) and then in Store global variable I have Pattern to match: TO_MANY_LOST_PACKAGES. In Store this constant instead ... set to 1.
I also have Store global variable Pattern to match: OK. In Store this constant instead ... set to 0. Both will update the same variable made in Core.
Both is tapped at Pattern is a regular expression. These will now react on TO_MANY_LOST_PACKAGES (=1) or OK (=0). This will feed Xively and give a graph with 2 modes, 1 and 0. On the timeline I can now see when the change came.
/misterleffe
Re: Another strange behavior ...
misterleffe wrote:As I wrote earlier, the mentioned problems came with when I installed your clean torrent-imgage. Seems very strange ...
![Bang Head :banghead:](./images/smilies/icon_banghead.gif)
http://developer.telldus.com/blog/2013/ ... .1.2_beta8
To help you continue to debug your Wireless Energy Meter signal-strength problem, I created a new version of the Wireless Energy Meter (0.9) that can log measurements to a CSV file.The file will end up in ~/source/automagically/logs.
For this I added three new configuration items: Default they are compatible with a Swedish Excel that uses ";" as separator and "," as comma. For English Excel, I think it should be "," and ".".
Format is: Status, Timestamp, SequenceNo, Energy, Pmom, Lost Packages
Here's an output:
Code: Select all
$ cat wem.csv
OK;1395518502,537537;98;255,0;15,3;1
OK;1395518562,537586;99;189,0;11,34;0
OK;1395518570,534564;0;380,0;171,06462;1
TO_MANY_LOST_PACKAGES
OK;1395518579,728213;0;380,0;171,06462;1
OK;1395518587,725205;1;138,0;62,12347;0
A warning though; if you leave it on it will fill your "disk" and possibly degrade performance of Automagically. I used append write method hoping to minimize the effect.
/Marcus
- Attachments
-
- wem_ver_0.9.zip
- (4.27 KiB) Downloaded 554 times
Last edited by KHolm on Sun Mar 23, 2014 11:04 am, edited 1 time in total.
Re: Another strange behavior ...
Mrleffe, have you updated your Tellstick to latest firmware version?
/Marcus
/Marcus
-
- Posts: 57
- Joined: Fri Mar 17, 2023 9:45 am
Re: Another strange behavior ...
Yes, it's updated with latest firmware. It was done a week ago.KHolm wrote:Mrleffe, have you updated your Tellstick to latest firmware version?
/Marcus
Marcus, I will say thank you, for your efforts for helping me. I haven't upgraded wem to 0.9 yet, but I will. Today I have been at "Trandansen" and made a lot of shots with my camera. Now when I have a look at my photos, I realize that is very hard to make good bird photos! But this was out of topic ...
I leave a report when wem 0.9 has been up for some time.
I noticed that in the picture you attached, the Manual Mode was set to True. Also you have the time set to False for Human reading. Should it be like that when logging to CSV file?
/misterleffe
Re: Another strange behavior ...
Do not use manual mode; that is only used when I need to simulate special behavior such as TO_MANY_LOST_PACKAGES in the basic test.If you enable Manual Mode, wem.py will not report TO_MANY_LOST_PACKAGES at all since it is no longer handling timeouts while waiting for the Wireless Energy Meter to report. A timeout will instead triggered by sending a special signal to the plugin.misterleffe wrote: I noticed that in the picture you attached, the Manual Mode was set to True. Also you have the time set to False for Human reading. Should it be like that when logging to CSV file?
"Human readable" is totally up to you. It's easier to do calculations when having timestamp in EPOCH, but easier to read if regular time.
/Marcus
-
- Posts: 57
- Joined: Fri Mar 17, 2023 9:45 am
Re: Another strange behavior ...
I don't know, but something is going wrong with the latest wem 0.9 ... This is what I did:
1. Installed a fresh "clean" image of my own.
2. After a "cold" reboot, with winSCP, I copied the wem.py (ver. 09) to the plugin directory.
3. New "Cold" reboot and when Pi was responding again I went to point 4
4. In System settings I can ONLY find 4 wem-parameters! ApiKey/Enabled/FeedID and Interval.
If I'm right, there should be 9 parameters for the wem plugin after the installation of version 0.9?
Automagically will also NOT respond e.g. when trying to make changes in the System settings.
Am I doing something wrong when copying the wem.py file to the plugin directory? Exactly as described, I did for version 0.8 of the wem plugin and there wasn't any issues at that time.
/misterleffe
1. Installed a fresh "clean" image of my own.
2. After a "cold" reboot, with winSCP, I copied the wem.py (ver. 09) to the plugin directory.
3. New "Cold" reboot and when Pi was responding again I went to point 4
4. In System settings I can ONLY find 4 wem-parameters! ApiKey/Enabled/FeedID and Interval.
If I'm right, there should be 9 parameters for the wem plugin after the installation of version 0.9?
Automagically will also NOT respond e.g. when trying to make changes in the System settings.
Am I doing something wrong when copying the wem.py file to the plugin directory? Exactly as described, I did for version 0.8 of the wem plugin and there wasn't any issues at that time.
/misterleffe
Re: Another strange behavior ...
EDIT: web ==> wem
Went to my Pi currently using wem.py version 0.6 and did exactly this:
I have no problems and all new configuration items shows up and when LogToFile is enabled. I get actual content to the file:
Nothing is wrong with version 0.9 as far as I can tell.
Did you remove the wem.pyc before installing the new version?
You have reported problems with saving system settings before - did it work prior to installing version 0.9?
Are you sure your SD card works as it should? No broken sectors or so - have you tried with another as I previously recommended.
I cannot reproduce the faults you report, which for me means you have something that might not be a software issue.
btw: Why to you keep on rebooting, just stop and start the service as shown above; will save you quite some time.
/Marcus
Went to my Pi currently using wem.py version 0.6 and did exactly this:
Code: Select all
$ cd ~/downloads
$ wget http://www.telldus.com/forum/download/file.php?id=458 -O wem_ver_0.9.zip
$ cd ~/source/automagically/site/plugins/
$ sudo service automagically stop
$ sudo rm wem.py*
$ unzip ~/downloads/wem_ver_0.9.zip
$ sudo service automagically start
Code: Select all
$ cd source/automagically/logs/
$ cat cat wem.csv
OK;1395679075,892653;69;10,2;0,68651;0
OK;1395679129,400783;70;10,2;0,68881;1
OK;1395679182,917674;71;10,0;0,67019;0
OK;1395679236,436409;72;10,2;0,68611;0
OK;1395679289,897141;73;11,3;0,76093;0
$
Did you remove the wem.pyc before installing the new version?
You have reported problems with saving system settings before - did it work prior to installing version 0.9?
Are you sure your SD card works as it should? No broken sectors or so - have you tried with another as I previously recommended.
I cannot reproduce the faults you report, which for me means you have something that might not be a software issue.
btw: Why to you keep on rebooting, just stop and start the service as shown above; will save you quite some time.
/Marcus
Last edited by KHolm on Tue Mar 25, 2014 10:37 am, edited 1 time in total.
-
- Posts: 57
- Joined: Fri Mar 17, 2023 9:45 am
Re: Another strange behavior ...
Sorry Marcus with all my troubles ... In some way it ends up in my poor knowledge of Linux I think.
No, I didn't remove the wem.pyc when I copied the new ver. 0.9 to the plugin directory. I think you mean I should do that? So, what does the .pyc file do? Does the versions has its own .pyc file?
I will give it a new chance and remove the .pyc file and copy the 0.9 version. Is that ok?
/misterleffe
No, I didn't remove the wem.pyc when I copied the new ver. 0.9 to the plugin directory. I think you mean I should do that? So, what does the .pyc file do? Does the versions has its own .pyc file?
I will give it a new chance and remove the .pyc file and copy the 0.9 version. Is that ok?
/misterleffe
Re: Another strange behavior ...
EDIT: web ==> wem
Do exactly as I did above and it should work. It'll download the right version in the right way.
Note that I remove wem.py* which means I remove both wem.py and wem.pyc.
And yes, I recommend to remove pyc files when replacing py files. Should not be needed, but by removing the compiled byte code you are sure the old is gone.
Marcus
Do exactly as I did above and it should work. It'll download the right version in the right way.
Note that I remove wem.py* which means I remove both wem.py and wem.pyc.
And yes, I recommend to remove pyc files when replacing py files. Should not be needed, but by removing the compiled byte code you are sure the old is gone.
Marcus
Last edited by KHolm on Tue Mar 25, 2014 10:38 am, edited 1 time in total.