~~SS~~

## Hot Projects

DIY Food Hacking

Open Solar Power

#### picoReflow

DIY Reflow Soldering

#### PiGI

RasPi Geiger Counter

Wideband Antenna

Map everything!

~~TAGCLOUD:50~~

# FOSS Data-Logging for Junsi iCharger

Batteries in general and lithium based batteries in particular require special attention, when it comes to charging and balancing. For this reason, the lab has a Junsi iCharger 1010B+, which offers a complete battery management solution for virtually every battery technology out there and some non-battery related features as well (like DC-Motor burn-in and foam-cutting programs).

It has proved itself as reliable hardware for over a year, especially taking care of the custom made LiPo battery packs for the Orion HD Camera Rig. It even offers a USB port for software updates and data-logging. Unfortunetaly, until now, only LogView users could get the logging data, but that would require a closed-source non-free operating system to run, which isn't available here (see Apollo-NG's Code of Conduct). Additionally, while LogView itself may be free (as in free beer), it doesn't seem to be open-source, so another solution was due…

Luckily, the USB port is actually just a serial port based on the cp210x serial to USB converter. Remember to build and load the kernel module, it should look like this, when you plug-in the iCharger:

[2865177.518351] usb 1-6.2: new full-speed USB device number 60 using ehci_hcd
[2865177.604715] usb 1-6.2: New USB device found, idVendor=10c4, idProduct=ea60
[2865177.604720] usb 1-6.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2865177.604723] usb 1-6.2: Product: Junsi iCharger 1010B+
[2865177.604726] usb 1-6.2: Manufacturer: Silicon Labs
[2865177.604728] usb 1-6.2: SerialNumber: 0906102520
[2865177.605380] cp210x 1-6.2:1.0: cp210x converter detected
[2865177.668344] usb 1-6.2: reset full-speed USB device number 60 using ehci_hcd
[2865177.753915] usb 1-6.2: cp210x converter now attached to ttyUSB0

## Python Code

The following code will read, translate and calculate all vital battery and voltage/current data. It was written in Python, since it's always inherently available on Gentoo systems, but should be easily adaptable into any other language. A node.js implementation with realtime web(socket) graphs would be interesting, to make it even possible to remote-monitor the process.

#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
########################################################################
#
#   This program is free software: you can redistribute it and/or modify
#   it under the terms of the GNU General Public License as published by
#   the Free Software Foundation, either version 3 of the License, or
#   (at your option) any later version.
#
#   This program is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#   GNU General Public License for more details.
#
#   You should have received a copy of the GNU General Public License
#   along with this program. If not, see <http://www.gnu.org/licenses/>.
#
########################################################################

import os, sys
import time
import serial

# discharge end voltage (empty)

dchg_end = 3.2

# iCharger modes of operation
mop=[None]*13

mop[1]  = "Charging"
mop[2]  = "Discharging"
mop[3]  = "Monitor"
mop[4]  = "Waiting"
mop[5]  = "Motor burn-in"
mop[6]  = "Finished"
mop[7]  = "Error"
mop[8]  = "LIxx trickle"
mop[9]  = "NIxx trickle"
mop[10] = "Foam cut"
mop[11] = "Info"
mop[12] = "External-discharging"

# configure the serial connections
# change according to the ttyUSB assigned to the iCharger (dmesg)

ser = serial.Serial(
port='/dev/ttyUSB0',
)

ser.open()
ser.isOpen()

### MAIN #############################################################

while 1 :

line 	= ser.readline	()
raw 	= line.split	(';')

v_bat 	= float			(raw[4])/1000
v_c1  	= float			(raw[6])/1000
v_c2  	= float			(raw[7])/1000
v_c3  	= float			(raw[8])/1000
v_in  	= float			(raw[3])/1000
i_chg 	= int			(raw[5])*10
i_sum 	= float			(raw[18])/1000
t_int 	= float			(raw[16])/10
t_ext 	= float			(raw[17])/10

s_vc1 	= ((float		(raw[6])/1000)-dchg_end)*100
s_vc2 	= ((float		(raw[7])/1000)-dchg_end)*100
s_vc3 	= ((float		(raw[8])/1000)-dchg_end)*100
s_bat 	= round			((((float(raw[4])/1000)
-   			(dchg_end*3))*100/3), 1)

