It looks like the file does not exist.

You showed the output of % ps aux | grep indiserver as

nafa 704 0.0 0.0 1836 1364 ? Ss févr.11 0:14 /usr/bin/indiserver -v indi_weatherradio >> /tmp/weatherradio_output.txt

$ sudo ls -l /tmp

$ ps aux | grep indiserver

$ sudo killall indiserver

$ indiserver -v indi_weatherradio > ~/logfile.txt

You may not have permission to view the file as your normal user.

Check the file is present with

% sudo ls -l /tmp/weatherradio_output.txt

% sudo tail /tmp/weatherradio_output.txt

Christophe, sorry to hear you are still having problems.

Did you check that something was being entered into the logfile with

$ tail -f /tmp/logfilename.txt

Use whatever path and name for (/tmp/logfile.txt) you called your logfile in your init script.

$ uptime

Here are two useful commands for you to try to monitor the situation

Check that indi is working
====================
$ ps aux | grep indiserver

You should see a line saying that indiserver is working, it will include the command including indi_weatherradio

Check the output of the logfile
=======================
$ tail -f /tmp/logfilename.txt

Instead of /tmp/logfilename.txt put in the path to the log file you used in the service script

This will show the output from the indiserver being put into the log file.
-f means follow and uou need to press ^C to get your command prompt back again.

Changing verbosity of indi
====================
You can increase the amount of information that indi outputs by adding extra v to the service file.

The service file above has one v as in

indiserver -v indi_weatherradio >> /tmp/outputfile.txt

indiserver -vv indi_weathreradio >> /tmp/outputfile.txt

If you use sudo you should be able to edit it, sudo makes you the super user.

If you tried sudo and it did not work please post the command you tried and the output you got back.

Read More...

Gain access to the box running the service, same as how you get to issue the commands to start and stop and get status for the service.

This is usually by either
- sitting at box with monitor and keyboard
- remote access over the network

At box
======
If you are using a keyboard and monitor at the computer running the service, start a terminal and edit the file with an editor, for instance
$ sudo nano /path/to/file

nano is a simple editor with prompts.

Make the changes and save the file
You can use any editor you like.

Remote access
=============
If you are remote from the computer running the service, use ssh (putty on windows) to get terminal access and proceed as before. You can also use a remote desktop instead of ssh if you have that set up.

Read More...

You launch the indi weatherradio service with the start command as you say.
You can also use a different syntax which gives the same result

e.g.
sudo systemctl stop indi-weatherradio.service
etc.

What you are typing is fine for controlling the service, you can use other methods but you only need one.

You need to get the output of the indiserver into a file to record what is happing in case of a crash.
To do this you need to edit the service script to redirect the output to a file.

First stop the service
Use a text editor to edit the service file /etc/systemd/system/indi-weatherradio.service

Change the exec start command from

ExecStart=/usr/bin/indiserver -v indi_weatherradio

ExecStart=/usr/bin/indiserver -v indi_weatherradio >> /tmp/weatherradio_output.txt

Regarding the tmp file
=================

If the file is not in /tmp the two main possibilites are
- you did not send it there when you started indiserver
- or the box where the indiserver was running has rebooted and /tmp has been emptied

I see that from your post above you are referring to the .service file
This is usually /etc/systemd/system/indi-weatherradio.service
I suppose this is where you are running indiserver from, this file will be run
at each system boot, if the service is enabled with

$ sudo systemctl enable indi-weatherradio.service
Or the service can be manually started with
$ sudo systemctl start indi-weatherradio.service

The indiserver can also be started in other ways
- from the terminal
- by another application (eg. kstars)

[Unit]
Description=INDI server for weather radio
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=root
ExecStart=/usr/bin/indiserver -v indi_weatherradio

[Install]
WantedBy=multi-user.target

ExecStart=/usr/bin/indiserver -v indi_weatherradio >> /tmp/weatherradio_output.txt

afa@NAFABox:~$ sudo systemctl start indi-weatherradio.service

afa@NAFABox:~$ tail -f /tmp/weatherradio_output.txt

If you started your indiserver with this command

/usr/bin/indiserver -v indi_weatherradio >> /tmp/indiserver.log

My investment has arrived a nice little Wemos No NAME D1 mini EUR 5.59, for pennies.
SSD1306 OLED 0.96", EUR 6.46.

I also discovered that you can use a slightly different oled begin call to use my old SH1106, but there are some artefacts.

Works perfectly with version 1.11 development with my hardware, (MLX90614, BME280, TSL2591, Davis anenometer, OLED)
Had to figure out that the pins have a different numbering to the arduino.

Wemos	Arduino	Connected
D0	16
D1	5	Yellow	SCL
D2	4	Green	SDA
D3	0	Purple	Anenometer Wind Speed
D4	2	
D5	14
D6	12
D7	13
D8	15	Grey	Button
Tx	1
Rx	3

I have unos and nanos and no Wemos D1, probably should invest I suppose.

I have been using the usb cable to power the microcontroller and communicate with it (two objectives with one cable).

I bought a longer USB cable which goes to the weather station's microcontroller.
This is commected back to a raspberry pi in a nicer weather proof environment which has AC power and an ethernet connection.

The wifi from the house does not reach the garden well where the pi is and is much less reliable than the cable usually.

