Inconsistent device listing in quick config

[iprak]

Some devices have [BK7231T] prefixed which makes keyboard navigation difficult.

It might be better to have that piece suffixed. Another improvement would be to have the list sorted.

How about this? I can submit a PR if this sounds like a good idea.

[openshwprojects]

Well, the idea was to abandon the quick config and use the online database of devices, but we need manpower to create that database first. It could be done through the javascript web panel, here: https://github.com/OpenBekenIOT/webapp

Still, your change is good, so if you want you can submit a PR

[iprak]

The items themselves don't say which device type they refer to so I am not sure how the grouping can be done on client. Since the content served is generated in http_fns.c so I was thinking of adjusting that code.

https://github.com/OpenBekenIOT/webapp provides content for the webApp right and the not the embedded app?

[openshwprojects]

Yes, this is a web app in vue and it's automatically downloaded by HTTP everytime when it's needed, so if we create a device database there then:

• it won't use device flash memory
• it will get automatic updates
• it could include device photos etc hosted on imgur and much more @btsimonh is web app maintainer

If anyone here have some time and VUE skills, just tell me, I am not a VUE programmer, any help is welcome, that javascript app devices library could be very useful for many users

[iprak]

Oh I see what you were referring to. Yes moving over this feature to the webApp sounds like a better idea. Let me see if I can figure it out.

[iprak]

I am curious why we use webApp in this manner. I am more familiar with ESP8266 chip using Espurna firmware. That chip is almost as powerful as this and the firmware serves embedded zipped website content. As such no internet is required to configure the device. I keep most of these IOT devices off the internet. There is an option for local WebApp but it doesn't seem to work yet.

[openshwprojects]

I'd rather just create a text definition for templates just like in Tasmota and allow people to import (copy-paste) templates offline, but still leave also the direct templates access through Web App. That would be simplest and cleanest solution.

Saving WebApp to local file system would defeat its purpose, as we already have a WWW panel that works without internet connection

[iprak]

What do you think of this UI?

• The device list is filtered by the chipset starting with the current chipset.
• One can pick a device to see its details.
• And then apply the pin configuration
• And then save them as before.

My webApp changes are in https://github.com/iprak/obj_webapp/tree/devices.

• The new UI will only appear if the firmware supports it.
• Most of the devices looked straight forward but some invoked CFG_SetFlag and CFG_SetShortStartupCommand_AndExecuteNow which I have accounted in the device database.

[blakadder]

I'd rather just create a text definition for templates just like in Tasmota and allow people to import (copy-paste) templates offline, but still leave also the direct templates access through Web App. That would be simplest and cleanest solution.

Saving WebApp to local file system would defeat its purpose, as we already have a WWW panel that works without internet connection

When is this planned? I've started playing around with the firmware and will be creating a supported devices website in the future

[btsimonh]

hi blakadder, welcome to the party :).

My initial thoughts on this were very similar to @iprak 's implementation. I imagined the device database being served off a site like your Tas site, as a single JSON file containing the list of all devices and their templates (and links for further info?). The link to the json would be hard coded in the webapp, and does not need to be part of the webapp itself; but it would be nice it it was easily (almost publicly) editable - I had considered making it a wiki page.

The webapp itself is currently very simple, quite easy to work with, and can be served directly from ghpages, or from the device itself (if the device type supports the FS, which currently overlays the upgrade flash area. You just configure the device to tell it where the webapp will be served from.

@iprak - to serve the webapp from the device itself, you just upload the folder to a folder on the device FS, and then configure the link to point there - the local FS is served over HTTP from the device itself. When upgrading, you have the option to backup and restore the FS automatically as part of the upgrade. As @openshwprojects states - the need for serving from the device is probably a specialist thing - where the browser you are accessing from does not have internet (when may that be?), or maybe when you want to stick to a very specific version.

@iprak - For development, I use the webserver addon for chrome :). and yes, a modified index.html to make it connect to the right device during development. (normally, the index.html is dynamically generated by the device itself to add the devices own address...).

br, Simon

[btsimonh]

@blakadder - I guess what I'm saying is as you are the god of TAS config pages, we'd take your lead on where to store the json, how it would be edited/updated, agree a json format, and off we go?

[blakadder]

@blakadder - I guess what I'm saying is as you are the god of TAS config pages, we'd take your lead on where to store the json, how it would be edited/updated, agree a json format, and off we go?

I'm still very new in all this so I'm not yet aware of all the features or limitations. I'd prefer a human readable style, but there might be size limitations and whatnot. Basically whatever you decide will be fine, an autogenerated JSON can be served from ghpages and a page layout for each device can have all the flashing and configuration information.

[iprak]

@blakadder , @btsimonh

I have some work done on this on the webApp end. I also converted the device pin mapping to json (devices.json). I ran into some odd devices which needed extra setup. My current plan was to leverage/extend the existing pin parsing code in firmware. It is based on JSON parsing so the offline app can be modified to submit JSON.

The code is in this branch - https://github.com/iprak/obj_webapp/tree/devices

I ended up using npm package serve with modified indexlocal.html which sounds close to what you are doing.

One thing I couldn't figure out was how to configure the custom WebApp location. Using a local website would always result in CORS error which might be because my website is not https. But I wasn't sure and could not find any instructions about this.

[iprak]

@blakadder I feel the same way about Tasmato templates. I can't make what the pins mapping and base template means and prefer a readable JSON listing which is what I went with.