print "Mode:           " + mop[int(raw[1])]
print "Batt:           " + str(v_bat) + " V (" + str(s_bat) + "%)"
print "Cell 1:         " + str(v_c1) + " V (" + str(s_vc1) + "%)"
print "Cell 2:         " + str(v_c2) + " V (" + str(s_vc2) + "%)"
print "Cell 3:         " + str(v_c3) + " V (" + str(s_vc3) + "%)"
print "Supply:         " + str(v_in) + " V"
print "Charge Current: " + str(i_chg) + " mA"
print "Charge Amount:  " + str(i_sum) + " A"
print "Temp INT:       " + str(t_int) + " °C"
print "Temp EXT:       " + str(t_ext) + " °C"
print ">>" + line



It only requires the pyserial package, on gentoo you can just:

$emerge -av pyserial To run the application, make sure your user has permission to read the ttyUSB device and run: $ python pycharger.py

There was not enough time to come up with a fancy pygtk or any other graphical implementation to show the data in real-time on a graph. Since the basic code, the data-mapping and the calculations are done and released under GPL3+ now, maybe someone else can step-in and extend the features to have realtime graphs :)

## Examples

### Monitoring Mode

The following example shows the data-log output of pycharger.py, with the iCharger in monitoring mode. The battery is one of Orion HD Camera Rig battery packs, after half a night of recording:

Mode:           Monitor
Batt:           12.199 V (86.6%)
Cell 1:         4.064 V (86.4%)
Cell 2:         4.072 V (87.2%)
Cell 3:         4.067 V (86.7%)
Supply:         12.315 V
Charge Current: 0 mA
Charge Amount:  0.0 A
Temp INT:       34.3 °C
Temp EXT:       22.3 °C
>>$1;3;;12315;12199;0;4064;4072;4067;0;0;0;0;0;0;0;343;223;0;46 Mode: Monitor Batt: 12.199 V (86.6%) Cell 1: 4.065 V (86.5%) Cell 2: 4.071 V (87.1%) Cell 3: 4.068 V (86.8%) Supply: 12.328 V Charge Current: 0 mA Charge Amount: 0.0 A Temp INT: 33.8 °C Temp EXT: 22.5 °C >>$1;3;;12328;12199;0;4065;4071;4068;0;0;0;0;0;0;0;338;225;0;39

Mode:           Monitor
Batt:           12.199 V (86.6%)
Cell 1:         4.064 V (86.4%)
Cell 2:         4.071 V (87.1%)
Cell 3:         4.067 V (86.7%)
Supply:         12.315 V
Charge Current: 0 mA
Charge Amount:  0.0 A
Temp INT:       33.8 °C
Temp EXT:       22.2 °C
>>$1;3;;12315;12199;0;4064;4071;4067;0;0;0;0;0;0;0;338;222;0;32 ### Charging The same battery pack, at the end of a charge cycle, in the final balancing phase: Mode: Charging Batt: 12.618 V (100.6%) Cell 1: 4.2 V (100.0%) Cell 2: 4.205 V (100.5%) Cell 3: 4.205 V (100.5%) Supply: 12.362 V Charge Current: 180 mA Charge Amount: 0.725 A Temp INT: 40.0 °C Temp EXT: 26.7 °C >>$1;1;;12362;12618;18;4200;4205;4205;0;0;0;0;0;0;0;400;267;725;31

Mode:           Charging
Batt:           12.599 V (100.0%)
Cell 1:         4.2 V (100.0%)
Cell 2:         4.205 V (100.5%)
Cell 3:         4.205 V (100.5%)
Supply:         12.315 V
Charge Current: 180 mA
Charge Amount:  0.725 A
Temp INT:       39.7 °C
Temp EXT:       26.6 °C
>>$1;1;;12315;12599;18;4200;4205;4205;0;0;0;0;0;0;0;397;266;725;29 Mode: Charging Batt: 12.579 V (99.3%) Cell 1: 4.194 V (99.4%) Cell 2: 4.205 V (100.5%) Cell 3: 4.204 V (100.4%) Supply: 12.315 V Charge Current: 170 mA Charge Amount: 0.725 A Temp INT: 39.7 °C Temp EXT: 26.6 °C >>$1;1;;12315;12579;17;4194;4205;4204;0;0;0;0;0;0;0;397;266;725;19


Although the code could only be tested with the 1010B+ here, it is likely to be compatible to all sister models. If you have a different Junsi model and are able to test the code, please be so kind and leave some feedback for other people, who also look for free and open-source data logging alternatives.

