@asetyde
Regarding not being able to delete all loggers, the workaround to this, for now, is to instead of deleting the loggers, just edit it and change it to enabled = false. That will give the same result.
1 Like
Ok but consider delete can be disabled
@asetyde It sounds like your device stopped logging data for that entry on the 28th of march?
So your issue may not be related to the issue that @plord is seeing.
And no, the alerts you show in the screenshot is likely not related the the issues you are seeing.
What is the details of the other alert you have? - does it match the logger that you show in the screenshot?
Best regards
/Malte
1 Like
No alerts is not linked to my issues of loggers , I can’t clean alerts I notice you . my alerts I think is old error of unit in my library
@Malte I don’t know is linked to recent update, but I reset timer of power settings and now loggers and autopi not wake … never I use car … 
Voltage is ok, I see log events but nothing I see … (I put all verbose but o see nothing)
Hi guys
We pushed a minor bugfix release that should fix the issues you have been seeing where the device will stop logging.
Core
- Fix for BEV’s: Do not break OBD connection when unable to load standard OBD-II commands
Best regards
/Malte
1 Like
Okay, then it can just be ignored.
Can you elaborate on the other issue?
When you say power settings, you mean the advanced settings for the device right?
The device should wake up every few hours, and then go back to sleep after the inactivity_timer (default 5 minutes).
But no data is logged or?
It might be fixed in the most recent version (the one we just pushed 5 minutes ago), can you test that?
Best regards
/Malte
I’ve tried to reboot manually cut off, or turn on / off car many times …
but logger not write and update not load …
and now ? how can I do =(
not change no new update about autopi activity
errors :
Hi
The first error you receive when attempting to update the device is likely just because it is not ready to run the update. It can only run one state at a time, and when the device boots up, it will run a “startup”-state, so if you attempt to run the update while that is still running, it will not run the update and instead reply with the error message that you are seeing.
Can you try running the update again after waiting for a few minutes?
I will look into the other issue that you are seeing.
Is it possible for you to send the log file?
At first it would be interesting just to see the output of the last_errors command.
minionutil.last_errors
Best regards
/Malte
about system I’m confused , you see before green world to indicate connection , but after says a days ago , confirmed from logs
To get the logs, your device will need to be online, so that’s probably the reason the command fails.
Has the device not been online since yesterday?
Best regards
/Malte
seems yes , but as I say before, I reset power, I turn on car and turn off … device seems not reply
and now how can I do ?
There is a few ways to figure out what is going on.
At first you can try to leave it powered on for a while, because maybe it failed a step while updating, and if that’s the case, it will automatically retry the update, and usually it will fix itself.
If it has been a while and it still does not work, you can go through the following steps to diagnose the issue further.
-
Check if the sim card has any data left.
No data = no connection to the cloud. -
Check if the green light comes on.
If it does not light up when powered up, it could be an issue with the SD card.
NOTE: It can be quite difficult to see the light. -
Is the autopi hotspot accessible?
If the hotspot it available, then the device is running, but something could still be interfering with it’s ability to connect to the cloud. -
Is the device seen as online on my.autopi.io?
If none of the above fixed the issue, the usual way to debug this, is to get access to the logs in the device.
If you can connect to the hotspot of the device, then it can be retrieved that way. If not, you may need to either connect a screen and keyboard to the device, or take out the SD card and insert it into a linux pc to browse the files and see the logs (linux because windows can not mount the primary EXT4 rootfs filesystem).
Best regards
/Malte
Working again for me.
Last today update work well
Also good news with real time SoC !
Just need to refresh but real-time.
3 Likes
1 /2 /3 is ok
4 Not (says 2 days ago online )
terminal not work propely
do you ve and address to send logs files on /var/logs/ ?
At now , my autopi not work with 4g sim , sim is working and has data .
i falsi sd but nothing work … I think there are something I not understand
Hi Alexandro
Can you try running the commands from the troubleshooting guide? and send me the output?
You can send it in a zip file to malte@autopi.io
Also, I have to mention this, are you sure the SIM card is oriented the right way?
Image taken from https://www.autopi.io/getting-started
Best regards
/Malte
Having the same issues as Alexandro.
SIM is 100% correctly oriented, i have 4G, i have internet connectivity, i can use it as a hotspot just fine.
It just seems to have no connectivity to the cloud.
The first time this happened was out of the box, as soon as i first installed it. I believed back then it was due to update that kept getting interrupted by the sleep. It eventually updated, and became accessible from the cloud after another reboot.
I left it in the parked car, with no modem hibernation overnight, so i can wake it up via SMS. It ate through the battery in 16 hours (from 12.6+V to 12.2V) just from the interval wakeups and the semi-active modem, went into hibernation, and now it’s back to cloud not seeing it at all.
I let it go to sleep, i drove the car around for a few hours, i left the car parked and on for a while - nothing. Each time it’d go to sleep, i’d wake it up with an SMS or by power cycling the car, i’d verify it has 4G connectivity (it did every time), and each time - no communication with the cloud.
Another interesting thing… This is the last entry in the event log:
yet this is what the power status pane says:
Emphasis on the selected text.
I’ve extracted the var/log folder from the Autopi.
I can upload it somewhere if that’d help in debugging…
There’s quite a few exceptions and errors in the minion log, no clue which of them are expected and which of them are not.
This seems to be the point where things started going south…
2019-04-11 19:18:53,984 [cloud_cache :184 ][WARNING ][785] Temporarily unable to upload batch with 195 entries from queue 'pend': ('Connection aborted.', BadStatusLine("''",))
2019-04-11 19:18:57,600 [messaging :232 ][ERROR ][783] Recurring exception (207 times) in worker thread 'readout_1sec' while running workflow for message: {'filter': 'alternating_readout', 'handler': 'query', 'returner': 'cloud', 'args': ['RPM'], 'kwargs': {'protocol': 'auto', 'force': True, 'verify': True}}
2019-04-11 19:19:00,337 [salt.pillar :116 ][ERROR ][385] Exception getting pillar:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/salt/pillar/__init__.py", line 113, in compile_pillar
dictkey='pillar',
File "/usr/lib/python2.7/dist-packages/tornado/gen.py", line 1015, in run
value = future.result()
File "/usr/lib/python2.7/dist-packages/tornado/concurrent.py", line 237, in result
raise_exc_info(self._exc_info)
File "/usr/lib/python2.7/dist-packages/tornado/gen.py", line 1021, in run
yielded = self.gen.throw(*exc_info)
File "/usr/lib/python2.7/dist-packages/salt/transport/zeromq.py", line 188, in
crypted_transfer_decode_dictentry
tries=tries,
File "/usr/lib/python2.7/dist-packages/tornado/gen.py", line 1015, in run
value = future.result()
File "/usr/lib/python2.7/dist-packages/tornado/concurrent.py", line 237, in result
raise_exc_info(self._exc_info)
File "<string>", line 3, in raise_exc_info
SaltReqTimeoutError: Message timed out
2019-04-11 19:19:00,400 [salt.minion :901 ][ERROR ][385] Error while bringing up minion for multi-master. Is master at hub01.autopi.io responding?
(i omitted some seemingly irrelevant log entries - “unable to determine GNSS location”, RPM missing etc.)
From the above, it seems like minion can’t contact salt master, even though 4G is up and running and otherwise working fine. NTP works fine too, i can see it syncing with 81.7.4.128:123 in the logs.
So my thoughts are:
- either minion is borked, or
- hub01.autopi.io is borked, or
- domain name resolution is borked, or
- something’s wrong with the iptables config and salt ports are blocked.
I’ve never worked with salt stack, though, so… no clue.
Edit: As an unrelated sidenote, I’ve just noticed hub01.autopi.io runs on Linode. I’d strongly recommend moving away to a more serious VPS provider, or bare metal. The company i work for used to run on Linode as well. We eventually bailed on them after years of unexpected downtimes due to their incompetence, issues with noisy neighbours, issues with their (physical) networking, week-long ping-pong games with support where they wouldn’t admit for days that they were wrong, when they were clearly in the wrong, etc. Honestly, save your nerves and hair - switch to something else 
1 Like