Not sure what might have caused this but I have had the ICC pi running for a few days now without problems but last night at some point overnight it stopped processing. It was set to change from grid to solar this morning but did not and it was not reading feeds although the threads seemed to be OK. I had to restart the pi to get it working again. On restart there is an error that seems to be a DB error from the message (in image).

Also, it's not clear how it processes the different power outputs. I have the BMV connected as well as the inverters but it reads "grid power" total as a sum of solar generation and battery watts output to the load, which is incorrect (please see screenshot). At the time grid power was only supplying the load and not charging the batteries but it shows over 2kw from grid. What was really happening was 600W from grid and 1400W from solar charging the batteries. Maybe this has something to do with the processing error that happened at some time while it was running overnight? The sudden change you see is when I swapped from grid to solar. Maybe I am misunderstanding what the Dashboard graph is showing?

Where do yo see db error. The attach screen is warnings. Also this is a desktop app and we running it from startup scrip. I am not sure exacly what is that. I have ask in the programming forum and they replied that is debugging info and not to stress about it

You have to post more info like what was your soc ect

Sent from my SM-G920F using Tapatalk

1 hour ago, Manie said:

Where do yo see db error. The attach screen is warnings. Also this is a desktop app and we running it from startup scrip. I am not sure exacly what is that. I have ask in the programming forum and they replied that is debugging info and not to stress about it

You have to post more info like what was your soc ect

 

The idea that it was a DB error was just a guess from the text about UTF8 in the warning messages. ICC just seemed to stop taking correct readings, although it was still running and also it did not change from grid to battery at the time specified in the settings, so it was almost as if it was unresponsive. I had had the change to grid and solar times set and activated from around a week ago and it had been working fine applying them until this error occurred at some time last night.

I just thought I'd post the info in case it was useful. I'll keep monitoring and see if it happens again.

The incorrect grid reading, however, does worry me. I have the inverters set to never charge batteries from grid. The screenshot from this morning when ICC was in an unresponsive state shows as if grid was carrying load and also charging batteries when it was just supplying the load and the PV input was charging the batteries.

1 hour ago, Manie said:

. Also this is a desktop app and we running it from startup scrip. I am not sure exacly what is that. 

OK. The screenshot I sent was of the LX Terminal. Not sure if it is correct but when pi starts up and ICC starts automatically I also have the LXTerminal open and running. I thought that was normal. If I close the LXTerminal window it shuts down ICC - perhaps this is not what is supposed to be happening? Screenshot shows what I have in pi GUI just after startup. It always starts the LXTerminal as well as ICC and I can't close the LXTerminal without it closing down ICC also.

Edited February 8, 20178 yr by incagarcilaso
Added screenshot

Please monitor it, What some users experience on the infini's is coms, but not from the app. Even after reboot still no data. After a inverter reboot all working fine !!

1 minute ago, incagarcilaso said:

If I close the LXTerminal window it shuts down ICC - perhaps this is not what is supposed to be happening?

I personally don't run startup scripts , I just run it like a desktop app. Some users wanted it to startup automatic after a reboot. But my pi does not crush and i never reboot it. There is no use for me to run it on startup. Yes if you close the terminal it will close the app also because the terminal launch the app

Under home/pi there is a folder called ICC. I run it from there, just ensure that the app does have permissions.

 

5 minutes ago, Manie said:

Please monitor it, What some users experience on the infini's is coms, but not from the app. Even after reboot still no data. After a inverter reboot all working fine !!

Yes, curious. OK, I'll monitor it.

3 minutes ago, Manie said:

Under home/pi there is a folder called ICC. I run it from there, just ensure that the app does have permissions.

 

OK. So when I start the Pi, ICC starts and is running by the time I log in to the GUI. So I thought that is what had been set up in the Jessie/ICC image. I wasn't aware that I had created a startup script to run ICC at start up, so I'm confused as to why it does. I would do the same as you and on the very few occasions that the Pi reboots I would just log in for a moment and launch ICC. I don't have the "Autostart" checked in the Settings either.

As you say, it must be in a start up script, so I'll dig around and find out why and change it.

The auto start in the setting basically press the start button on top,  

Mine is check , so when i start the app , it start running, otherwise i have to click the start button on top

4 hours ago, incagarcilaso said:

If I close the LXTerminal window it shuts down ICC