If you're looking for a cheap grid power supply to drive the charger, any old PC AT or ATX power supply will do, since the charger itself is nothing else but a versatile buck/boost converter, regulated by a micro controller and assisted by a battery of balancing resistors. The 12V output of a 300W ATX supply is being used here.

# Update

You may also wanna check out https://github.com/shead-custom-design/pipecat

## Discussion

, 2015/06/05 21:17

Hi,

Already few years old post but anyway really informative article. I have heard that Junsi use some non-standard baud rate for serial connection. Did you have to do any “tricks” to get connection to work?

I tried your script but it won't print anything to screen. I guess it won't get any data. I have checked that my Raspberry Pi recognizes charger when I connect it (with dmesg), but still can't get any data from there. Any tips how to proceed?

Thanks, Tero

, 2015/08/24 11:06, 2015/09/12 18:06

Hey Tero, sorry for the late reply, currently internet access is very sparse. I really don't remember anymore, the code ran just like it is documented abov eand I don't think I used any “tricks” to change the baudrate.

When you attach the charger, do you get the /dev/ttyUSBx device? You should see the driver messages in dmesg.

You could also try a serial terminal like minicom or screen and access the serial device manually ,to see what's going on there.

And you can play with

ser = serial.Serial(
port='/dev/ttyUSB0',
baudrate=115200,
)

or many other options from http://pyserial.sourceforge.net/pyserial_api.html to see if that does anything.

, 2015/09/12 17:26

I'll be trying this with the 4010 Duo over the next week or so.

, 2017/09/14 15:32

Late but did you have any success running this code with the icharger 4010 duo? I have been trying to communicate with the HID device but that is just not fun anymore

, 2015/09/12 17:27

When you say “make sure you have the drivers installed”, you simply mean USB kernel drivers or particularly the cp210x driver? Which one did you compile in?

, 2015/09/12 17:49, 2015/09/12 17:58
Device Drivers --->
USB Support --->
<M>   USB Serial Converter support  --->
<M>   USB CP210x family of UART Bridge Controllers 

In dmesg you should get something like

cp210x converter now attached to ttyUSB0

when you plug it in. Most Linux distros should have these enabled by default in their kernels, I would reckon. It was just meant as a heads up for people who'd rather compile their own kernels and may run into unnecessary problems otherwise.

, 2015/09/14 10:06

I see it for a 306B, for the 4010 is appears that only a USB-HID device is seen - no ttyUSB0. I'll keep digging. Appears I need to investigate modbus over USB-HID.

For the 306B, while I see the device appear in /dev I don't get any information coming from readline().

, 2015/09/14 11:24

Ok then, try minicom or some other terminal for the 306B to see if there is anything coming there at all or if it needs some magic trigger to start putting out data.

We can also try to look if there is logview support for the 4010 and if so, see how they grab the data off the device. In the future I'd like to build these features into our new, flexible governing/monitoring software, where we have all system configuration, storage and logging already available (see picoReflow). It would be a great adition to the feature set and hopefully make this stuff more easily accessible for other people :)

, 2015/09/14 12:26

OK, minicom, not too familiar with it - but I'll have a look. I was wondering if the 306B has a specific baud rate/parity etc - my python code isn't using anything there.

I also don't know if there is a specific setting in the iCharger to do with log files that would trigger logging via USB or not.

I also had the idea of looking at LogView - another source is DataLogger (a java system for pulling data). I pulled the code for that too but haven't had time to figure out what protocol its using.

I'm more than happy to share the ideas / code by the way - having searched for about 3 hours now for info and seeing what's available… hmm… very little, so sharing more of this would be great.

I'll *potentially* build something commercial from this stuff, so I would be willing to share particular bits on a commerce friendly license.

, 2015/09/23 20:03

ok, so I got a basic USB-HID interface working, that speaks Junsi's MODBUS protocol. It's a C++ program using libusb. I can get quite a bit of data from the charger, can start/stop different modes too. Still a total prototype program in that there's nothing to tell you how to build it, nor how to set up a USB-HID interface etc etc.

But as proof of concept - yay. I'll keep working at it. I used A LOT of the demo app code (Visual Studio 2005) code.

, 2015/09/24 07:58

That's good, but when you're saying you want to build something *potentially* commercial we might have a potential conflict in interest :) Everything we do here is strictly kept non-commercial, since many people sacrifice a massive amount of their lifetime to share their knowledge, code and examples on the net for free, so that others may not be hindered by intellectual property issues and can start with what ever we have achieved up to now, no matter if we are rich or poor and may not be able to afford “commercial” solutions.