[blakadder]

@blakadder I feel the same way about Tasmato templates. I can't make what the pins mapping and base template means and prefer a readable JSON listing which is what I went with.

looks ok, the flag part is a bit cryptic but maybe its for the best ;)

Maybe the naming scheme could be expanded into more fields (vendor, name, serial) because this way gets messy fast, not that it won't get with the expanded one due to manufacturers not caring about model numbers and whatnot

[btsimonh]

vendor, name, serial

I like that, 'cos then it can be hierarchical if required. Maybe vendor, name, serial plus a pure descriptive which can by default be built from the categorisation ones. One thing we have observed is the exact same vendor/model/code being 'upgraded' and being completely different hardware, even with the same serial number style.

[btsimonh]

One thing I couldn't figure out was how to configure the custom WebApp location. Using a local website would always result in CORS error which might be because my website is not https. But I wasn't sure and could not find any instructions about this.

check we did not lose the CORS headers in the App URL serving from the Device code. I seem to remember this being a right royal pain. If serving the index from a local webserver, and accessing JS files from somewhere else, you would need the webserver to add the cors headers to allow it. I'm SURE it's in the device code.... in the serving of /app ? s

[iprak]

serial number style.

Do you mean model number? Serial number (if defined) would be unique per device.

[btsimonh]

I mean like two devices have adjacent serial numbers (obviously in the same 'series'), yet different boards inside.

[iprak]

I had included chipset+board to differentiate that. I just updated https://github.com/iprak/obj_webapp/blob/devices/devices.json with some changes.

[openshwprojects]

@iprak it's a great progress, especially good for a start, altough I would also note that as long as we use a database in json format then the frontend gui can be change and improved with ease

I think the JSON format is also good as well, altough I would add an images array (for a gallery), a main image and a keywords array (example keywords: Dimmer, BL0937, etc)

@blakadder it's great to see you here and I hope we can all create one devices database, as I said, maybe in that JSON format, then multiple web pages can fetch it and display it however they want

Regarding hierarchical listings - they could be procedurally generated based on JSON content, for example, it's up to frontend gui to decide whether devices are grouped by manufacturer, or by chip, etc. NOTE: some devices comes with different chips, as @btsimonh said

If there is anything you need from programming side of things, just tell me and I will try to get it done within a reasonable amount of time.

[iprak]

@openshwprojects I personally feel that gallery images would be just bloating the database. Main image is one thing but making it a gallery is taking is somewhere else. The extra images would be helpful if we had instructions along with it but that is pretty much the teardown wiki. I looked at your posts at elektroda and they are very extensive. I cannot imagine flashing any of those devices by just looking at the images.

I was also going to ask if it was possible move the setup wikis to github. My inspiration and use in this regards is mostly based on ESP8266 firmwares with the main one being https://github.com/xoseperez/espurna, https://github.com/xoseperez/espurna/wiki/Hardware.

[blakadder]

I think I'll be able to tackle setting up a better documentation page on a framework built for that purpose and try to collect info dispersed among the various threads

[btsimonh]

@iprak - a request on the JSON. can we have it something like: { "type":"devicedatabase", "version":"0.1", "devices":[ { ... } ] }

this just allows us to future-proof the format by identifying it, i.e. the file is self-describing at the top level. It's something I do with all my json files now :).

[openshwprojects]

@iprak by gallery I meant photos helping to identify if the board you have is the board from the device, because sometimes devices have the same label but different board or vice versa. Still, a link to teardown topic solves most of the problems

@iprak one of the reasons that I host my stuff on Elektroda is because Elektroda supports my projects and provides me with devices and equipment for testing and it's the only way to make my little IoT "reasearch" affordable, so for me moving out of Elektroda is not possible now. And it's not just OpenBeken - see example projects that I made with cooperation and support from Elektroda: Relay driver compatible with Home Assistant / Tasmota HTTP + 3d printed case Fubarino Eth (PIC32MX795F512H and ENC28J60) board for Arduino IDE

Of course, not everything has to be on Elektroda, so you have a green light to create the database in json files and add some kind of frontend on any page you need. Still, if you want to support my purpose, keep at least your teardown topics here: Teardowns Section Sample of my teardown with schematics drawn: Four-channel relay controller Tuya WiFi SmartLife 4CH 10A schematic Don't worry, you don't have to go THAT DETAILED, a basic brief on device is good as well.

I am also working on much more devices (teardown + analysis + support), for example a TuyaMCU door sensor below: (it's using a battery powered devices Tuya system, Tuya has a very good documentation about it, basically TuyaMCU enables power of wifi module only when data is needed to be reported)

[btsimonh]

@iprak - if in the device defn, we had a list of links, rather than link1/2/3, maybe we could have [{link:{ description:"some text", link:"https://blaa.com/device.html"}}, {link:{...}}]. Then we can link one or more posts on the forum, link to blakaddr's descriptive, link to wiki page, link to github issues, link to tuya hacking info, etc. The forum posts are quite good, because often flashing troubles are discussed there.

If blakadder's site gathered from the same document, the flashing links etc. are very worthwhile.

[openshwprojects]

I second to that. It would be great if we could just make one database with @blakadder .

I do multiple detailed teardowns per month, but I am just one person so I won't ever analyze all available devices.

A sample recent teardown - two bulbs with NEW module - WB2L_M1 (BK7231N version of WB2L), warning - not yet translated - https://www.elektroda.pl/rtvforum/topic3903356.html