WeeRT - realtime interface to weeWX

[Thomas Keffer]

This is something I've been fiddling with for quite a while: a realtime display for weeWX.

Live demo.

Github repository.

It consists of a Node server running Express, an InfluxDB database, and a React client that uses Redux for state management.

Please, please, please: do not attempt to install and get running unless you are very experienced with Linux and, preferably, Javascript, Node, InfluxDB, and npm. Expect a very steep learning curve. I would love contributions, but I simply do not have the time for any hand holding. 

Cheers,

-tk

[bell...@gmail.com]

I continue to be impressed by all things Weewx. After finally upgrading WeeWX (easy) and struggling with upgrading node, I was able to get this up and running. I have limited experience with the technology being used, but have experimented with node some. I’m currently working on understand InfluxDB, but hope to be able to help some.
As an aside, I think on aggregation, a NEW_AGGREGATE event is created and the test expects a a NEW_AGGREGATION event.
- rich

[Thomas Keffer]

Right you are! Good sleuthing!

Fixed in commit a0045078cc.

I also have limited experience with Node, React, etc., but it has been a great learning experience playing with them.

What kind of weather station do you have WeeRT running on?

-tk

[Rich Bell]

I have a VP2. It’s been hooked up to WeeWX via the usb logger for about 2 years.  I spent some time before that struggling to get a robust set up (hw, not WeeWX) and life got in the way, etc. I’ve been lurking on the groups during those years.  Currently everything is not public. But I have been experimenting with a rest Api to a .net core server in Azure.  Also played some with D3 to graph it. 

I did hack together something to import my archive datainto InfluxDB   Needs a lot of work, but maybe I can start out on that issue you have opened.  

I also got Istanbul running, to help me get a handle on the current tests.  Again, a bit of a hack... 

-rich 

[Maarten van der Hoeven]

Hi,

It seems the demo is not available at the mentioned URL. Is there someone else who has the realtime display of Weewx running, before I dig into it myself?

Op donderdag 5 april 2018 23:46:22 UTC+2 schreef Tom Keffer:

[Thomas Keffer]

It has moved to here: http://threefools.org:3000/

-tk

[Bill Morrow]

On Friday, 22 June 2018 09:10:22 UTC-3, Tom Keffer wrote:

It has moved to here: http://threefools.org:3000/

I started installing weert, and noticed that it listens on port 3000. I already have grafana (a graphical frontend for influxdb) on port 3000.  It looks easy enough to move grafana's port. 

Any opinion, Tom? 

weert looks nice. Also a good chance to explore some technology (javascript et al) foreign to me.

[Thomas Keffer]

Hi, Bill

You can use any port you want. It's set in file server/config/config.js, under the 'server' key:

  // Configuration info for the WeeRT server itself
  server: {
    port: 3000,
    api: "/api/v1"
  },

-tk

[Kimmo Linna]

Hi,