After all, it doesn't take much to observe the failings of our current non-sustainable system implementation and it doesn't seem to be wise to concentrate efforts and lifetime for personal monetary gains, when we're only able to create and build these things because other people were willing to give it away for free (even at the cost of their time).

Personally, I'd be happy to collaborate when it's kept open-source, don't worry too much about code sources or quality, everything starts out as a giant bug and progresses (or not) from there ;) If you could share your current implementation on github we'd have a place to start and I'd love to look at it anyways, since I've also got an LCR meter here that seems to have some sort of USB-HID interface, which I couldn't query successfully yet.

, 2015/09/24 13:24

I'm happy to share bits and pieces. I laughed out loud when you said everything starts as a giant bug! So true, so true.

I respect your choices with regards to open source and leveraging others work - at the same time I'll see what options exist for me commercially. In my particular case (the rc heli market), I rather doubt that there's enough people in the world to warrant mass production, marketing etc of the concept I'm building. After all, it's all about charging batteries and I am tickled with the idea of being able to monitor the charging from the comfort of my armchair.

I was discussing the idea of OS vs. commercial with my brother the other day too - we've both got plenty experience in coding and business, and agreed that in the initial stages the following ideas are more important (also from a business point of view): - release early, and make it open source you want to find out if theres any interest - once you've found interest, THEN ask if someone is willing to pay cash to have a really polished solution, e.g. buy it, plug it in, it works - instead of the more open source approach of buy it, assemble it, cross your fingers (and toes) and see if you can cobble something together that works. the latter option implies a non-trivial amount of will power and knowledge, which plenty of people have - my view is the commercial solution exists to serve the first crowd.

So, I'll keep you posted - my current goal is now take the “spike” solution I created which proves I can at least do comms i/o with the device and turn this into a server that publishes the charger status via ZeroMQ (using JSON), uses Bonjour for auto discovery and handles USB unplug/plug events.

After that, I can focus on a UI. I can't decide yet whether i'll cut my teeth on some HTML/JS stuff, or whether I'll go the Qt/QML route - the latter is appealing because it'll run EVERYWHERE and the tools to dev are far higher quality than that of the HTML/WEB world, not to mention I've already got years of C++/Qt experience so I'm massively biased anyway.

Time will tell.

Take care, – John

, 2015/11/22 20:34

