[ottorino]

The one with one orange socket. 2.1 right?

[ottorino]

No success here on MATE Mint

I get the same error as cuteboi
./osFWUpdater_x64: symbol lookup error: ./osFWUpdater_x64: undefined symbol: _ZN6QDebugD1Ev

I cannot recompile
I get the prompt after qmake but this what I get after “make”

g++ -c -m64 -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -o mainwindow.o mainwindow.cpp
In file included from /usr/include/qt4/QtGui/QComboBox:1:0,
from ui_mainwindow.h:16,
from mainwindow.cpp:2:
/usr/include/qt4/QtGui/qcombobox.h: In member function ‘void MainWindow::on_btnDetect_clicked()’:
/usr/include/qt4/QtGui/qcombobox.h:233:10: error: ‘void QComboBox::currentIndexChanged(int)’ is protected
void currentIndexChanged(int index);
^
mainwindow.cpp:51:66: error: within this context
ui->cmbDevice->currentIndexChanged(myHandler->curr_device);
^
make: *** [mainwindow.o] Errore 1

No matter if I run both commands as sudo

[ottorino]

I know. I will update ASAP, but have a look at this log.
This is the log after a reboot. The rain event (yesterday) seems to have lasted for 49710 days !!

Attachments:

1. 

   Schermata.png
   

[ottorino]

Hi Samer,
this really make sense.

I could have solved the issue simply resetting the unit, but in that case I would have missed the opportunity to share with the community what appear to my eyes a GREAT problem.

I will try again to update the firmware and let you know.

[ottorino]

Two updates

1) my system is a DIY kit and not a Pi one. Sorry for posting here

2) we had an heavy rain this afternoon. The rain sensor is working properly so the system alert me tha rain was detected

