News items for tag statistics - Koos van den Hout

2022-05-11 SolarEdge omvormers 'THROTTLING'
Na het aanpassen van het netwerk naar de schuur naar gigabit was ik natuurlijk ook de monitoring van de SolarEdge inverter met modbus/tcp aan het testen. En toen viel me even iets op, de inverter stond in mode THROTTLING en dat was me nog niet eerder opgevallen.

De uitvoer is dan
$ ./sunspec-status -v se-schuur -m 0
INVERTER:
             Model: SolarEdge  SE2200
  Firmware version: 3.2537
     Serial Number: xxxxxxxx

            Status: THROTTLING

 Power Output (AC):          342 W
  Power Input (DC):          348 W
        Efficiency:        98.50 %
  Total Production:     3964.313 kWh
      Voltage (AC):       237.40 V (49.94 Hz)
      Current (AC):         1.53 A
      Voltage (DC):       378.80 V
      Current (DC):         0.92 A
       Temperature:        42.75 C (heatsink)
Ik kon niet vinden wat de reden was van het terugregelen van het uitgangsvermogen. Ik log nu wel de statuswaarde van de inverters om te zien of dit vaker voorkomt.

Update: Achteraf denk ik dat dit gekomen is omdat ik de omvormer in de schuur gereboot had om het juiste IPv4 adres te krijgen voor monitoring. Dit was op een best wel zonnig moment. Na de reboot was ik snel aan het testen of de modbus/tcp monitoring het deed naar het nieuwe adres, en de omvormer gaat niet in een klap voluit electriciteit leveren maar brengt dat langzaam op gang.

Tags: , ,
2022-05-09 Grafana alerts working again
After reverting to Grafana 8.4.7 for a while because alerts were failing in Grafana 8.5.0 I had a look at the available version today and saw version 8.5.2. I assumed the problem with DataSourceNoData errors was fixed by now and did the upgrade.

Indeed the alerts are seeing data fine now and I trust they will work when needed.

Tags: , ,
2022-04-23 Grafana alerts failing in 8.5.0
I installed Grafana from their debian repository, so I get updates via the normal apt update / apt dist-upgrade process. Since upgrading to version 8.5.0 the alerts were all firing because of 'DatasourceNoData' errors. According to Alert Rule returned no data (after upgrade to 8.5.0) #48128 other people are seeing this too.

For now I downgraded to version 8.4.7 where things work fine and I'll see if a newer version shows up.

Tags: , ,
2022-03-18 Using grafana for alerting too
I've been playing with grafana for about a year since starting with updating my statistics gathering and I keep seeing new options and updates in grafana.

Grafana recently got some new options for alerting and I am trying a few of those. Alerts for things that are a real problem and can cause other problems are a good start. Based on some earlier problems I keep an eye on some filesystems that are over 90% full.

Today I read Three DDoS attacks on my personal website found via Three DDoS attacks on my personal website : r/homelab reddit and this made me wonder about overloads on my webserver. The easiest way to detect problems with web serving I could think of is to look at the queue size in haproxy which is monitored in influxdb/grafana anyway for nice graphs of website traffic.

I did have a time with too high queues for backend webservers. But that was when the backend server was completely broken due to a filesystem problem so that was a logical reason.

It would be nice if I could iterate alerts, like 'for the root filesystem of every monitored system'. Or at least copy them changing only the system name in the rules and alerts.

Tags: ,
2022-02-16 Closing 2021 in amateur radio
QSO count plot up to December 2021 I noticed I didn't do a "Closing 2021 in amateur radio" post yet, so time to catch up. Looking back at the Review of 2020 in amateur radio with plans for 2021 I can say:
  • Practising morse has happened! Just no exam yet, but that is mainly due to the current circumstances
  • Satellite contacts: none.
  • Morse and phone in contest: yes!
  • New qsl cards ordered and in use
And the plans for 2022:
  • More and more morse, and that exam. There is an exam date now and it will be possible to get the wanted 'CW included' on my radio amateur identification
  • Again satellites
  • In contests: try to get more morse and phone contacts.
  • Use the better propagation to get contacts on different bands

More detailed statistics over 2021

And I had to check my own notes again how I got these numbers last year, so I'm adding the sql queries I typed at the mysql/mariadb client. With the database behind cqrlog available I can make all kinds of queries.

By month

The influence of months with (digital) contests isn't as strong as in previous years.
+-------+-----+
| month | cnt |
+-------+-----+
|     1 | 234 |
|     2 | 204 |
|     3 | 238 |
|     4 | 161 |
|     5 | 131 |
|     6 | 111 |
|     7 | 211 |
|     8 |  19 |
|     9 | 232 |
|    10 | 204 |
|    11 | 191 |
|    12 | 101 |
+-------+-----+
Query: select month(qsodate) as month,count(id_cqrlog_main) as cnt from cqrlog_main where year(qsodate)=2021 group by month order by month;

By band