Looks really great. I hope I find some time to change InfluxDB to kdb+ which is free for non-commercial use. The performance is quite fast also in Raspberry Pi (https://kx.com/blog/benchmarking-kdb-raspberry-pi/).

Have you tried Rickshaw.js for realtime graphing?

Best regards,

Kimmo 

--

--- Kimmo Linna Lansantie 23a A 9 02630 ESPOO Kimmo...@gmail.com +358 40 590 1074

[Thomas Keffer]

First I've heard of kdb+. Looks interesting. InfluxDB is also free (as well as open source). The biggest problem I've had is that InfluxDB is not time zone aware. It would be nice to be able to do queries for, say, midnight to midnight, where the database worries whether there is a DST transition in there. Can kdb+ do something like that?

I probably tried half a dozen different charting libraries. I wanted something

1. that was being actively developed;
   
2. could handle real-time updates;
   
3. used SVG (not canvas); and
   
4. was compatible with React.
   

The problem with Rickshaw, and other D3-based libraries, is that D3 wants to control the DOM and so does React. There are kludges to get around this, but they not very elegant. So, I ended up going with Recharts, which is a React-based library. Unfortunately, since that decision (last winter), there have been no updates to it, so it may be dead, violating requirement #1 above.

I'm thinking of switching to react-vis.

Life on the bleeding edge...

-tk

[Bill Morrow]

Thanks Tom. I made the configuration change you suggest, to stay away from grafana's use of port 3000.

I had version 0.10 of influxdb installed, which is the default for my version of linux mint. weert needs a newer version. Upgrading from there to a modern version was painful. I ended up completely deleting it and installing version 1.5.4. I made one change to influxdb's config, unrelated to weert but an unkind default in my opinion:

# Once every 24 hours InfluxDB will report usage data to usage.influxdata.com
# The data includes a random ID, os, arch, version, the number of series and other
# usage data. No data from user databases is ever transmitted.
# Change this option to true to disable reporting.
reporting-disabled = true

Initially, data was not getting to influxdb. I eventually found my mistake by using a verbose curl command to see the details of a post from weewx to the weert server 

curl -v -u weert:xxxxxxx -i -X POST -H Content-type:application/json -d '{"timestamp": 1529895217000, "tags": {"platform": "default_platform", "stream": "default_stream"}, "fields": {"gauge_pressure": 1002.6683035778668,"out_temperature":16.470000000000002,"heatindex_temperature": 16.470000000000002, "altimeter_pressure": 1009.5370707366749, "windchill_temperature": null, "dewpoint_temperature": 13.326693680497735, "extra1_temperature": 16.63, "unit_system": 17, "out_humidity_percent": 81.69, "sealevel_pressure": 1009.68, "y_wind_speed": null, "x_wind_speed": null, "wind_dir": null}, "measurement": "wxpackets"}' http://localhost:3001/api/v1/measurements/examples/packets

Note: Unnecessary use of -X or --request, POST is already inferred.

*   Trying 127.0.0.1...

* Connected to localhost (127.0.0.1) port 3001 (#0)

* Server auth using Basic with user 'weert'

> POST /api/v1/measurements/examples/packets HTTP/1.1

> Host: localhost:3001

> Authorization: Basic d2VlcnQ6Y3Jhd2xzcGFjZQ==

> User-Agent: curl/7.47.0

> Accept: */*

> Content-type:application/json

> Content-Length: 545

> 

* upload completely sent off: 545 out of 545 bytes

< HTTP/1.1 403 Forbidden

HTTP/1.1 403 Forbidden

< X-Powered-By: Express

X-Powered-By: Express

< Content-Type: text/html; charset=utf-8

Content-Type: text/html; charset=utf-8

< Content-Length: 12

Content-Length: 12

< ETag: W/"c-dAuDFQrdjS3hezqxDTNgW7AOlYk"

ETag: W/"c-dAuDFQrdjS3hezqxDTNgW7AOlYk"

< Vary: Accept-Encoding

Vary: Accept-Encoding

< Date: Mon, 25 Jun 2018 11:44:16 GMT

Date: Mon, 25 Jun 2018 11:44:16 GMT

< Connection: keep-alive

Connection: keep-alive

Once I corrected the password set in weert-js/server/config/config.js to match the setting in the [weert] clause of weewx.conf and restarted both, data started showing up in influxdb, and in weert's web page. 

I was surprised that weert's server is processing packets going back to the last time I started weewx - about 8 hours ago from when I gave up last night. It's catching up at about 20 times real time. This is on a generic PC with about 8000 bogomips. Together node, influxd and python are consuming about 20% of the CPU.

[Thomas Keffer]

Sounds like you've got it working!

The WeeRT uploader uses the regular WeeWX uploading machinery (in file restx.py), which has a queue. If it is unable to successfully post something, it queues up until it can. The max size of the queue is set by option max_backlog, which, by default, is infinite. It can be changed

[WeeRT]

    ...

    max_backlog = 3600   # = one hour

All the uploaders work this way.

-tk

[Thomas Keffer]

Bill, give the latest commit a try.

It can assemble a full packet from a set of partial packets. I don't have a station that emits partial packets, so I'm eager for someone to give it a try.

-tk

On Mon, Jun 25, 2018 at 11:22 AM Thomas Keffer <tke...@gmail.com> wrote:

I actually found the tutorials that come with Redux to be pretty useful. You want to build towards the 'async' tutorial, which is the first realistic application of Redux. 

It can get confusing, but underlying it all is a very simple concept: the "reduction" process means you take an immutable data structure or "state", apply an action, and end up with another immutable state. That means very simple state changes: two read-only inputs, one read-only output. It makes debugging complicated programs very easy. 

But, I don't claim to be an expert at this. 

-tk

On Mon, Jun 25, 2018 at 10:54 AM Bill Morrow <morr...@gmail.com> wrote:

Had a quick look in to the javascript side of weert. I see what you are describing with NEW_PACKET actions, reducers, and other such voodoo! I have a steep learning curve ahead of me.

On Mon, Jun 25, 2018 at 1:47 PM Bill Morrow <morr...@gmail.com> wrote:

I was just looking at the loop_filters in weert.py. Could I do something with those?

There's a number of ways of implementing this. My first thought is to create a new reducer method, which on every NEW_PACKET action, scans the internal data structures, constructing a full packet, then emitting it as a new action, call it NEW_FULL_PACKET. React would then subscribe to this (instead of NEW_PACKET). 

This would belong in the neighborhood of the get_post_body method in weert.py? Not sure if this will get to the top of the priority list, but I'll think about it a bit anyway.

On Mon, Jun 25, 2018 at 1:22 PM Thomas Keffer <tke...@gmail.com> wrote:

Yes, the "N/A" current values is likely to be the same problem: the most recent packet consists of mostly null values. 

I can imagine two fixes:

1. The WeeWX uploader caches values, creating full packets before sending them off to WeeRT. This is what the Weather Underground uploader already does, so it's an easy fix.

2. The "current value" component shows the most recent non-null value for each observation type. This would also be fairly easy to do. 

I think I prefer solution #2. I don't like the idea of messing with the data-of-record. This keeps the data intact, and just affects the display.

There's a number of ways of implementing this. My first thought is to create a new reducer method, which on every NEW_PACKET action, scans the internal data structures, constructing a full packet, then emitting it as a new action, call it NEW_FULL_PACKET. React would then subscribe to this (instead of NEW_PACKET). 

It will be a while before I get a chance to look at this, but if you want to give it a try...! 

-tk

On Mon, Jun 25, 2018 at 8:52 AM Bill Morrow <morr...@gmail.com> wrote:

I'm not immediately concerned about the plots, more the left pane "Current values". They're a bit behind wall clock time and except for the first packet, the values are "N/A". Even though the developer console suggests real values are coming in.

I like your theory on the partial packets. The last packet that arrives in a burst is probably all NULLs.

On Mon, Jun 25, 2018 at 10:39 AM Thomas Keffer <tke...@gmail.com> wrote:

Yes, it is rather chatty! Each new packet triggers a new action. So, the console shows the state of the internal data structures before the action, the action itself, and the state after the action. 

Looking at your website, the packets are coming in, and the data structures are getting updated, but the new data points are not showing up on the graphs.

I suspect the problem is either the unit system you're using (METRICWX), or (more likely) the partial packets emitted by your weather station. I have only tested WeeRT with a VantagePro2, which emits full packets.

The partial packets means there will be a lot of nulls in the time-series vector that it's trying to plot. This may result in react effectively plotting a lot of (invisible) points, not lines. Mousing over the plots shows the invisible points.

Try going into client/config/componentConfig.js and add an option connectNulls:

export const plotOptions = {

  width: "95%",

  height: 200,

  margin: { top: 5, right: 5, left: 5, bottom: 5 },

  nXTicks: 5,

  type: "linear",

  connectNulls : true,

  ...

}

See if that does anything. I've found a lot of bugs in recharts, so it wouldn't surprise me if this didn't work.

-tk

On Mon, Jun 25, 2018 at 8:16 AM Bill Morrow <morr...@gmail.com> wrote:

On Mon, Jun 25, 2018 at 9:46 AM Thomas Keffer <tke...@gmail.com> wrote:

Sounds like a WebSocket issue. Try opening up the "debugging" window on your browser (Ctrl-Shift-I on Chrome) and look on the console. It may give you some clues as to what's happening.

There's a lot of traffic. A new packet every 0.5 seconds?

action NEW_PACKET @ 10:14:25.708

main.js:21 prev state

1. {selectedTags: {…}, selectedTimeSpan: "recent", timeSpans: {…}, stats: {…}}

main.js:21 action

1. {type: "NEW_PACKET", measurement: "wxpackets", packet: {…}}
1. measurement:"wxpackets"
2. packet:{timestamp: 1529939663000, out_temperature: 11.270000000000001, extra2_temperature: 33.6, extra1_temperature: 12.41, unit_system: 17, …}
3. type:"NEW_PACKET"
4. __proto__:Object

main.js:21 next state

1. {selectedTags: {…}, selectedTimeSpan: "recent", timeSpans: {…}, stats: {…}}

main.js:21 action NEW_PACKET @ 10:14:25.735

This may be a side effect of the rate I am bombarding weewx with my wxMesh driver. 

Is the WeeRT server exposed to the outside world? If so, I can try taking a look.

 

Just opened it: http://east.themorrow.net:3001/

 

[Bill Morrow]

I committed my personal settings in server/config/config.js, then did a 'git pull'. Restarted the weert server and weewx.

It looks like basically the same behavior. If I refresh the page, the current values show nicely. Then some new websocket traffic comes in, the Current Values all change to N/A and stay that way. The Charts work fine.

In the Chromium developer tools console, I see partial packets coming in. The same data seems to be pushed over repeatedly?

...
action

1. {type: "NEW_PACKET", measurement: "wxpackets", packet: {…}}

1. measurement:"wxpackets"
2. packet:{timestamp: 1530277846000, out_temperature: 16.52, extra2_temperature: 34.2, extra1_temperature: 17.219999999999995, unit_system: 17, …}
3. type:"NEW_PACKET"

...


these are all for the same time stamp, and all the same data?

action

1. {type: "NEW_PACKET", measurement: "wxpackets", packet: {…}}

1. measurement:"wxpackets"
2. packet:{timestamp: 1530278448000, unit_system: 17}
3. type:"NEW_PACKET"

...
action

1. {type: "NEW_PACKET", measurement: "wxpackets", packet: {…}}

1. measurement:"wxpackets"
2. packet:{timestamp: 1530278448000, extra1_temperature: 17.18, unit_system: 17, sealevel_pressure: 1010.89}
3. type:"NEW_PACKET"
   ...

...
action

1. {type: "NEW_PACKET", measurement: "wxpackets", packet: {…}}

1. measurement:"wxpackets"
2. packet:{timestamp: 1530278448000, out_temperature: 16.24, extra1_temperature: 17.18, unit_system: 17, sealevel_pressure: 1010.89, …}
3. type:"NEW_PACKET"

...
action

1. {type: "NEW_PACKET", measurement: "wxpackets", packet: {…}}

1. measurement:"wxpackets"
2. packet:{timestamp: 1530278448000, wind_speed: 0, out_temperature: 16.24, windchill_temperature: 16.24, extra2_temperature: 34.2, …}
3. type:"NEW_PACKET"

[Bill Morrow]

It looks like the partial packets are getting assembled in influxdb. in_temperature is coming from an indoor sensor every 20 seconds. out_temperature is coming from a separate outdoor sensor every second or so. I should actually reduce the frequency of the latter. I have been stress testing the solar power generation.

$ influx
> precision rfc3339
> use weert;
Using database weert
> SELECT time,out_temperature, in_temperature FROM h24.wxpackets order by time desc limit 10;
name: wxpackets
time                 out_temperature    in_temperature
----                 ---------------    --------------
2018-06-29T13:47:55Z 16.22              24.099999999999998
2018-06-29T13:47:35Z 16.209999999999997 24.11
2018-06-29T13:47:15Z 16.209999999999997 24.119999999999997
2018-06-29T13:46:55Z 16.22              24.13
2018-06-29T13:46:35Z 16.22              24.119999999999997
2018-06-29T13:46:15Z 16.22              24.11
2018-06-29T13:45:55Z 16.2               24.11
2018-06-29T13:45:35Z 16.22              24.11
2018-06-29T13:45:15Z 16.24              24.11
2018-06-29T13:44:55Z 16.28              24.119999999999997

[Andy]

The 5 minute view does not show lines for the data, but if you mouse over you see the data points.

[Andy]

The day view looks correct

[Andy]

And some version info 

influxdb/unknown,now 1.5.2-1 amd64 [installed]

nodejs/unknown,now 8.11.3-1nodesource1 amd64 [installed]

root@weert:~/weert-js# cat /etc/debian_version 

9.4

root@weert:~/weert-js# uname -a

Linux weert 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux

[Andy]

> SELECT time,out_temperature, in_temperature FROM h24.wxpackets order by time desc limit 10;

name: wxpackets

time                 out_temperature in_temperature

----                 --------------- --------------

2018-07-01T22:37:45Z 84.56           

2018-07-01T22:37:42Z                 70.88

2018-07-01T22:37:30Z 84.56           

2018-07-01T22:37:25Z                 70.88

2018-07-01T22:37:13Z 84.92           

2018-07-01T22:37:08Z                 70.88

2018-07-01T22:36:57Z 84.92           

2018-07-01T22:36:51Z                 70.88

2018-07-01T22:36:41Z 84.92           

2018-07-01T22:36:34Z                 70.88

[Thomas Keffer]

Andy, a couple of questions:

What kind of weather station?

Which commit of WeeRT are you running?

-tk

[Andy]

Using the SDR drive pulling from various devices which emit packets at different times.  Made the change suggested above (connectNulls : true,) but did not make any different.  There is no pressure sensor at this time also.  I set this up to help with the weert testing.

Andy

    [[sensor_map]]
        windDir = wind_dir.0A66.Acurite5n1Packet
        windSpeed = wind_speed.0A66.Acurite5n1Packet
        outTemp = temperature.18A8.AcuriteTowerPacket
        outHumidity = humidity.18A8.AcuriteTowerPacket
        #outTemp = temperature.0A66.Acurite5n1Packet
        #outHumidity = humidity.0A66.Acurite5n1Packet
        rain_total = rain_total.0A66.Acurite5n1Packet
        #rain_since_reset.0A66.Acurite5n1Packet
        inTemp = temperature.3067.AcuriteTowerPacket
        inHumidity = humidity.3067.AcuriteTowerPacket

root@weert:~/weert-js# git log
commit ec6b53008d8ecaffcad7caffefc52951cbc9ba87

[Thomas Keffer]

I don't know if it will make any difference, but could you try the latest commit 3041e638? 

At least, then, we won't be chasing old bugs.

-tk

[Andy]

root@weert:~/weert-js# git pull

remote: Counting objects: 12, done.

remote: Compressing objects: 100% (7/7), done.

remote: Total 12 (delta 5), reused 12 (delta 5), pack-reused 0

Unpacking objects: 100% (12/12), done.

From https://github.com/tkeffer/weert-js

   ec6b530..3041e63  master     -> origin/master

Updating ec6b530..3041e63

Fast-forward

 client/src/containers/AppContainer.js | 12 ++++++++----

 1 file changed, 8 insertions(+), 4 deletions(-)

root@weert:~/weert-js# git log
commit 3041e6380bc933dec912ea2a26242dbeb1b3994e
Author: Tom Keffer <tkeffer@gmail.com>
Date:   Sun Jul 1 07:38:57 2018 -0700

root@weert:~/weert-js# npm install
root@weert:~/weert-js# npm start  #seperate window actually running in screen

root@weert:~/weert-js# npm test

> we...@0.5.0 test /root/weert-js

> jasmine --config=spec/support/jasmine.json

Started

.....................

21 specs, 0 failures

Finished in 1.17 seconds

root@weert:~/weert-js/client# npm install
root@weert:~/weert-js/client# npm run build

The data plotting behavior has not changed with this update

Andy 

[Thomas Keffer]

Thanks.

Can you put your site online, at least temporarily? 

-tk

[Andy]

andylittle.ddns.net:3000

[Thomas Keffer]

Thanks, Andy

You have a lot of null values in the plots. By default, the charting package (Recharts) does not connect null values. This behavior can be overridden by going into file config/componentConfig.js, data structure plotOptions, and adding a new option connectNulls and setting it to true:

export const plotOptions = {

  width: "95%",

  height: 200,

  margin: { top: 5, right: 5, left: 5, bottom: 5 },

  nXTicks: 5,

  type: "linear",

  connectNulls : true,

  ...

}

Bill had the same problem (see earlier in the thread) and it solved it for him.

Perhaps this should be the default...

-tk

On Mon, Jul 2, 2018 at 6:37 AM Andy <rockl...@gmail.com> wrote:

andylittle.ddns.net:3000

[Thomas Keffer]

I just did a commit that makes connectNulls true by default.

-tk

[Andy]

Still the same behavior with latest commit.

  animationDuration: 500,

  connectNulls: true, // Connect null data values

  dot: false,

[Thomas Keffer]

I think this must be a limitation in the charting package, Recharts.

The data in the plot lines contains a lot of missing data. That is, the value is not null, it's just plain missing. I'm guessing that Recharts won't connect lines across missing data --- only null values.

A workaround is to filter out data points with missing data. Let me try that.

-tk

[Thomas Keffer]

OK, give the latest commit a try.

I'm not entirely happy with this fix because each plot can see a different set of data points. But, I think it will work out.

-tk

[Andy Little]

that got it working

[Thomas Keffer]

Good.

I guess we don't need connectNull any longer, as there are no nulls to connect.

-tk

[Andy]

connectNulls is gone from config and client rebuilt. Access is tightened down a bit, but you and Bill should still be able to see it.  Let me know when you want to test anything on it.

[Cyril D]

I have been also interested in having a real time display of the information sent by the station.

I use node-RED on the Raspberry Pi to handle that.

It's probably easier in my configuration, as I receive the data from RFXcom and generate a file with the data.

Weewx upload this file via fileparse, and node-RED reads that same file every time it is updated.

It's not difficult to create this, mainly via GUI. Here is how it looks in the background:

[Thomas Keffer]

First time I've heard of Node-RED. Looks interesting. For years people have been trying to create effective "visual programming" tools. Perhaps IBM has finally succeeded!

-tk

[Thomas Keffer]

Just discovered an error that causes wind direction to be N/A in the wind compass, when assembling a packet from partial packets.

Pull, rebuild the client, redeploy.

-tk

[Vince Skahan]

On Wednesday, August 8, 2018 at 6:23:38 AM UTC-7, Tom Keffer wrote:

First time I've heard of Node-RED. Looks interesting. For years people have been trying to create effective "visual programming" tools. Perhaps IBM has finally succeeded!

Here's a dashboard I cooked up today, reading two MQTT topics, one 'weather/#' put out from weewx MQTT extension, the other one I cooked up to measure the temperature on an outside TV room.....

[Maarten van der Hoeven]

Hi,

I've taken notice of the remark about a steep learning curve. However, I've installed all according to the manual, and I see data posted (trail of ndm with posted data every second or so) and data populated into the influx database.

However, when I access the webpage (http://localhost:3000) I got:

WeeRT server

Page not found: /

Status: 404

Error: Page not found: /
    at /home/maarten/git/weert-js/server/server.js:107:17
    at Layer.handle [as handle_request] (/home/maarten/git/weert-js/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/home/maarten/git/weert-js/node_modules/express/lib/router/index.js:317:13)
    at /home/maarten/git/weert-js/node_modules/express/lib/router/index.js:284:7
    at Function.process_params (/home/maarten/git/weert-js/node_modules/express/lib/router/index.js:335:12)
    at next (/home/maarten/git/weert-js/node_modules/express/lib/router/index.js:275:10)
    at SendStream.error (/home/maarten/git/weert-js/node_modules/serve-static/index.js:121:7)
    at emitOne (events.js:116:13)
    at SendStream.emit (events.js:211:7)
    at SendStream.error (/home/maarten/git/weert-js/node_modules/send/index.js:270:17)

What would be a logical place to look into to?

Op donderdag 5 april 2018 23:46:22 UTC+2 schreef Tom Keffer:

This is something I've been fiddling with for quite a while: a realtime display for weeWX.

Live demo.

Github repository.

It consists of a Node server running Express, an InfluxDB database, and a React client that uses Redux for state management.

Please, please, please: do not attempt to install and get running unless you are very experienced with Linux and, preferably, Javascript, Node, InfluxDB, and npm. Expect a very steep learning curve. I would love contributions, but I simply do not have the time for any hand holding. 

Cheers,

-tk

[Maarten van der Hoeven]

Sorry, not completed my message. I am quite experienced at Linux, so I understand the pointers to look into.

This one (http://localhost:3000/api/v1/measurements/wxpackets/packets) gives (all valid data):

[{"tags":{"platform":"default_platform","stream":"default_stream"},"fields":{"altimeter_pressure":1019.5373185962048,"console_voltage":3.83,"dewpoint_temperature":8.515007214898198,"extra1_temperature":11.666666666666666,"gauge_pressure":1019.3588138825883,"heatindex_temperature":11.666666666666666,"in_humidity_percent":58,"in_temperature":21.5,"out_humidity_percent":81,"out_temperature":11.666666666666666,"radiation_radiation":308,"rain_rain":0,"sealevel_pressure":1019.8446579091847,"unit_system":16,"uv_uv":0.8,"wind_dir":234,"wind_speed":22.530872000139194,"windchill_temperature":11.666666666666666,"x_wind_speed":-18.22785834619927,"y_wind_speed":-13.243314282971237},"timestamp":1542106655000},{"tags":{"platform":"default_platform","stream":"default_stream"},"fields":{"altimeter_pressure":1019.5373185962048,"console_voltage":3.83,"dewpoint_temperature":8.515007214898198,"extra1_temperature":11.666666666666666,"gauge_pressure":1019.3588138825883,"heatindex_temperature":11.666666666666666,"in_humidity_percent":58,"in_temperature":21.5,"out_humidity_percent":81,"out_temperature":11.666666666666666,"radiation_radiation":308,"rain_rain":0,"sealevel_pressure":1019.8446579091847,"unit_system":16,"uv_uv":0.8,"wind_dir":246,"wind_speed":25.749568000159073,"windchill_temperature":11.666666666666666,"x_wind_speed":-23.523400882804587,"y_wind_speed":-10.473292849036753},"timestamp":1542106657000},{"tags":{"platform":"default_platform","stream":"default_stream"},"fields":

Op dinsdag 13 november 2018 13:51:06 UTC+1 schreef Maarten van der Hoeven:

[Thomas Keffer]

I suspect that either you did not build the client, or you had an error while building it. Take a look in the directory weert-js/client/dist and make sure it includes files index.html and and main.js. Both are created as part of the build process. For instructions on building the client, see the section Building and running the client in the README.

-tk

[Maarten van der Hoeven]

Hi Tom,

You were right, the build failed. Must have been overlooked when I was fetching some coffee. I started all over again, and watched it clolsely. Regarding the client, the setp 'npm install' succeeded (toook some long time). However, 'npm run build' failed. See track stace below. npm is at version 3.5.2, nodejs is at version 8.10. Running Ubuntu 18.04 LTS, 64 bit

0 info it worked if it ends with ok
1 verbose cli [ '/usr/bin/node', '/usr/bin/npm', 'run', 'build' ]
2 info using n...@3.5.2
3 info using no...@v8.10.0
4 verbose run-script [ 'prebuild', 'build', 'postbuild' ]
5 info lifecycle weert-...@0.1.0~prebuild: weert-...@0.1.0
6 silly lifecycle weert-...@0.1.0~prebuild: no script for prebuild, continuing
7 info lifecycle weert-...@0.1.0~build: weert-...@0.1.0
8 verbose lifecycle weert-...@0.1.0~build: unsafe-perm in lifecycle true
9 verbose lifecycle weert-...@0.1.0~build: PATH: /usr/share/npm/bin/node-gyp-bin:/home/maarten/git/weert-js/client/node_modules/.bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
10 verbose lifecycle weert-...@0.1.0~build: CWD: /home/maarten/git/weert-js/client
11 silly lifecycle weert-...@0.1.0~build: Args: [ '-c', 'webpack --mode production' ]
12 silly lifecycle weert-...@0.1.0~build: Returned: code: 1  signal: null
13 info lifecycle weert-...@0.1.0~build: Failed to exec build script
14 verbose stack Error: weert-...@0.1.0 build: `webpack --mode production`
14 verbose stack Exit status 1
14 verbose stack     at EventEmitter.<anonymous> (/usr/share/npm/lib/utils/lifecycle.js:232:16)
14 verbose stack     at emitTwo (events.js:126:13)
14 verbose stack     at EventEmitter.emit (events.js:214:7)
14 verbose stack     at ChildProcess.<anonymous> (/usr/share/npm/lib/utils/spawn.js:24:14)
14 verbose stack     at emitTwo (events.js:126:13)
14 verbose stack     at ChildProcess.emit (events.js:214:7)
14 verbose stack     at maybeClose (internal/child_process.js:925:16)
14 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
15 verbose pkgid weert-...@0.1.0
16 verbose cwd /home/maarten/git/weert-js/client
17 error Linux 4.15.0-38-generic
18 error argv "/usr/bin/node" "/usr/bin/npm" "run" "build"
19 error node v8.10.0
20 error npm  v3.5.2
21 error code ELIFECYCLE
22 error weert-...@0.1.0 build: `webpack --mode production`
22 error Exit status 1
23 error Failed at the weert-...@0.1.0 build script 'webpack --mode production'.
23 error Make sure you have the latest version of node.js and npm installed.
23 error If you do, this is most likely a problem with the weert-client package,
23 error not with npm itself.
23 error Tell the author that this fails on your system:
23 error     webpack --mode production
23 error You can get information on how to open an issue for this project with:
23 error     npm bugs weert-client
23 error Or if that isn't available, you can get their info via:
23 error     npm owner ls weert-client
23 error There is likely additional logging output above.
24 verbose exit [ 1, true ]

Op dinsdag 13 november 2018 15:20:14 UTC+1 schreef Tom Keffer:

[Thomas Keffer]

That's a pretty cryptic error message. Doesn't tell us much of anything.

I wonder if webpack was installed? Take a look in /home/maarten/git/weert-js/client/node_modules/.bin and see if there is a link to webpack. Mine looks like:

ls -al weert-js/client/node_modules/.bin

total 40

drwxrwxr-x   2 tkeffer tkeffer  4096 Sep  8 06:21 ./

drwxrwxr-x 846 tkeffer tkeffer 36864 Sep  8 06:21 ../

lrwxrwxrwx   1 tkeffer tkeffer    18 Jul  1 10:04 acorn -> ../acorn/bin/acorn*

lrwxrwxrwx   1 tkeffer tkeffer    19 Jul  1 10:00 atob -> ../atob/bin/atob.js*

lrwxrwxrwx   1 tkeffer tkeffer    25 Jul  1 10:00 babylon -> ../babylon/bin/babylon.js*

lrwxrwxrwx   1 tkeffer tkeffer    22 Jul  1 10:04 browserslist -> ../browserslist/cli.js*

lrwxrwxrwx   1 tkeffer tkeffer    20 Jul  1 10:09 cssesc -> ../cssesc/bin/cssesc*

lrwxrwxrwx   1 tkeffer tkeffer    16 Jul  1 10:09 csso -> ../csso/bin/csso*

lrwxrwxrwx   1 tkeffer tkeffer    22 Jul  1 10:04 envinfo -> ../envinfo/dist/cli.js*

lrwxrwxrwx   1 tkeffer tkeffer    15 Jul  1 10:00 errno -> ../errno/cli.js*

lrwxrwxrwx   1 tkeffer tkeffer    25 Jul  1 10:00 esparse -> ../esprima/bin/esparse.js*

lrwxrwxrwx   1 tkeffer tkeffer    28 Jul  1 10:00 esvalidate -> ../esprima/bin/esvalidate.js*

lrwxrwxrwx   1 tkeffer tkeffer    24 Jul  1 10:00 glob-all -> ../glob-all/bin/glob-all*

lrwxrwxrwx   1 tkeffer tkeffer    12 Jul  1 10:00 he -> ../he/bin/he*

lrwxrwxrwx   1 tkeffer tkeffer    23 Jul  1 10:00 html-minifier -> ../html-minifier/cli.js*

lrwxrwxrwx   1 tkeffer tkeffer    31 Jul  1 10:00 import-local-fixture -> ../import-local/fixtures/cli.js*

lrwxrwxrwx   1 tkeffer tkeffer    33 Jul  1 10:04 jscodeshift -> ../jscodeshift/bin/jscodeshift.sh*

lrwxrwxrwx   1 tkeffer tkeffer    18 Jul  1 10:00 jsesc -> ../jsesc/bin/jsesc*

lrwxrwxrwx   1 tkeffer tkeffer    19 Jul  1 10:00 json5 -> ../json5/lib/cli.js*

lrwxrwxrwx   1 tkeffer tkeffer    25 Jul  1 10:09 js-yaml -> ../js-yaml/bin/js-yaml.js*

lrwxrwxrwx   1 tkeffer tkeffer    22 Jul  1 10:00 loose-envify -> ../loose-envify/cli.js*

lrwxrwxrwx   1 tkeffer tkeffer    32 Jul  1 10:00 miller-rabin -> ../miller-rabin/bin/miller-rabin*

lrwxrwxrwx   1 tkeffer tkeffer    14 Jul  1 10:00 mime -> ../mime/cli.js*

lrwxrwxrwx   1 tkeffer tkeffer    20 Jul  1 10:00 mkdirp -> ../mkdirp/bin/cmd.js*

lrwxrwxrwx   1 tkeffer tkeffer    19 Jul  1 10:00 opener -> ../opener/opener.js*

lrwxrwxrwx   1 tkeffer tkeffer    27 Jul  1 10:04 prettier -> ../prettier/bin-prettier.js*

lrwxrwxrwx   1 tkeffer tkeffer    25 Jul  1 10:00 regjsparser -> ../regjsparser/bin/parser*

lrwxrwxrwx   1 tkeffer tkeffer    16 Jul  1 10:00 rimraf -> ../rimraf/bin.js*

lrwxrwxrwx   1 tkeffer tkeffer    20 Jul  1 10:00 semver -> ../semver/bin/semver*

lrwxrwxrwx   1 tkeffer tkeffer    16 Jul  1 10:00 sha.js -> ../sha.js/bin.js*

lrwxrwxrwx   1 tkeffer tkeffer    19 Jul  1 10:04 shjs -> ../shelljs/bin/shjs*

lrwxrwxrwx   1 tkeffer tkeffer    16 Jul  1 10:09 svgo -> ../svgo/bin/svgo*

lrwxrwxrwx   1 tkeffer tkeffer    25 Jul  1 10:00 uglifyjs -> ../uglify-es/bin/uglifyjs*

lrwxrwxrwx   1 tkeffer tkeffer    25 Sep  8 06:21 webpack -> ../webpack/bin/webpack.js*

lrwxrwxrwx   1 tkeffer tkeffer    46 Jul  1 10:04 webpack-bundle-analyzer -> ../webpack-bundle-analyzer/lib/bin/analyzer.js*

lrwxrwxrwx   1 tkeffer tkeffer    29 Jul  1 10:04 webpack-cli -> ../webpack-cli/bin/webpack.js*

lrwxrwxrwx   1 tkeffer tkeffer    18 Jul  1 10:04 which -> ../which/bin/which*

-tk

[Maarten van der Hoeven]

Thanks. The cryptic error message came from the npm-debug.log. Below the messages I see on screen. 

No .bin directory is created. So, nothing there.

At 'npm install' I only see a couple of warnings. 

At 'npm run build' I see a 'TypeError' on property of 'properties' of undefined.

/home/maarten/git/weert-js/client# ls -las
total 456
  4 drwxr-xr-x   6 root root   4096 Nov 13 19:18 .
  4 drwxr-xr-x  10 root root   4096 Nov 13 16:20 ..
  4 -rw-r--r--   1 root root    236 Nov 13 16:20 .babelrc
  4 drwxr-xr-x   2 root root   4096 Nov 13 16:20 config
  4 -rw-r--r--   1 root root     91 Nov 13 18:40 error.txt
 40 drwxr-xr-x 849 root root  36864 Nov 13 18:29 node_modules
  4 -rw-r--r--   1 root root   2696 Nov 13 19:18 npm-debug.log
  4 -rw-r--r--   1 root root   1726 Nov 13 16:20 package.json
372 -rw-r--r--   1 root root 379098 Nov 13 16:20 package-lock.json
  4 drwxr-xr-x   5 root root   4096 Nov 13 16:20 src
  4 -rw-r--r--   1 root root   2923 Nov 13 16:20 state.md
  4 drwxr-xr-x   3 root root   4096 Nov 13 18:40 v8-compile-cache-0
  4 -rw-r--r--   1 root root   1480 Nov 13 16:20 webpack.config.js

/home/maarten/git/weert-js/client# npm install
npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: fsev...@1.2.4
npm WARN ajv-ke...@3.2.0 requires a peer of ajv@^6.0.0 but none was installed.
npm WARN weert-...@0.1.0 No repository field.
npm WARN weert-...@0.1.0 No license field.

/home/maarten/git/weert-js/client# npm run build

> weert-...@0.1.0 build /home/maarten/git/weert-js/client
> webpack --mode production

/home/maarten/git/weert-js/client/node_modules/webpack-cli/bin/config-yargs.js:89
                                describe: optionsSchema.definitions.output.properties.path.description,
                                                                           ^

TypeError: Cannot read property 'properties' of undefined
    at module.exports (/home/maarten/git/weert-js/client/node_modules/webpack-cli/bin/config-yargs.js:89:48)
    at /home/maarten/git/weert-js/client/node_modules/webpack-cli/bin/webpack.js:60:27
    at Object.<anonymous> (/home/maarten/git/weert-js/client/node_modules/webpack-cli/bin/webpack.js:515:3)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)

npm ERR! Linux 4.15.0-38-generic
npm ERR! argv "/usr/bin/node" "/usr/bin/npm" "run" "build"
npm ERR! node v8.10.0
npm ERR! npm  v3.5.2
npm ERR! code ELIFECYCLE
npm ERR! weert-...@0.1.0 build: `webpack --mode production`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the weert-...@0.1.0 build script 'webpack --mode production'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the weert-client package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     webpack --mode production
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs weert-client
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls weert-client
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/maarten/git/weert-js/client/npm-debug.log

Op woensdag 14 november 2018 02:53:51 UTC+1 schreef Tom Keffer:

[Thomas Keffer]

Apparently, this is a known problem with webpack. The cure is to upgrade webpack-cli. 

Try the following steps. Note that in the following we are changing the required version in the file weert-js/client/package.json (which is for the client). Do not confuse it with the similarly named weert-js/package.json (which is for the server).

1. Remove the old installation.

cd weert-js/client

rm -rf node_modules

2. Delete the file weert-js/client/package-lock.json

3. Edit the file weert-js/client/package.json so the highlighted line reads

    "webpack": "^4.17.2",

    "webpack-bundle-analyzer": "^2.13.1",

    "webpack-cli": "^3.1.2",

    "webpack-merge": "^4.1.4"

4. Install and build again

cd weert-js/client

npm install

npm run build

If that doesn't work, we'll have to figure something else out.

-tk

[Maarten van der Hoeven]

Jippie, success! All working now in good order. Thanks a lot, Tom, for helping me out! Really appreciated.

Op woensdag 14 november 2018 17:01:51 UTC+1 schreef Tom Keffer: