I wrote a berry driver

[3ricj]

Hi there,

I just released my first berry driver -- for victron controllers.

The code is here:

https://github.com/3ricj/VictronTasmota

There was quite a bit I had to determine about berry through raw experimentation because it wasn't documented anywhere. Specifically, syntax around specific operations with lists, how to check for a value on a list without causing an exception, how to interact with json_append and web_sensor secret built in functions, and lots of other random things. I still don't know wny json_append calls happen at a rate faster than it sends json.

Also, there is a pretty good json library in berry (import json), but most examples use basic string concat like it's 1997. Of course, because it's appended json, you have to muck with the value name in order to make valid json come out the other end. here's how to do that:

# Stuff a bunch of stuff into a list in different formats. 
self.sensorname = "mysensor"
self.jsonstring["Volts"] = real("12.123")
self.jsonstring["Model"] = "testing 5000"
self.jsonstring["BuildVersion"] = 4

# assemble into a valid json string
tasmota.response_append(",\"" + self.sensorname + "\":" + json.dump(self.jsonstring)) 

I'm not sure a full driver implementation should be copied into the playground -- I'll let whoever maintains this figure this out, but as I had to spend so much time figuring out under-documented features, it might be helpful to others.

Best,
-3ric

[dkebler]

Thx for you contribution

I moved your post to discussion, issues are for actual PRs once your contribution PR has been created/vetted.

Can you take a look at the readme especially the part about contributions. If you can create the appropriate PR we can add what you have developed. Unfortunately no one is available to create this for you.

[3ricj]

yeah.. I think I'm starting to understand why there isn't any contributions to this repo, and why berry documentation is in the state it's in. Nobody is here doing the work to maintain this!

I'm sorry, but I don't have time to jump though those various hoops. Perhaps someone who is a berry contributor or stakeholder can pick this up; I'm happy to answer questions.

Best,
-3ric

[3ricj]

I'm noticing a pattern here with the berry folks: When faced with feedback: They kick the bucket!

[jziolkowski]

Nah, I get you. All the drama aside, or disagreements in view etc. That's a side topic.

You said "nobody is here to do the work to maintain this". Fine. Then I'm giving you the opportunity to put your money where your mouth is and change that by taking care of maintaining the berry docs.

(I'm not a berry guy btw, I rarely use it)

[3ricj]

That's fair, and why I was here trying to contribute code, implementations and the like.

[jziolkowski]

No one is challenging the fact that your contribution is adding value.

However, as it's done in the main tasmota repo, and here, and I'd wager an assumption that in any repo that is not simply a link list, contributions are done via pull requests, and when needed some extra steps.

Does that need some extra work? Yes. Can it be annoying? Hell yes. Should people other than the welcome contributor be delegated to do that? I would disagree. Are these extra steps a part of a contribution? That depends if you want your code to be included in this repo.

While I'm not a fan of going personal and assuming certain traits in the other side of a discussion, as you both unfortunately did, from a strictly technical/GH point of view the PR is the way to go, with all the added complexities. All I can say is take it or leave it. No hard feelings towards anyone.

[3ricj]

Perhaps you should review this document: "Contributions: Guidelines, Reliability and Management". There's much more involved. Also best I can tell not a single person has actually managed to follow that process.

Finally I was asking some key questions which were left unanswered such as does it make sense to leave an entire driver implementation copied into this dead repo? It's the sort of thing that would become out of date as soon as it's integrated.

Projects like this will thrive or stifle and die entirely based on how maintainers interact with folks trying to help. The first message I received from the maintainer told me that he was not going to answer my questions or offer me any sort of support.

There's no earthly reason trying to contribute code snippets to be more complicated than submitting something to the Linux kernel.

But I'm not alone: Best I can tell everyone else who's tried to submit something to this repo has been turned away by the combative and not helpful maintainer. This just means I shouldn't take it personally. No hard feelings, this dead end will eventually get replaced with something more welcoming to people trying to contribute.

[dkebler]

I am just a tasmota user/ berry coder and I volunteered to put this repo together and to manage it, Since I don't have time to also to create the content for others contributions I tried to make it as painless as possible (fork the repo add your markdown, make a PR)

It's a bit selfish if you think about it to use tasmota firmware for free, to ask questions on the discord server and get answers for free from sfromis and others who are very helpful and then never give anything back. Ok so you don't have any time, we all have time constraints so that's understandable.

The worst thing, though, is to complain about the lack of effort of others for something you use for free. That's a comment worth keeping to yourself. In fact that should be a point of courtesy of anyone using all the code (mostly for free) found on github.

[3ricj]

You seem a bit confused.

• I just released a fully functional driver which was asked for by the community, for free.
• I've never been on discord, nor gotten "free answers" from anyone.
• I offered this to you, as the self appointed maintainer, for free, as a gesture of good will.
• You told me I have to do a bunch of random things and that you where not going to help, and that nobody was available to help.

You have an extremely narrow view of what helpful is. I'm not sure this "berry playground" which nobody is using is helpful to the community. It didn't contain anything helpful for me when trying to write a driver. That's likely because you've decided it should be structured in a very specific way, which nobody is using, and by all appearances, abandoned. Perhaps something as simple as a wiki page with links to useful code might go a long way toward adoption and usefulness.

Otherwise, it's just berry bitrot.

Operationally, what you asked didn't even make any sense for me to do, even if I had time. Forking the whole berry playground, merging my driver into it, and sending it up to you for review is absurd. Having a duplicate, old copy of code around on this site doesn't help anyone here; they should likely just get the current version from the existing PR, which I sent you the link to. I said as much on my first message to you, which read "I'm not sure a full driver implementation should be copied into the playground" - which you provided zero guidance or comment on.

Best,
3

[sfromis]

@3ricj I'm not much involved in what happens here, but let me mention a couple of details.

I've collected a simple list of Github repositories where I've "noticed" Berry code being published, and have added your useful driver to the list.
http://sfromis.strangled.net/tasmota/berry/github-repositories

Most of the discussions and questions/answer around Berry coding is happening on the Tasmota Discord server https://discord.gg/Ks2Kzd4 including a #berry channel with daily activity. I'm pretty active there.

The reason "why json_append calls happen at a rate faster than it sends json" is that the JSON payloads are not only used for publishing via MQTT, but also the basis for Tasmota features like the old rules feature, tasmota.add_rule processing in Berry, and also the optional scripter feature (which is mainly used on ESP8266). Hence it will be called around every second. The driver is also expected to have a similar web_sensor() callback, to provide sensor data for the Tasmota front page.

When it comes to the steps for getting stuff published here, Github is mostly designed for collaborative maintenance of complex code projects, and therefore the procedures around contributions tend to be on the elaborate side, and needing things done "just right". I've not put any thought into how it could have been made more suited to a more loose structure with very separate items included, and simpler procedures, within Github.

[dkebler]

ok, whatever, stop wasting your time here then.

[3ricj]

It's all good -- I looked over others folks attempt to contribute, and you had similar issues. It looks like we've identified the common denominator here. Best of luck!

[dkebler]

So why don't you ask the devs to be the maintainer of this repo and do it your way? (you can talk to them on discord)

It was never meant to be list of links to other repos (which too gets stale). It was put this together more as a place for stand alone learning material and code and the tasmota devs blessed it and that's why it's in their org and not just my repo.

I think you have convinced me to no longer be the maintainer of this repo. I'll find another way to contribute.