Normal unix behaviour. When you close the terminal, it kills the shell process (bash) running in it. Bash in turn sends the HUP (hangup) signal to all processes it's managing. The default behaviour for SIGHUP is to terminate. So unless you install an alternate signal handler (see the manpage for signal(2)*) that's what your application does.

To work around it, you start the application with an & at the end (to put it in the background), or if it is already running you press Ctrl+z in the shell to stop it, then type "bg" to send it to the background. Finally, type "disown". This causes the shell not to send SIGHUP to the process when you terminate it, so you can close the terminal.

* the syntax signal(2) has some unix history behind it. The (2) indicates that we're talking about the signal documentation in section 2 of the manual. Section 2 contains system calls, that is, the API of the kernel, as opposed to stuff implemented in libraries (section 3), user commands (section 1) or configuration files (section 5). This was just one of the beauties of Linux back when I discovered it. Not only did it come with a free compiler suite in a time when Borland and Microsoft wanted money for theirs... it came with manual pages for EVERYTHING, including itself ("man man" actually works).

The only thing it doesn't have a man page for is "woman".

6 hours ago, Manie said:

The auto start in the setting basically press the start button on top,  

Mine is check , so when i start the app , it start running, otherwise i have to click the start button on top

Of course, yes it's to start monitoring when the app starts, not to start the app on boot.

I have had the odd occasion when ICC-Pi hung up. Usually notice that the figures on MQTT does not change any longer. Then I just reboot the Pi and let the script start ICC. The display hides the terminal window so it does not bother me. I am going to give @Manie 's method of starting ICC and see what happens. Perhaps a watchdog program of sorts to monitor ICC will solve most of the problem, which is not much of a problem exept when one is away form home and perhaps monitor less frequently. I have never had the Pi hang up.

Guys if the pi is not for you there is always Solarweb to go to. TTT likes this comment of not working and send me nice faces and getting a nice kick out of it.

So if you have problems and are unhappy go to MR TTT he believes his software is the answer

Have a great day

Sent from my SM-G920F using Tapatalk

@Manie if I gave the impression that I am unhappy with ICC, I apologise. That was certainly not the intention. I was merely adding my experiences to the other posts on the thread. As I have frequently said on this forum, I cannot envisage running my system without ICC and MQTT. It was a disconcerting moment when the AICC website was closed one morning when I opened the website only to see it had closed down. It was very reassuring and a relief when you posted that you are continuing development. Unfortunately sometimes comments that are well intended and aimed at keeping you informed of user experiences, sound like criticisms. That was certainly not my intention. After all something like a power spike can hang up any program but to determine that would require something like a  power line logger at huge cost. Be assured that to my mind ICC-Pi/MQTT is an outstanding solution for me and I am sure many others. I for one would not even take the trouble to try something else. If it is'nt broke there is nothing to fix. So just carry on with your development and brush off criticisms. Constructive suggestions on the other hand would hopefully be of use to you in improving the product to whatever extent that may be possible. Criticisms without suggested solutions should be ingnored with the scorn they deserve. Hopefully we are all mature enough on this forum not to be guilty of such behaviour, not even in jest as it will sure sound malicious.

 

FWIW. Manie and I are happily chatting on Skype. And yes, we joke a lot.

Story was that I said that we have SolWEB reader hang for no reason, BMV data is still sent but the Axpert data is gone. The app is solidly frozen.

Manie said his software never freezes, it is a coding issue, which I took with a pinch of salt.

Although ours happens infrequently, can take weeks, there is absolutely no pattern. But if you rely on it to switch the Axpert, we though it is a potential problem.

So we are also looking at a "watchdog" program to check the reader. For software can fail.

So ja, I ragged him this morning. My bad.

 

EDIT: No, I do not want to compete with Manie on Windows software. We started a long time ago, and we are focused on data and database, so SQL Express, SQL localDB is our preferred DB for we use a lot of Stored Procedures to do the things we want done. It is a small system but it is BIG.

 

 

@Manie it seems there is an error in reading "Grid Watts" when the inverters are on "Utility" and solar power kicks in to charge batteries. ICC interprets it as all grid power when it is in fact a mixture of grid and solar power - grid power is supplying the load but solar power is charging the batteries. Please see screenshot that confirms this. It is the same as the screenshot that I posted yesterday in this thread, where the same thing is happening - ICC interprets solar power as grid power.