Hi John, i read with very interest your posts. I am not su good in embedded software like you. Let's say so, I can read a little bit what you are telling us, but i am not really so expert to develop by myself. I have a duo4010. I was wondering if is possible to have a PC remote control. Let's say i habe a Labview or similar PC Logic Unit implemented and I can send (let's say every second) a current or voltage set point and the Junsi answer with a current/voltage stress on the battery, and give back on the modbus the measure current/voltage/temperature. Thanks in advance for your appreciated answer.

, 2015/11/22 21:45

Hey there - this is then worth a small progress update.

After about 6 days I managed to work out what the heck Modbus was, and used the example code (targeted for Visual Studio and the m/soft USB stack) to talk to the device - albeit on Linux running on a little Raspberry Pi/2.

It's not perfect - libusb reports that the device stops talking after some time, but I built a little USB reset into the calls and this appears to stabilize the comms quite well.

The code publishes the ports that are used for communication via Bonjour - making auto discovery and connection possible as long as the UI is running on the same subnet/network.

Speaking of UI. I tried using Qt/QML to mimic the 4010 DUO - it worked, but I wasted DAYS learning how to do it and I'm not at all happy with dev speed. I'll be investigating Ionic/AngularJS2 now as I'm curious as to whether this is, at the end of the day, easier. Goal is to deliver a monitoring UI to the charging process to all devices - so both Qt/QML and HTM5 work well as they cover all devices.

To answer your other questions - yes - you need a protocol to control the device, it requires Modbus knowledge - more than happy to push my code to github but right now it absolutely will not build for you unless you follow some pretty specific instructions (that I don't even have). What i mean by this is that I rely on some headers to be included on my dev box (Rasp Pi/2 and Mac), some installed by apt-get some installed by hand.

In other words - you'll need some level of patience getting it to work. I would like to release the back end parts that actually work as open source - but can't promise a documented, excellent smooth ride at this point in time.

Will post more when I have the chance.

Thanks!

, 2015/11/25 20:53

Sounds awesome. If you don't already know it, I can highly recommend: https://github.com/tmaximini/generator-ionic-gulp as a starting scaffold for a hybrid angular/ionic UI which is really easy to get going.

, 2015/11/22 21:47

Oh yes - I decided to use ZeroMQ as the comms channel NOT httpd - because it can provide pub/sub as well as req/resp patterns, this is far far better suited to the data stream requirements that a continuously polling HTTP request system.

Granted: my knowledge of web sockets is limited - still, to get that working the server needs a fully configured Apache or NGINX or equiv. back end - and ZeroMQ doesn't need any of that stuff, so code-wise it's a LOT easier to set up.

There you go - now you know why I chose that path

, 2015/11/25 21:01

I've got plenty of nginx and zmq experience at \$dayjob and I must say, in my experience, zmq does scale pretty well, yet it's simple and serverless +1. On the other hand most websocket based apps don't technically need an nginx in front of them. This is done mostly for either convenience or security measures. Using angular/ionic with websockets is actually a real breeze and a tightly integrated component for app/UI comms. I hope I can release some code for goveness by the end of the year for another project that might also serve as an example for this kind of approach.

, 2015/11/25 21:07

aha, cool - I have ZERO experience and of course this provides me a huge opportunity to bias things I know, like C++/C etc etc.

So if websockets and some simple low spec pub/sub style stuff is available via that, then it could well be a solution too. Zmq I know is utter overkill in the sense that we're talking kb/s over the wire with only a few messages per second not thousands.

I'm all ears - what kind of components would one plug together to get:

1. a pub/sub channel over which charger information would be continuously published.

2. a command channel over which a GUI asks “which chargers are there”? and “what topics/queues should I use to listen for their updates”?

Make sense?

, 2015/11/23 13:13

Here the VERY simple commando that I would like to have: Set a Charge or discharge Current or Charge of discharge Voltage (say I=+/-10A or U_=10V) for a given time(say t_ch=1000s). In the meanwhile the Junsi provides on the bus as quick as possible the measurment of U,I,T. 100ms. Every 100ms the junsi verify that a new Current Value or the stop is given and so change the current value with the updated one.

With this i would be able to generate than a driver for a Labview VI system. It is possible? I would really appreciate. Bests & Thanks

, 2015/12/07 08:51

Which specific Junsi iCharger do you have?

I think I understand your idea, and the code allows for it - at least I've written a test command line program that can start the charger, one would need to add code to specify the voltage amount.

Monitoring is also very possible.

Whats lacking is documentation about why I wrote the code the way I did. For example, the code to listen to updates from a charger can listen for updates from multiple chargers. My long term vision was to hook up more than just iChargers you see.

I'm at the brink of learning ionic/angular now - but my full time job takes a ton of my time, as do my family and other interests so don't hold your breath please waiting for me. i'm MORE than happy to answer any questions though!

, 2015/12/07 08:50

Awesome, thanks for sharing. I'll have a look as soon as time permits (same thing with full-time job, rebuilding Apollo-NG'S basecamp etc. so there is little time left to dive into projects right now) but I probably can't test it anyways, since I've only got the 1010B+ so far, and IIRC this is not a modbus but a plain old serial device and I don't think that it's just a matter of firmware, it it?

If someone else has a modbus junsi device, please play with John's code, so that we can get more people involved.

News: re-writing the project now, open-source, based on python - have got further than before So far I've not tackled the idea of the 306B, I'm writing all this against a 4010Duo.

, 2017/01/04 10:14

Awh, that's great, John. I've also been busy pushing https://github.com/apollo-ng/governess forward, it would also be a perfect system to integrate a multi-charger control & monitoring appliance. As of now, almost all wok has been put into the client (Multi-Platform Hybrid Web/Mobile/Desktop) to have a complete model/data driven setup. This way we can create any kind of appliance on the server with driver-plugins which give their input, control and output interfaces and settings to the client to build an interface that makes sense for the selected set of drivers for the users and leaves the server with an abstracted sense of the appliance it's supposed to be.

I'd love to have someone else onboard so that we don't waste time and resources building similar systems but I realize that it would require some sessions where I could show you more, so that you'd get the picture of the stuff that I haven't managed to finish yet.

I hope that I can finish the appliance editor toward the weekend in order to finally make a screencast that would give people a better idea of what's already been done since they can't just download, try it and start developing plugins for it.

, 2020/07/09 07:25

I'm working with an iCharger 208B, putting it to use with a bike generator as the control device for the system. It works well as a generator-controller, but it's difficult to change the charge rate (effectively, pedal resistance) while running… fiddling with less-than-ideal control buttons while riding. So I want to automate a stationary-bike interval-training routine, preferably using Arduino.

Problem is, I can't get past the very first step - understanding this Modbus protocol, if it even is that. It's a USB-UART (CP210x) device, and when I open it at 115200 baud, nothing happens… once I set it charging, it starts spitting out binary data with seemingly invalid encoding (bad parity? can't figure it out), and I can't make sense of it.

One thing that NOBODY… ABSOLUTELY NOBODY on the internet seems to have done so far… is simply capture a raw binary conversation between the two devices. Exactly what binary bytes are sent… what's received. That's how I finally figured out YMODEM file transmission, because Tera Term leaves behind a log-file that's quite verbose and explains the protocol byte by byte.

I've not yet been able to find anyone explaining the protocol like that. And the sample code in this post here seems … incomplete? It doesn't set up a baud rate or anything… it just tries opening a port with no parameters. That can't possibly work!

The more I dig, the more lost I get. The protocol guide “icharger_modbus_protocol.pdf” is probably quite useful but it glosses over the most basic details to get started… and it talks about using USB-HID which isn't applicable to mine. .. yet it also talks about using USB-Serial, which is applicable… and doesn't go into any detail on describing that.

Some binary hex-dump of a conversation between the two would be HUGELY appreciated :)

I really need to be able to control charging amps, that's it.

, 2020/07/21 04:27

I dont have the 208B :/

, 2020/07/20 22:52

The missing piece of information:

It's an all-ASCII protocol. It runs at a non-standard baud rate of 128000 baud.

It's not MODBUS. It's proprietary.

It's not bidirectional, except for firmware updates, that starts off with an odd character sequence (something like :FF412324 but I can't remember the six digits, then a \r\n sequence), then streams packets of data and the charger responds with a single ”&” character after every approx-17-byte packet.