No real surprises there. And the feeling that 10 meter was improving isn't showing in the statistics yet.
+------+-----+
| band | cnt |
+------+-----+
| 40M  | 699 |
| 20M  | 849 |
| 17M  | 151 |
| 15M  |  40 |
| 10M  | 243 |
| 2M   |  51 |
| 70CM |   4 |
+------+-----+
Query: select band,count(id_cqrlog_main) as cnt from cqrlog_main where year(qsodate)=2021 group by band order by freq;

By mode

Almost double the number of morse contacts compared to the previous year.
+-------+-----+
| mode  | cnt |
+-------+-----+
| JT65  |   2 |
| PSK31 |   3 |
| FM    |  19 |
| FT4   |  35 |
| PSK63 | 226 |
| CW    | 240 |
| SSB   | 267 |
| RTTY  | 386 |
| FT8   | 859 |
+-------+-----+
Query: select mode,count(id_cqrlog_main) as cnt from cqrlog_main where year(qsodate)=2021 group by mode order by cnt;

Tags: , , ,
2021-11-12 Meer magische getallen in Sunspec Modbus
Na een poosje blijkt ook het getal 65534 (0xFFFE) in sunspec modbus antwoorden een vorm van 'geen geldige uitlezing' te kunnen zijn. Ik heb de scripts die de gegevens ophalen en verwerken richting influxdb hier op aangepast.

Tags: , ,
2021-11-10 Nieuwe firmware geïnstalleerd in SolarEdge omvormers
Het lokaal uitlezen van de SolarEdge omvormers via Modbus/TCP ging op den duur toch weer haperen, zeker over wifi.

Ik begreep uit wat beschrijvingen dat het bijwerken van de firmware in de omvormer hierbij zou moeten helpen dus dat heb ik vandaag gedaan. Ik had eerder naar een van de omvormers ook een netwerkkabel gelegd maar nog niet de omvormer open gemaakt om die van binnen aan te sluiten. Nu moest de omvormer ook open om de firmware bij te werken dus heb ik gelijk het ontbrekende stukje UTP kabel gemaakt en aangesloten, en de wifi module verwijderd.

De SolarEdge handleiding voor het bijwerken van omvormer firmware had na alle stappen om de omvormer veilig open te maken een aantal stappen voor het kiezen van een upgrade maar de omvormer 'zag' gelijk bij het inschakelen dat er een kaartje met firmware in zat en startte vanzelf de upgrade.

Op beide omvormers is de upgrade gelukt. De omvormer waar ik ook de netwerkaansluiting omgezet heb van wifi naar bedraad wil momenteel geen gegevens doorgeven naar SolarEdge monitoring (ik zie wel verkeer naar buiten gaan) en er staat ook geen S_OK op het display. Ik denk dat dat komt door de wijziging netwerkaansluiting. Volgens wat bronnen kan dat even duren, maximaal 2 dagen.

Ondertussen kan ik nu via Modbus/TCP de nodige gegevens goed uitlezen, en ik heb wat veranderingen aan het monitoring script gemaakt zodat er ook data van de afzonderlijke omvormers naar een influxdb database gaat.

Tags: , ,
2021-11-09 Zonnepanelen omvormers lokaal monitoren (2)
Gisterenavond de andere omvormer ingesteld voor Modbus TCP. Ook hier hetzelfde effect, de omvormer reageert eerst niet. Het lijkt dat er een dag/nacht overgang of een aantal uren wachten nodig is voor deze instelling overgenomen is.

Nu met zonlicht:
$ ./sunspec-status -v se-boven -m 0
INVERTER:
             Model: SolarEdge  SE2200
  Firmware version: 3.2434
     Serial Number: xxxxxxxx

            Status: ON (MPPT)

 Power Output (AC):          129 W
  Power Input (DC):          130 W
        Efficiency:        98.51 %
  Total Production:     2952.829 kWh
      Voltage (AC):       238.90 V (49.99 Hz)
      Current (AC):         0.78 A
      Voltage (DC):       380.10 V
      Current (DC):         0.34 A
       Temperature:        30.16 C (heatsink)

Als de omvormer iets meer actief wordt komt er inderdaad een meting uit het DC voltage. In de verwerking moet ik dus echt een uitzondering maken voor 'geen data' bij uitlezing 65535.

Tags: , ,
2021-11-07 Zonnepanelen toch (ook) lokaal monitoren
Onze zonnepanelen met SolarEdge omvormers liggen er al een tijd en na wat nadenken over monitoring heb ik toen toch voor de optie gekozen om de gegevens gewoon aan de solaredge API te vragen en wat te verwerken in rrdtool voor mooie grafiekjes en in een postgresql database voor langdurig bewaren.

Maar de laatste weken krijg ik vrij regelmatig foutcode 429 van de SolarEdge API dat ik teveel queries zou doen. Ik kan niet terugvinden waar dat vandaan komt. Ook na het vervangen van de API key (zodat eventuele andere scripts die ik heb laten slingeren met mijn api key stoppen) blijven deze status 429 resultaten komen:
HTTP Status 429 – Too Many Requests
Message Concurent limit quota exceeded
Description The user has sent too many requests in a given amount of time ("rate limiting").
Tijd om naar de opties te kijken om de omvormers uit te lezen via Modbus over TCP. De code is er: tjko/sunspec-monitor: Monitoring Sunspec (Modbus TCP) compatible Solar Inverters - GitHub maar nu de omvormers zo ver krijgen dat dit werkt.