In the image the "grid watts" line should not increase and separate from the "load" line but remain equal to it while the "pv watts" and "battery watts" lines rise together. I am not drawing that much grid power because the inverters are set to never charge the batteries from the grid. That extra power that is charging the batteries is coming from pv watts not the grid.

Hi@ebrsa no i dit not took it that way.

I just hate it when i get skype messages that ..... . There was a big discussion on the pi thread that time about the pi. Nobody could produce execpt me. It was a challenge as i did not program for the pi. Execpt so python code wich is easy that 99% of users can just copy and past and it work.

Where are the people now that started the thread and never produced. Now i get criticize if there is a problem. Myne is running almost a year and i dont experience the problems.

I did a test that me and Cobus was runnig and it did fail. I never added it to the one that users use

Sent from my SM-G920F using Tapatalk

@Manie it seems there is an error in reading "Grid Watts" when the inverters are on "Utility" and solar power kicks in to charge batteries. ICC interprets it as all grid power when it is in fact a mixture of grid and solar power - grid power is supplying the load but solar power is charging the batteries. Please see screenshot that confirms this. It is the same as the screenshot that I posted yesterday in this thread, where the same thing is happening - ICC interprets solar power as grid power.
In the image the "grid watts" line should not increase and separate from the "load" line but remain equal to it while the "pv watts" and "battery watts" lines rise together. I am not drawing that much grid power because the inverters are set to never charge the batteries from the grid. That extra power that is charging the batteries is coming from pv watts not the grid.

Please refere to the other topic. As users agree is i will take solarpower out as it confuse people and also difficult to calc it correcly. Specially for the infini that is grid ty

Sent from my SM-G920F using Tapatalk

7 minutes ago, Manie said:

I just hate it when i get skype messages that .

Hozid Manie , FWIW , it might be in you interest to keep skype and PF apart. Keep up the good work! 

True Paul. Thank you

Sent from my SM-G920F using Tapatalk

6 minutes ago, Manie said:

Please refere to the other topic. As users agree is i will take solarpower out as it confuse people and also difficult to calc it correcly. Specially for the infini that is grid ty

Sent from my SM-G920F using Tapatalk
 

 

 

But even if you remove the light blue "Solar Watts" line this reading is still incorrect. It says that I am drawing the full 1250 watts going into the installation from the grid when what is happening is that I am drawing 750 watts from the grid to supply the load and the remaining 500 watts are supplied to the batteries from pv power. This 500 watts does not come from the grid.

How the program works if you on grid then pv watts will not be added to the grid watts because that will go to batteries.

If you still on grid and there is no pv then the battery watts will be added to to grid.

If you run in cluster mode and you run one inverter to charge from solar and the other one to charge from grid. I do not have a solotion on how to calc it correcly as its difficult to detect it

Sent from my SM-G920F using Tapatalk

Open a new topic and then we can maybe come up with a solution for the cluster mode

Sent from my SM-G920F using Tapatalk

3 minutes ago, Manie said:

How the program works if you on grid then pv watts will not be added to the grid watts because that will go to batteries.

If you still on grid and there is no pv then the battery watts will be added to to grid.

If you run in cluster mode and you run one inverter to charge from solar and the other one to charge from grid. I do not have a solotion on how to calc it correcly as its difucut to detect it

Sent from my SM-G920F using Tapatalk
 

Perhaps the "Grid Watts" value needs a name change then because it is not really ALL grid watts when the inverters are in utility bypass and the PV array is charging the batteries. This could be alarming because the user may think they have configured the inverters to charge the batteries from the grid whenever the inverter is in bypass mode. That is certainly what it looks like in this graph and I went down to the basement to check that setting when I say this.

Basically, when the Axperts are on utility the "Grid Watts" shows "Total Watts" (grid watts + pv array watts), which are not necessarily all grid watts. But then when the Axperts are in solar/battery mode the "Grid Watts" on the graph is a true grid watts reading (but in this case it is always 0 so that doesn't help). Only when the Axperts are on utility and there is no PV array input is that "Grid Watts" line an accurate representation of what is really happening. For users with 500+ Ah battery banks it could be alarming to suddenly think that they are charging them from the grid - that's what it looks like on the graph.