Haven't found a way to control the charger, unfortunately, as that's all I wanted to do. There might be a way, but it doesn't appear to be documented, and the firmware isn't quite plain-text (otherwise I'd expect to be able to see menus, errors, and prompts in ASCII plain text somewhere in the firmware), so it's either compressed or scrambled in some way. Unfortunate…

, 2020/07/21 11:55

Hi

I’d be happy to share the knowledge I gained on the charger project. Another gent (Avery Baird) pinged me just 3-4 days ago to start working on driving electric’s metrics into prometheus, so he can build a dashboard.

I just spent the last few months of my CTO life dealing with integrating Grafana, alertmanager, prometheus etc into our tech stack - and I can stay Avery’s idea of exposing progress via these tools is FANTASTIC.

Obviously; a dashboard can’t drive charger settings nor kick off a charge - but since we need to hook up batteries physically anyway, I don’t see this as much of a limitation.

Anyway, getting off topic: I never managed to make the ASCII protocol work. I worked out how Junsi did their MODBUS implementation and wrote a RESTful web stack on top of that - allowing any front end to drive most of the charger functionality. This is what is currently driving the electric project although I’ve not used it in years as I stopped flying heli’s a couple of years ago now.

Yeah; not what you are after I know you said ASCII and the 308/B.

I’m happy to try and help where I can. I don’t personally have the time to commit to another OS project but perhaps it would make sense to hook up on skype/zoom/whatever and talk through some of the ideas / problems.

I’m open for that.

Find me on Skype. Remove the spaces and underscores from this: j_oh nccla_ yto_n

Yeah, I’m paranoid. But just fire me a message - throw in something to remind me you are not a spam / robot and we can talk.

Ciao!

, 2020/07/25 04:30

Yeah, good approach, I do the same, if even push my 3d printer metrics into my local inlfux/prometheus/grafana stack and have been promoting grafana since forever (see: Virtual Flight Control Center now public).

, 2020/08/22 20:40, 2020/08/22 20:46

Nice, ebastler ported it to py3 and put in some more features:

Also, John, electric really looks nice! Why is it Pi only tho? If I find the time I'll have a look into the ionic build…

I just bought an icharger X6, it was quite a quest to find info and latest firmware. In case someone is looking for latest firmware:

  _      __     __   _  __   ___   _   __
|__/|__/  \___/  /_/|_/  /_/     |___/