I did set up the pi as a wifi hotspot so that the pi zero on the skycam can communicate back, so it would be easy to use this trick with a Wemos.

Still have to get power to the pizero and have used a portable power bank 5V (lasts the whole night) and 12V DC via buck converter to 5 V,
which I can power via a 12V battery or a 12V power supply running off the mains. Suppose I could power the Wemos in a similar fashion.

Bit old fashioned with the uno, I know. Suppose I should move with the times!

Read More...

Thanks for looking at that Wolfgang, you are very kind to do all that work.

Do you have an Uno to try with?

Like Mark I doubted my wiring so I had redone it several times before I looked at the code.

Yes, it definitely seems to be due to lack of memory on the UNO.

Options:
- Use bigger memory device, like your Wemos D1
- Limit sensors used
- Spread sensors over several microcontroller boards
- It may be possible to save some memory, so that lower powered devices can be used

The main memory hogs are the JSON calls that are copied back to a large long string. The JSON object is big and the string output to the serial port is larger.
In addition, reading about the String object suggests that it is somewhat notorious for giving memory problems.

I have been looking at the code and I am trying to get rid of the String objects and the ArduinoJSON library.

I see the same information is in three places - the basic structure storing the results for each sensor, the JSON object
and the large character buffer that is built up to send to the serial port.

I have written a shortJSON library to generate the JSON strings. I store these in a character buffer for each sensor (the memory is assigned at the start and continuously reused) I just allocated a little more characters than are needed to accomodate the sensor readings.
At the moment I call the function to update this character buffer every time
when the sensor is updated (I call it after the structure is updated eg mlxData.variable.= mlxreadCAll(object).
This is a little wasteful in processing time but the strings are just there and ready to go when they are requested.

These are just Serial.print(MLXstring); on the calls to w, p etc. from the serial console.

I have these working for davis, mlx, tsl and bme, no problem with funny output or memory shortage so far, so seems stable with less memory usage.

Before I move on to the other sensors I will see if I can get indi to talk to the new code.

I will upload the code to github so you can have a look at it.

Kind regards,

Adrian

Read More...

Of course the Wemos D1 mini (4Mb) pro (16Mb) is flush with memory compared to the Uno (32K flash and 2K SRAM)

So if a Wemos D1 mini pro is used there will be no shortage of ram compared to the UNO.

Read More...

Slight progress

There is a clue to setting the Static JsonDocument in the webpages

arduinojson.org/v6/assistant/

I set mine to 194 to allow for the JSON data and the strings
How to work this out on the fly for different sensor and outputs?

The main problem with the outputting is with serializeJsonPretty, this puts out a very long output with all those nice spaces and ^M at the end.
This seems to overrun the memory which is put into String result="";
I am not sure how the String object looks after its memory, or if you have to reserve memory for it yourself, and free it up afterwards etc.

You can specify how much to output in the serialze functions

I tried to output to a buffer and set a size limit on this

#include <ArduinoJson.h>
#define DESTBUFSIZE 320
char destBuf[DESTBUFSIZE];

#ifdef __arm__
// should use uinstd.h to define sbrk but Due causes a conflict
extern "C" char* sbrk(int incr);
#else  // __ARM__
extern char *__brkval;
#endif  // __arm__

int freeMemory() {
  char top;
#ifdef __arm__
  return &top - reinterpret_cast<char*>(sbrk(0));
#elif defined(CORE_TEENSY) || (ARDUINO > 103 && ARDUINO != 151)
  return &top - __brkval;
#else  // __arm__
  return __brkval ? &top - __brkval : &top - __malloc_heap_start;
#endif  // __arm__
}

void getSensorData(bool pretty) {

and

  int ret;

  destBuf[0] = 0;// Null terminator

  if (pretty)
    ret = serializeJsonPretty(weatherDoc, destBuf, DESTBUFSIZE);
  else
    ret = serializeJson(weatherDoc, destBuf, DESTBUFSIZE);

  Serial.print("ret :"); Serial.println(ret);
  Serial.print("Free Memory: "); Serial.println(freeMemory());
  Serial.print("DestBuf :"); Serial.println(destBuf);

    case 'w':
      //Serial.println(getSensorData(false));
      getSensorData(false);
      Serial.println(destBuf);
      break;
    case 'c':
      Serial.println(getCurrentConfig());
      break;
    case 'p':
      //Serial.println(getSensorData(true));
      getSensorData(true);
      Serial.println(destBuf);
      break;

Seems docSize needs to include the json part and the string storage.

github.com/bblanchon/ArduinoJson/issues/151

For my 313 byte serial output the doc size is calculated as 152 so it is unlikely to be able to hold the information.

Weather Radio V 1.10
152 <=== Serial.println(docSize)
{
  "Davis Anemometer": {
    "init": true,
    "direction": 87,
    "avg speed": 0,
    "min speed": 0,
    "max speed": 0,
    "rotations": 0
  },
  "BME280": {
    "init": true,
    "Temp": 14.42,
    "Pres": 1024.433,
    "Hum": 50.88184
  },
  "MLX90614": {
    "init": true,
    "T amb": 14.82999,
    "T obj": 14.19
  },
  "TSL2591":<Rni
  }
}