Building GOSDM630: fs.go:35: undefined: sort.Slice about gosdm630

[andig]

Wrong go version!

[aerno]

Raspbian offers Golang 1.7. Which version do I need ?

[andig]

1.8, see #14

[aerno]

Thanks. I just tried building Golang 1.9.3 on Raspbian but it seems to be a no-go:

./make.bash

Building Go bootstrap tool.

cmd/dist
import cycle not allowed
package cmd/dist
imports bytes
imports errors
imports runtime
imports runtime/internal/atomic
imports runtime/internal/sys
imports runtime

Not even a clear error or anything like that. 'Import cycle not allowed' - good luck. In the docs it specifies needing 1.4 as a bootstrap compiler.

This Go language seems not so well standarized to me. We will end up with 10 versions of Go on our system when running 10 different Go apps :-(

Ouch, it means I cannot compile either Golang or GOSDM630 myselves. I might be quicker off just porting GOSDM630 to plain C or C++ ...

Are there any older versions available of GOSDM630 which I can still compile on Go 1.7 ?

[andig]

Golang 1.8 from buster worked for me.

[aerno]

I used the latest stable Raspbian 'Stretch', which seems reasonable to me when installing a monitoring system to use the next upcoming years.

Are there any older versions available of GOSDM630 which I can still compile on Go 1.7 ?

[andig]

Not sure if it matters if it seems reasonable. GOSDM needs go 1.8 and as for debian that's available as of buster, not stretch. You can easily install it from the testing repos.

[aerno]

I will give up on GOSDM630. It looked so promising to me by not low level addressing the modbus registers.

But on the other hand low level bit banging the modbus seems a much better route than compiling my own compiler which needs itselves old specific version to compile... What was wrong with C++ in the first place ?

As my RPi will be running much more software than just GOSDM630 I will not go for a beta Raspbian.

Issue can be closed as: unresolvable

[andig]

I will give up on GOSDM630

Too bad- it's working perfectly stable for me.

bit banging the modbus seems a much better route than compiling my own compiler which needs itselves old specific version to compile...

There is no need to compile a compiler.

I will not go for a beta Raspbian.

There is no need to do so. All you need to do is to install a perfectly stable piece of software that has just not made it into the debian release train for stretch. Make yourself familiar with the debian release methodology and you'll understand this point. It has nothing to do with beta at all.

Issue can be closed as: unresolvable

It is resolvable. I've told you how. And you can close the issue yourself.

[aerno]

You're right I'm not so into Debian at the moment. I'm are RHEL specialist, so no beta software here :-)

I chose the latest Raspbian stable, updated that with the latest updates available and assumed to be ready to rock and roll.

I did see the search & replace trick in the repository online to switch to Buster. But I will wait untill I can do a dist-upgrade to Buster if ever needed.

All I notice as a Linux systems architect it gets more and more frustrating to compile custom apps which are not into the standard repositories. See this Golang issue; have 1.7, need 1.8, need 1.4 to build 1.9. Dependency hell anyone ?

Good news: In 2 hours I've tweaked/programmed a very basic Python modbus daemon which reads all the required SDM630 sensor values every 10 seconds and stores them into a database.

A second python script is able to read the timestamped records with values from the database and forward the values to any other application like Domoticz. If that part isn't working the energy data is still collected and stored and can be processed later.

Netto CPU Usage: 0.3%. I don't see why an app for retrieving these MODBUS values would need a custom Google programming language like Go. It has an 8MB binary memory footprint and uses many more CPU cycles than a basic python script which runs anywhere.