the MQTT protocol as a customized server protocol hasn't been rolled out
to all Ecowitt consoles (yet)
- rolled out to: GW2000, GW3000 so far
after having successfully proven itself in the field, it will be rolled
out to all IoT enabled consoles.
You could have known this if you had consulted
I don't think that this "deviated" timestamp is a real issue.
Assuming your weewx srchiving interval is 5 minutes (300 seconds) and also
assuming the GW3000 archive interval is also 5 minutes, its archiving
time stamp will be whenever it starts archiving - any time between
minute 00 and minute
correct,
the WS85 restriction applies to the GW1000 and WH2650/2680 only - all
other consoles (e.g. GW> 1100) with local API can also receive and
process a WS85.
On 07.07.2025 19:49, vince wrote:
Minor correction. You ‘can’ use Gary’s original ecowitt driver with a
WS85 if you have a consol
Reading the thread I think there is some potential confusion ...
Hence the whole story in short below:
1. the GW1000, GW1100, GW1200, GW2000, GW3000 - all Ecowitt consoles
with the local Ecowitt API, the binary local API for which the weewx
local API driver is there, can handle all existing Eco
False, it will call genStartupRecords() and
ask for all records since the last timestamp in the database. If True,
then the catch up is not done.
It should probably be documented.
-tk
On Tue, Jul 1, 2025 at 11:42 AM 'Rainer Lang' via weewx-user
wrote:
after some code inspection (
after some code inspection (and my understanding of Python) it appears
(see catchup_factory(self) line 4897)
that at weewx startup, if a device with SD card is available under the
IP address from weewx.conf, the EcowittDeviceCatchup class is executed.
If not, provided the API/APP key and MAC addr
the ecowitt.net backfill and the SD card backfill are mutually
exclusive/excluding each other
in addition, the MAC address of the console in question is needed - also
for the SD card download the MAC address is needed
=> a nested setup (as e.g. done in CumulusMX) will make sense
1. activate e
sappeared
from github. Hopefully, this wasn’t
intentional and Gary’s work will appear again
soon.
> On Jun 1, 2025, at 12:47 PM, Chuck Rhode
wrote:
>
in soon.
> On Jun 1, 2025, at 12:47 PM, Chuck Rhode
wrote:
>
> On Sun, 1 Jun 2025 21:14:19 +0200
> "'Rainer Lang' via weewx-user"
wrote:
>
>&
weewx is not different from the weewx database 😉 - the database is part
of weewx.
I think what you are talking about is the depiction of the database (and
current) data in a skin,n the weewx word for a web page, by default the
Seansons skin.
How database data are depicted there depends on the
@vince: (and others 🙂)
the WiKi keeps track with three small paragraphs in the weewx section:
for the modern Ecowitt (clone) consoles and their available sensors two
Ecowitt related drivers are important:
1.
the Interceptor driver written by Matthew Wall
2.
the Ecowitt local gateway API
You should be able to use it with the weewx Interceptor driver.
But it's not weewx connecting to your weathr station, but your console
sending data to weewx. 😎
How this works with an Ambient station is described in the Fine Offset /
Ecowitt / Ambient ... WiKi
https://meshka.eu/Ecowitt/dokuw
if it's only rain data from yesterday, you can look them up in your
dashboard at ecowitt.net - assuming you have your console post there
And then I would install sqlitebrowser (unless it's already part of your
Linux installation) and edit and save the data directly in the database
(make a safety
if you take the time to read the Ecowitt WiKi
https://meshka.eu/Ecowitt/dokuwiki/doku.php?id=start#data_flow_between_sensors_consoles_application_software_and_internet_weather_services
to understand how Ecowitt (clone) consoles communicate
and also the weewx chapter in the Ecowitt WiKi
https:/
Hi Benedict
you need two files
1. the very file to import which contains the data with a headline
giving a name to each field (between two separators, delimiters, in the
example a ";") and having the same sequence below where the data are
2. the .conf file where the weewx import program is told
@Gary or others knowledgeable regarding the topic ...
Is there a special reason why this link doesn't work anymore ?
Or is this only a temporary thing ?
A search on GitHub with the "GW1000" keyword doesn't give any results ...
best regards
Rainer
--
You received this message because you are s
@Cameron D.
I think you are mistaken here regarding the console WLAN - even if that
Garni piece is manufactured by CCL, what they do is a commonly used process.
E.g. factually all FineOffset (clone) consoles can create their own WLAN
and a WLAN enabled device (PC, Smartphone etc.) can connect to
I suggest the wee_import approach earlier in the thread
of course weewx won't do this by itself, the import needs to be triggered
for such tasks you can create a CRON job - in Linux (derivate)
installations usually the cronjob config file is /etc/crontab
if you want to update weewx every five mi
One thing I can tell that the Garni 1025 is not a Fine Offset clone
model like your Ambient ObserverIP WS-1002 - therefore the settings for
your WS-1002 cannot be taken. It's a different manufacturer for the
Garni 1025, CCL. When your Garni 1025 posts to WU, it probably posts
only every 5 minutes,
org.uk
On 17 Feb 2025, at 10:50, 'Rainer Lang' via
weewx-user wrote:
Ecowitt has confirmed that the missing piezo
data, the WH7 time stamp of the last
Why make it so complicated ?
every Ecowitt console has the option to post the sensor data to a
customized server address - locally or remotely.
Have your remote console post its data to your local server (e.g. your
RaspberryPi) and have weewx process the data with the help of the
Interceptor drive
my test environment.
steepleian schrieb am Montag, 17. Februar 2025 um 13:22:43
UTC+1:
Good news indeed. Thank you for your update.
Ian
https://claydonsweather.org.uk
On 17 Feb 2025, at 10:50, 'Rainer Lang&#
I am not the developer but a user of the (extended) Interceptor driver -
the base developer is Matthew Wall (but only for the basic sensors and
not the piezo sensors nor other Ecowitt sensors) and the extended
version was created by a German developer who adapted Matthew's code
(basically the f
I suggest you read the weewx 5.0 documentation and see what's new in 5.0
and how things are done differently.
E.g. extensions are now installed with the weectl tool
see https://weewx.com/docs/5.1/utilities/weectl-extension/
if you install the Interceptor driver zip file with weectl, all should
I don't think the Interceptor driver in its pre-diluvial state will do
the job here - I suggest to get the up-to-date version of it from (see
below)
You will need to use the original interceptor driver installation whose
driver will not show you your rain data, as the dinosaur-version doesn't
Ecowitt has confirmed that the missing piezo data, the WH7 time stamp of
the last lightning event and the LDS01 depth will be added to the SD
card data with the next firmware for the GW3000 and WS6210.
@Gary: the header text now contains for temperatures a one-character
representation of °C an
there are a few more things to be considered from the bigger perspective
with the GW3000
- some referring to the SD card archiving of also other sensor values
(e.g. LDS01, WH57 ...), the file name change etc - all needs to be
streamlined - already a few things were sorted with the last firmware
in addition - an excerpt from your syslog covering one reporting cycle
will also be needed - two+ pairs of eyes can often see more than one pair.
An commonly known reason for that behaviour (worked before, no changes
made at your end) that your provider enforced https.
So changes to your .htacc
I think what would be helpful first is to post the portion of your
weewx.conf file where this weewx posting is described (possible password
can be replaced by ) -
best the complete [StdReport] section (stanza) as it show in your
weewx.conf.
And we'll take it from there.
As far as I am awar
OK guys, try https://meshka.eu/Ecowitt/dokuwiki/doku.php?id=start#gw3000
instead 😎
On 03.12.2024 08:00, Graham Eddy wrote:
i just clicked on it and it says ‘oops not found’ rather than ‘404'
*⊣GE⊢*
On 3 Dec 2024, at 5:49 pm, 'michael.k...@gmx.at' via weewx-user
wrote:
I just clicked it, fo
Hi Ashley,
I think you presented your station already in 2006 in the weewx group
The relevant portion of your station for the weewx context here are two
pieces:
the legacy WH25 indoor T&HP sensor (nowadays WN32P) and the Fine Offset
WH2600 LAN gateway also known as observer IP.
The pressure read
you probably need to define the units/unit group for pm4_0 in
extensions.py 😎
On 01.08.2024 08:08, j.fri...@gmail.com wrote:
Hi Gary,
the v0.6.3b1 works wery well. There is only one possible issue with
PMI 4. index.html page shows it in other way then others values .
Thank you very much for
not sure if Gary has already considered the new WH46 situation into the
0.6.1 driver version
the API response is different depending on whether a WH45 or a WH46 are
connected to a console/gateway with the local Ecowitt API
- there can only be one WH45/46 connected - either a WH45 or a WH46
*in
this is all clear and long stated in the WiKi - the 79 interval gets
restarted once a discharge is detected.
But thinking that a SDR would receive values more often and faster than
a normal Ecowitt console (that was the statement I was referring to) is
an illusion.
That's at least how the stat
"If there is a possibility to extract a singled detected lightning event
and
> it's data with standard devices, is another story. If so, I'd see the
point
> of doing so. At least the minimal distance and weighted average distance
> are interesting values to me. I doubt it is possible doing this
in addition, look up
https://weewx.com/docs/5.0/utilities/weectl-station/#create-a-new-station-data-directory
there you find the example how to create a Vantage station (of course
the values for altitude, longitude, latitude have to be replaced by your
values)
|weectl station create --no-pro
try reading (and applying) https://weewx.com/docs/5.0/hardware/vantage/
On 20.03.2024 01:07, Sidney wrote:
Type: Davis Vantage Pro2/Vue
Station model: WeatherDuino 4Pro DB
Connection: TCP/IP
IP: http://192.168.0.39
Thank you Rainer.
On Wednesday, March 20, 2024 at 12:42:51 AM UTC+1 Rainer Lang
I'm not sure if you have understood the weewx concepts ...
What would be the use of changing skins - except you don't like the
Seasons skin
But before you do this, you better get weewx running with the default
Seasons skin.
Once running, you can add or switch skins.
You probably want to
...
It is a Sainlogic WS3500 👍.
Thank you for your help.
On Tue, Mar 19, 2024, 21:23 'Rainer Lang' via weewx-user
wrote:
can you post your weewx.conf entries of the [Interceptor] stanza ?
Also a screecopy of your WS View Plus customized server entries
would be helpful.
@Sidney - I think you are confusing a few things and are comparing
apples with pears.
You may not be aware of the functionality of and the need to have a
webserver (program).
CumulusMX has an inbuilt webserver, but not one which is available to
users other than the CMX users.
So when you can rea
can you post your weewx.conf entries of the [Interceptor] stanza ?
Also a screecopy of your WS View Plus customized server entries would be
helpful.
I have just run out of my crystal balls ...
And a WS3500 is what ? A Sainlogic WS3500, an Ecowitt WH2910 clone ?
The more precise you are in your
correct, but weewx (its Seasons skin) doesn't have a realtime dashboard
(except you install the mqtt based Belchertown skin).
The update interval is defined in weewx.conf and could go down to one
minute instead of five minutes (in theory - in practice to be found out
if the reports can complete
if you have a webserver installed, entering
http://ip-address-of-the-weewx-server/weewx will show you the last
created Seasons skin
On 19.03.2024 21:06, Sidney wrote:
Hi, I believe I've successfully installed weewx. The manual says:
After about 5 minutes (the exact length of time depends on y
've learnt a great deal so far on this massive learning curve,
but obviously I am not up to this ...yet.
Bear with me whilst I uninstall it all again, and start a fresh again.
Many thanks for the Links, I'm off to do some more reading.
On Mon, Mar 18, 2024 at 7:55 PM
The Ventus W830 is a Ecowitt WH2910 clone. In your mail it is not clear
what "it" means. Your RaspberryPi, weewx, the console ?
Maybe you should first make yourself familiar with your environment,
your setup, the architecture and then see where weewx comes into play.
I suggest you read http
a lighter, the flash of a camera in front of the sensor
On 14.03.2024 18:50, Joachim Puttkammer wrote:
How can I simulate lightning for the WH57 sensor?
--
You received this message because you are subscribed to the Google
Groups "weewx-user" group.
To unsubscribe from this group and stop
I don't think it has changed ... why would it ?
It's a reasonable approach for how and when to copy an active database.
That's independent of the weewx version.
Safest way is always to shutdown weewx (best immediately after the last
archive records were written), then copy, then restart weewx
interesting, but as you didn't give us more context, you're likely not
to receive a satisfactory reply
1. it is good practice to post a _*complete*_ syslog protocol from a
weewx start to at least one archiving and reporting cycle (unless it
doesn't reach it)
2. you should tell us about your co
that's the weexwx end - but to me this looks like an issue at the
console end.
Each transceiver stick has a unique ID which should be mentioned in
weewx.conf
(and which will be reported in the syslog, when debug = 1)
Also the console needs to be paired with the transceiver stick - that's
KlimaL
only from the context (and when you know) one can guess that you are
talking about KlimaLogg and the the KlimaLogg extension.
And the messages refer to the tranceiver USB stick through which the
KlimaLogg console communicates with weewx
Are you aware of how the two devices cooperate ?
Did you p
you may have to have your console post its data also via the customized
server functionality to your RPi, using Wunderground protocol, and e.g.
port 8000
and then have your interceptor driver at the weewx end listen at port
8000. Mode would then be listening and not sniffing ! wu-client to be
c
hanks for that, very useful.
I guess what I meant by 'compatible' was the "Supported Hardware"
list on https://weewx.com/hardware.html, almost all of which
appear unobtainable.
On 07/12/2023 11:22, 'Rainer Lang' via weewx-user wrote:
Not sure wha
Not sure what you mean by "compatible" here - but beyond Davis there is
a whole station/sensor/IoT universe
Have a look at https://www.ecowitt.com
and for a better understanding
https://www.wxforum.net/index.php?topic=40730
all these stations can be used with weewx with either the Ecowitt local
Hi Marlon
three more remarks:
1. comparing to neighbouring environment may not always be helpful - as
rainfall is not a homogeneous phenomenon and 100 m away from your sensor
there may even be no rainfall at all - or vice versa. A proper manual
gauge close to your sensor makes more sense.
2.
summary data shown on the ecowitt.net dashboard are the values from the
console and can be changed by the user in the console. At ecowitt.net no
summarizing is done for the displayed tiles, just display of what the
console sends. What is shown there is user responsibility. If the user
makes adj
I have no idea why it should be 800+ mm
I did the work deleting all 0.0 mm value records and left for non 0.0
days only the last record (usually either 18:00 or 22:00 whatever was
available)
and added them all up - result: 507.2 mm as opposite to the 470.2 mm
shown in your graph and NOAA. Not 8
can you remove all lines with ";;" from the import CSV file
and start the import again (I assume you still have an untouched copy of
your database),
re-create the NOAA reports and check again ...
The NOAA reports from your web site is the only place where I could
compare the import
1. as Gary (@gjr80) already mentioned - send us your import.conf file
for the CSV import and maybe 5 lines of your import CSV file including
the first line with the descriptors
2. did you run the daily summary update after the import ?
sudo wee_database .. from= to= (see wee_database --h
And, to improve your knowledge of your weather station, I recommend
reading the WiKi at
https://www.wetterstationsforum.info/wiki/doku.php?id=wiki:wetterstationen:ecowitt-stationen
if you understand German (the Froggit brand may point to that).
If not, try https://www.wxforum.net/index.php?topic=
I think you have to understand better how weewx works:
even if you set a archive interval of 300 seconds (5 minutes), each data
packet sent by your console every 16 seconds (shorter doesn't make sense
for you anyway as the outdoor sensor array only transmits every 16
seconds) is processed by we
a) you should use an interceptor driver version which cleanly handles
all your sensors - and also those you don't have
the original version on GitHub was never extended and is a crippled
version from a today's point of view as it covers the basic sensors only
and its exclusion field-map is incom
the download from the Ecowitt cloud is not fully based on their public
http-API - it rather offers a "canon ball" solution as the author says
for details about the API see https://doc.ecowitt.net/
if you want to develop your own thing or create a more specific solution
using the accounts APP an
you can install (unless already installed) the ncdu tool:
sudo apt-get install ncdu
and you'll have to run it in the root directory in a console window on
your RPi
it will give you a nice and complete overview which directories use
which storage capacity down to the files
On 18.10.2023 13:57,
it appears that the console you are connected to (IP 192.168.50.41) is
NOT a console with the Ecowitt local Gateway API (aka GW1000 API) but
another console
with the WiFi firmware EasyWeatherPro_V5.1.3
e.g. a HP25x0 console with the new WiFi modem.
Therefore the GW1000/Ecowitt API driver canno
I meant of course
set *debug = 3*
Forwarded Message
Subject:Re: [weewx-user] Re: Cannot get weewx + gw1000 working
Date: Tue, 17 Oct 2023 15:32:48 +0200
From: Rainer Lang
To: weewx-user@googlegroups.com
it's difficult to follow what you are/were doing - it
it's difficult to follow what you are/were doing - it would be helpful
if you
a) provided us with a copy of your weewx.conf (you can your
passwords if there are any)
b) set your station to GW1000
c) set debug = 0
d) provided the complete syslog from weewx startup until either the 1st
repor
correct - the API description has 0x03, 0x04 and 0x05 for dew point,
wind chill and heat index, but the GW1x00/GW2000/WN19x0
consoles/gateways do not calculate them for the API response -
therefore, until now, 0x03 thru 0x05 won't be found in an API response.
The live data view of the WS View (
nothing is "amiss" in the "WS90 software", whatever you mean by this.
I think you have a wrong understanding of the hardware you are using and
its (assumed) capabilities.
1. Tom's hint will solve your issue in weewx, as the observations you
are asking for are not primary observations but deriv
sent my reply only privately by mistake - here for the group to benefit
to the group too
Forwarded Message
Subject:Re: [weewx-user] Correct data in weewx.sdb
Date: Tue, 19 Sep 2023 13:58:30 +0200
From: Rainer Lang
To: bgra...@umw.edu
the easiest way imo is
if you are going for a Ecowitt (clone) station, - look up
https://www.wxforum.net/index.php?topic=40730.0 to see what's available
from them these days and what they are able to do - then weewx will be
able to read their data which they all send via WLAN ("WiFi") to the
local network and/or the
to calibrate your WS-1001 (Ambient version of the FineOffset/EcowittWH24
outdoor array and the WH1080 console) you could just follow the
instructions in https://www.wxforum.net/index.php?topic=40730.0 chapter 6
determine the offset and enter it accordingly (either an offest of
change the value,
yes - why not calibrate your console first
when you see that the offset between absolute and relative pressure for
your location used is wrong, just adjust it 😎
the the first basic step I'd say
even though, when your absolute (=local) pressure reading is correct,
and your have the weewx option
see inline below
On 15.08.2023 13:25, gert.a...@gmail.com wrote:
Hi Rainer
I did as you suggested and it seems to work now. gw1000.py was not
there, so something went wrong during the installation.
A couple of questions:
1) I used sudo to install and WeeWX is running under root. Should I
jus
I think a simple solution could be to extract the file gw1000.py from
the gw1000-0.5.0b5.tar.gz archive and copy it to /usr/share/weewx/user
On 15.08.2023 10:42, gert.a...@gmail.com wrote:
Hi Ian
Thanks for looking.
I used this command to install WeeWx:
sudo apt install ./python3-weewx_5.0.0a2
FULL
the others have a 5 or 6 tier status information
those with voltage can be simply display "as is": x.x V
On 14.08.2023 12:38, Greg Troxel wrote:
"'Rainer Lang' via weewx-user" writes:
the driver only collects the data provided by the gateway API - and if
the driver only collects the data provided by the gateway API - and if
you have created corresponding fields and assignments, weewx stores this
data in the data base. That's it.
There is no further code as far as I am aware of.
Can you tell what exactly you want to do ?
Display the codes as hum
If the predefined unit of a database field changes (i.e. you want it to
be changed), weewx needs to be told how to interprete the value stored
in this field.
Entries in extensions.py will override the default unit definitions
weewx keeps in a table at runtime (the obs_group_dict).
E.g.
you hav
in principle all seems to be correct in weewx.conf
now, how to check the database: get yourself the sqlitebrowser and look
it up yourself
sudo apt-get install sqlitebrowser
you will have to load your database and you can see everything, all
records etc.
but you may have a unit problem as
l=16'
--
Jason Marshall Thomas
On Sun, Aug 6, 2023 at 11:15 AM 'Rainer Lang' via weewx-user
wrote:
in my understanding you don't need this field map extension below
as it is already contained in the interceptor.py (driver).
The only extension you need is
ed parameter gain50_piezo=1.00
Aug 6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor:
unrecognized parameter wh90batt=3.16
Aug 6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor:
unrecognized parameter interval=16'
--
Jason Marshall Thomas
On Sun, Aug 6, 2023 at 11:15 AM &
in my understanding you don't need this field map extension below as it
is already contained in the interceptor.py (driver).
The only extension you need is
[[sensor_map_extensions]]
rain = drain_piezo
rainRate = rrain_piezo
supplyVoltage = wh90batt
refe
your location data you can get out of weewx 😉
On 29.07.2023 22:11, Stefan Gliessmann wrote:
That would work. But I would miss out on the location and elevation
data … I would like to include location in a database …
p q schrieb am Sa. 29. Juli 2023 um 20:25:
Why not use the same one and
You can get a GW1100 which comes already with an inbuilt indoor T/H
sensor, a WH32 outdoor for the outdoor T/H and maybe, if you need more,
another WH31 extra T/H sensor.
An external 3-in-1 sensor doesn't exist in the Ecowitt universe. Indoor,
yes, but a GW1100 cannot receive it.
And then run we
You probably gave your new plot a new different name - and have
forgotten to display it also in index.html.tmpl 😎
On 27.07.2023 20:13, DR wrote:
I have had 4.5.1 running on a Rasp Pi 4 for over a half a year. Not a
glitch.
I wanted to add to the Seasons Skin an additional plot. The stock
pa
you are free to do whatever you want...
You can even disable the rsyslog service completely and have no logging
at all.
However, turning off logging is not a very smart approach, and thinking
you can turn logging on again "when it's needed" is imho rather naive
thinking. When an application (an
maybe weewx is not the culprit
did you set the piezo rain priority in your GW1100 ? (-->Rain totals -->
Rainfall data priority --> Piezoelectric Rain Gauge)
On 24.07.2023 16:38, didier belin wrote:
Despite modifying weewx.conf , as quoted in another post
weewx.conf
poll_interval
the fields are oblivious of how the data stored was achieved (min, max,
avg, sum ...).
This is defined in the accumulators for the weewx field map - and if
your new variable is not contained or you want a different way from the
default accumulator behaviour, you have to add this to the [Accumula
you have to do some proper network analysis - this whole story is
neither a GW1000 nor a weewx issue.
And I doubt that "just out of the air" it all stopped and went wrong.
Something must have (been) changed in the network configuration.
"Upgraded the GW1000 firmware"
that means you must have use
the message is clear:
DEBUG user.gw1000: Failed attempt 1 to send command
'CMD_READ_STATION_MAC': [Errno 101] _*Network is unreachable*_
_you have an issue reaching your GW1100 from the weewx server_
at first glance that's neither a weewx nor a GW1100 issue - it looks
like an issue in your lo
can you see the live data in the WS View Plus app or in the
WebUI/embedded webpage (IP address of your GW1100 in the browser URL
field) ?
maybe the IP of your GW1100 changed, which won't keep it from posting to
ecowitt.net, but if it is now different from what is written in
weewx.conf, weewx
Assuming you assign your WH51 sensors to the SoilMoist1 thru SoilMoist4
database fields, be via a fieldmap extension or a
StdCalibrate/Corrections entry in weewx.conf,
you will also have to add some changes to extensions.py (in
/usr/share/weewx/user or /home/weewx depending on your installa
Another option I could suggest for this antiquarian piece of a weather
station (it's imho a shame that such old hardware is still being sold -
but probably the sellers want to empty their stock - when technology has
made already big leaps ahead for 5+ years) would be to get yourself a
modern Ec
can you please post your syslog after restarting weewx with debug = 3 in
weewx.conf from the weewx restart until at least the first archiving
cycle and report generation (so it ever completes) is finished
thanks
On 17.07.2023 17:53, Stefan Gliessmann wrote:
I have read the link above and made
Maybe you send us a complete excerpt from your syslog covering the weewx
startup and at least one archiving period
That would be more helpful than just a few snippets.
Thanks
On 17.07.2023 11:02, 'neu...@bnjpro.dk' via weewx-user wrote:
I have been the happy user of weeWX for a very long time n
that's an option
but keep your Skin files (rename your skin directory) and weewx.conf so
you can cannibalize on them when doing a complete new install - and, of
course, keep your weewx.sdb 😉 (safety copy).
You may need to download a new updated driver/extension for your
Tempest, too.
On 10.07
try
sudo |pip3 install --upgrade requests|
|if pip3 is not installed, do it before
|
|sudo apt-get -y install python3-pip|
|
|
|
|
||
On 10.07.2023 18:50, mukbar wrote:
Hello,
Have lurked here for years. Many folks have been invaluable in helping
me set up https://sanpedrowx.com/.
I am
and that's more than enough for the Ecowitt console(s) to post their
data to weewx 😎
(apart from the possibility to introduce specific firewall rules on
specific ports 😉)
On 22.06.2023 20:52, metalmi...@gmail.com wrote:
Because the server is in a different subnet than my LAN.
Let's say the se
just technically speaking:
if your server stands in a DMZ, it has a internal LAN side and an
external WAN side.
You should be able to access the server (and an application running on
it) from the internal LAN side.
Then, why do you need an extra WLAN access point at the server/ VM ?
I'm not say
sorry to say that but you are just trading subjective non-representative
opinions regarding Ecowitt (and clone) stations and hardware
modern Ecowitt stations have proven to be quite reliable and to compare
an ancient WH1080 with the modern Fine Offset / Ecowitt hardware is like
comparing a yea
it seems you posted the same question in the German Weather Forum
https://wetterstationsforum.info
There you already got the suggestion to read their WiKi section about
Ecowitt (clone) weather stations:
https://www.wetterstationsforum.info/wiki/doku.php?id=wiki:wetterstationen:ecowitt-stationen
1 - 100 of 163 matches
Mail list logo