Update: Handleiding gevonden hoe ik Modbus TCP inschakel op de SolarEdge omvormer. Voorlopig lijk ik er tegenaan te lopen dat de Modbus TCP setting dit maar 2 minuten open stelt en daarna weer afsluit. Terwijl ik dit eigenlijk eens per 5 of 10 minuten wil opvragen. Met een firmware upgrade schijnt dit te verhelpen te zijn.

Update: Een paar uur later snapt de omvormers wel Modbus TCP op poort 502. Vreemd, het lijkt wel alsof het een tijdje duurt voordat de configuratie actief wordt. Hoe dan ook, succes:
$ ./sunspec-status -m 0 -v se-schuur
INVERTER:
             Model: SolarEdge  SE2200
  Firmware version: 3.2434
     Serial Number: xxxxxxxx

            Status: SLEEPING

 Power Output (AC):            0 W
  Power Input (DC):            0 W
        Efficiency:         0.00 %
  Total Production:     3514.256 kWh
      Voltage (AC):       239.30 V (49.99 Hz)
      Current (AC):         0.00 A
      Voltage (DC):      6553.50 V
      Current (DC):         0.00 A
       Temperature:        17.79 C (heatsink)

De 6553.5 volt DC lijkt nog een vreemd iets (uitlezing 65535 keer vermenigvuldigingsfactor -1), ik moet morgen als de omvormer wakker is dit nog eens controleren. Omdat er een aantal andere variabelen ook 65535 zijn lijkt het een geval 'niet actief' of iets dergelijks. Nalezen van de sunspec modbus specificatie geeft bevestiging: waarde 0xFFFF (65535) is voor 'not implemented'.

Ik zie mooie grafiekjes zonnestroom aankomen als ik deze data in influxdb stop en er grafana op loslaat.

Tags: , ,
2021-09-11 Adding physical hardware temperatures in telegraf/influxdb/grafana
Grafana dashboard with host cpu temperatures After starting the collection of a lot of the system data I wanted with telegraf/influxdb/grafana one small part was missing: the system temperature sensors. I like these, so I had a look and found the inputs.temp plugin in telegraf which is normally disabled.

Enabling it on hosts that have actual hardware to measure worked ok. On the Raspberry Pi systems it gives one temperature:
> SHOW TAG VALUES ON "telegraf" WITH key="sensor" WHERE host='joy'
name: temp
key    value
---    -----
sensor cpu_thermal_input
On the home server conway it gives quite a lot of temperatures:
> SHOW TAG VALUES ON "telegraf" WITH key="sensor" WHERE host='conway'
name: temp
key    value
---    -----
sensor coretemp_core0_crit
sensor coretemp_core0_critalarm
sensor coretemp_core0_input
sensor coretemp_core0_max
sensor coretemp_core1_crit
sensor coretemp_core1_critalarm
sensor coretemp_core1_input
sensor coretemp_core1_max
sensor coretemp_core2_crit
sensor coretemp_core2_critalarm
sensor coretemp_core2_input
sensor coretemp_core2_max
sensor coretemp_core3_crit
sensor coretemp_core3_critalarm
sensor coretemp_core3_input
sensor coretemp_core3_max
sensor coretemp_core4_crit
sensor coretemp_core4_critalarm
sensor coretemp_core4_input
sensor coretemp_core4_max
sensor coretemp_core5_crit
sensor coretemp_core5_critalarm
sensor coretemp_core5_input
sensor coretemp_core5_max
sensor coretemp_physicalid0_crit
sensor coretemp_physicalid0_critalarm
sensor coretemp_physicalid0_input
sensor coretemp_physicalid0_max
For the dashboard showing all relevant temperatures for a system this is a bit overkill and makes the dashboard hard to read. Solution: go for all the temperature sensors that end in 'input', with the variable in the dashboard defined as 'ending in input':
> SHOW TAG VALUES ON "telegraf"  WITH key="sensor" WHERE host='conway' AND sensor=~/input$/
name: temp
key    value
---    -----
sensor coretemp_core0_input
sensor coretemp_core1_input
sensor coretemp_core2_input
sensor coretemp_core3_input
sensor coretemp_core4_input
sensor coretemp_core5_input
sensor coretemp_physicalid0_input
So far this works with all physical systems.

Tags: , ,

IPv6 check

Running test...
, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred. PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers

RSS
Meningen zijn die van mezelf, wat ik schrijf is beschermd door auteursrecht. Sommige publicaties bevatten een expliciete vermelding dat ze ongevraagd gedeeld mogen worden.
My opinions are my own, what I write is protected by copyrights. Some publications contain an explicit license statement which allows sharing without asking permission.
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews
This page generated by $Id: newstag.cgi,v 1.37 2022/02/15 21:48:19 koos Exp $ in 0.023445 seconds.