The program (5) is still in loop and the pot channel turns on and off continuously (ignore rain is on. The other channel do not turns on because of the ignore rain flag is off

[ottorino]

Here the configuration file. The system is now disabled, but as soon as I enable it, one channel start the loop again.

I’m not at home, so I cannot control the real situation.

PS It seems that json files are not allowed as attachments

Here the copied/pasted file

{“programs”:{“nprogs”:5,”nboards”:1,”mnp”:53,”pd”:[[1,128,4,1259,1439,120,30,2],[1,128,3,0,180,60,20,8],[1,127,0,1230,1350,120,60,4],[1,128,2,60,240,120,60,1],[1,127,0,130,490,120,20,148]]},”stations”:{“snames”:[“Pratino al sole”,”Pratino in ombra”,”Fasce laterali”,”Aiuola serra”,”Terrazza e vasi”,”S06″,”S07″,”pompa pratino”],”masop”:[7],”ignore_rain”:[16],”act_relay”:[0],”maxlen”:16},”options”:{“fwv”:209,”tz”:56,”ntp”:1,”dhcp”:1,”ip1″:192,”ip2″:168,”ip3″:1,”ip4″:22,”gw1″:192,”gw2″:168,”gw3″:1,”gw4″:1,”hp0″:80,”hp1″:0,”ar”:1,”ext”:0,”seq”:1,”sdt”:0,”mas”:8,”mton”:2,”mtof”:-3,”urs”:1,”rso”:0,”wl”:100,”stt”:10,”ipas”:0,”devid”:0,”con”:110,”lit”:100,”dim”:5,”rlp”:0,”ntp1″:204,”ntp2″:9,”ntp3″:54,”ntp4″:119,”reset”:0,”dexp”:0,”mexp”:5},”status”:[0,0,0,0,0,0,0,0],”settings”:{“devt”:1434003047,”nbrd”:1,”en”:1,”rd”:0,”rs”:0,”mm”:0,”rdst”:0,”loc”:”firenze, italia”,”sbits”:[0,0],”ps”:[[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0]],”lrun”:[4,5,7,1434003032],”rodur”:[0,0,0,0,20,0,0,0]}}

Attachments:

1. 

   program5.png
   

2. 

   Schermata-del-2015-06-11-080456.png
   

3. 

   Schermata-del-2015-06-11-080549.png
   

[ottorino]

What about adding the date/time of status change of the rain sensor in the upper red strip ??

Instead of reading “Rain detected”, one should read, say, Rain detected at xx:yy, oct 1, 2014.
I think it would be helpful.

Presently you can only acquire that information only when the results are written in the logs, i.e. when the sensor switch back to the dry condition.

[ottorino]

That’s true (with a magnifying glass !!).
The duration is 38 sec (0.63 min) but they are represented as close to 0.
When I toggle all the other stations off (see screenshot), I still see undetectable values near zero.
Is that expected ?

[ottorino]

In my case I can see logs as table but not as graph.
Only for station one: no matter how many others stations are toggled on/off (rain delay in tyhe screenshots)
The soil is wet in the morning, which is reassuring and most important.
Mobile and web app gave the same behaviuor, both at 1.2.2 version firmware 2.0.9

[ottorino]

This morning it happened again. On program 5, start time at 00:10 and stop time at 00:10.
I’ve tried to change the stop time back to 08:10 but on web interface (now at 1.2.0b) I cannot save the correct value: I entered the 08:10 in the stop field and saved but the 00:10 value was still there after re-entering the program. After this, it was not possible to save anything with the web interface; after changing the value and pressing “save”, the wait-I-m-processing symbol appears and remained there, hanging for some minutes. I tried this 2-3 times

I finally set the correct value by the mobile app (1.2.0).

The rest of the programs were not enabled and n° 5 was the only one active.

I’m sure I did not alter anything in the program 5. Being conscious that could be me/my gestures to cause the problem, I took extra care in observing my gestures and the behavior of program 5.

This time the OS was turned on and off many times, because I had to work on the electrical system of the garden.
I will try to turn it on and off again to see if I can reproduce the problem.

Edit
I’ve checked it again with mobile app: is back to 00:10.

[ottorino]

@rowan.g wrote:

Hi All,
I’ve searched around quite a bit for info on the SD card but I can’t seem to find answers.
Does the Opensprinkler 2.1u come with an SD card?

No. There’s the slot, but not the microcard. At least my specimen came without card.

What type of SD cards are supported? What role does the SD card play?

Do not know exactly. Microcards FAT32 formatted, if (my) memory serves.

Others may answer here

Is it required to power on and use the device or is it only there if you run out of space on the Atmega?

No, is not essential. My OS have been running a couple of months without card.

[ottorino]

I did the same on friday, and got no error whatsoever. (debian wheezy)
The new version asked me to perform again the bootloading procedure.
There I had some problems, but it was my fault.

I plugged the cable into the USB 2 socket on my laptop, since I had problems with 2.0.7 on USB 3.
viewtopic.php?f=2&t=758&start=10#p5275

Could be this the reason ?

[ottorino]

I’m checking the clock from time to time and this behaviour seems triggered by programs. I’ve never seen it without programs. But as we are approaching a wet season, I will keep an eye on the clock with disabled programs.

[ottorino]

I switched back to the classic interface and now I’m able to save the 08:10 value as stop. I will keep the classic interface as reference.

The two glasses were filled, but I can’t say whether is the result of one irrigation or more.

[ottorino]

You can touch the legend. It makes channels appear and disappear from the graph.

Welcome!!

[ottorino]

In the meanwhile I let all the fields as they are. I’m curious, so I will put a glass under some drippers. And tomorrow morning (CET) I will report the results.

[ottorino]

Worst than that.

I enter 08:10 in the stop field, save the program 5, see that the value is still 08:10, exit the programs page, re-enter into program page, re-open program 5 and find 00:10 in stop field back again !!

[ottorino]

In the afternoon I’ve removed the battery, to control its voltage (3.2 V, viewtopic.php?f=33&t=910#p6004).

And I’m sure that this morning the program 5 was from 00:10 to 08:10. I’ve round it back at 00:10 start and 00:10 stop.

I’m underlying because this morning I checked the program, and changed the restriction from “odd days” to “None”.
Since I doubt of me, myself, my gestures (:oops:), after saving the program I checked again the start/stop values.
I did it from the mobile app.

I will try to reproduce this behaviour, be quiet until then and finally I will let you know.

[ottorino]

3.2 V, apparently a good one.
But after placing the battery back ….. viewtopic.php?f=2&t=836#p5987

[ottorino]

I really do not know.
It’s always possible that I myself changed the settings unadvertedly.
I will take extra care when I will modify the programs

[ottorino]

I will check the battery voltage. Thanks
All the other details are written in the signature.

[ottorino]

This morning my pots were quite dry, so I opened the relevant program page.
I’ve found that the program start was at 00:10 (as scheduled/wanted) but the stop was inexplicably moved from 08:10 to 00:10. This was the reason of the dryness. Is this occurring only to me ?

[ottorino]

@salbahra wrote:

I think your asking two separate questions at the same time.

This was because I was confused myself !!
I assumed that the date was right.
Actually it was not.
I’ve keep checking it for one day and It was always wrong and weird.

Only after a reboot from remote, the problem disappeared.

I will check again the battery.
viewtopic.php?f=8&t=829#p5434
It’s improbable to find two bad batteries in a row, but not impossible.

[ottorino]

I’m travelling so I cannot check the sensor properties. But it must be a clock-related problem. Right now, 15:30 local time, the app report sept 09, 23:59 !!
I’ll keep checking the time on the app from remote.

Edit: definitely a clock problem. Local time 19:14, four hours later: and the app reports sept,10, 02:31. The NTP sync is enabled. Should I disable it ?

GMT is set to +2:00 as it ever was from the start.

[ottorino]

I think it’s correct to continue in this topic, the discussion that was started here
http://rayshobby.net/phpBB3/viewtopic.php?f=2&t=897&start=40#p5883

I’m aware of the limitations of OS(notPi) about the week.

Is it not possible to automatize the mail sending of the log, say weekly or every second day ?

[Author]

Posts