Forking from the extension host fails when running tests

Clone the extension samples repo, and in the helloworld-test-sample, make the test look like this:

	test('Sample test', async () => {
		await new Promise<void>((resolve, reject) => {
			const child = fork('hello.js', ['8001'], { stdio: 'pipe' });
			child.stderr?.on('data', d => console.log(d.toString()));
			child.on('close', code => code ? reject() : resolve());
		});
	});

And also add version: 'insiders' to runTests() in runTest.ts. Then, npm run test
It fails:

/Users/connor/Github/vscode-extension-samples/helloworld-test-sample/.vscode-test/vscode-darwin-insiders/Visual Studio Code - Insiders.app/Contents/Frameworks/Code - Insiders Helper.app/Contents/MacOS/Code - Insiders Helper: bad option: --vscode-utility-kind=extensionHost

This broke js-debug's tests where we use that for debug servers: https://dev.azure.com/vscode/VS Code debug adapters/_build/results?buildId=68145&view=results

@deepak1556 I see two issues here:

the recent addition of --vscode-utility-kind=extension-host to indicate the extension host in the process explorer causes bad option: --vscode-utility-kind=extensionHost
but even when I revert that change, the utility process seems to exit with a code of 9 and not 0 which is a regression compared to not using utility process

If this is related to #154922 then I can add that my fork is killed when it should stay alive.

i have pushed a workaround to detect extension host via probing for --utility-sub-type=node.mojom.NodeService but I think there are two follow ups:

why is a forked process from a utility process inheriting the execArgv
how can we add custom arguments in the future when we start to use the utility process for more things (such as terminals or file watchers)

execArgv affect the launch of a process, these arguments also gets validated by Node.js and the array can only contain arguments that are supported by Node.js and V8, any unsupported arguments will cause the process to abort https://github.com/nodejs/node/blob/cabf429b1e6e5b856a07d846b3d8f752bdb38241/src/node.cc#L862-L866.
If you want to pass custom arguments into the launched process, then the args[] should be used and this will appear in the process as process.argv.
For the process explorer situation, it is a bit unique because we detect the type based on the arguments that are used to launch it process.execArgv. We already provide a serviceName when creating the utility process, currently this does not get reflected in the --utility-sub-type, I will provide a different flag from the runtime that will ensure the serviceName is also reflected in the launch args and we can use that to distinguish in the process explorer.

This bug has been fixed in the latest release of VS Code Insiders!
@connor4312, you can help us out by commenting /verified if things are now working as expected.
If things still don't seem right, please ensure you're on version 1cd90cceddf3c413673963ab6f154d2ff294b17c of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.
Happy Coding!

This is back

Yes, my bad of restoring what we had before. Will create a follow up issue for Deepak to better support this.


Add ability to paste text and images

Hi it occured to me that I wanted to copy some text and some images while in mouse pointer mode and paste them as artifacts to the pen mode.
Can we have this feature ?

both paste images and text works : for text, the paste into the dialog area after creating text is working. The same you can create a new clipart directly from an image stored in the clipart.

Hi ι meant directly also drag and drop. I work with two monitors one is windowed to ppink. I'd like to be able just to paste clipboard on page or drag and drop. It is much faster and the workflow is much more fluid. Also this would work by switching to pointer mode copy something,  switch mode paste on page.  I really hope you take some time to complete this project. You have put so much detail in it.

This feature is complex and is not compatible with touchscreen. I will not spend time on this


How to flash ?

Hi,
If i want to test this firmware what is the process of flashing it to the chip?
Is it possible to use a chip clamp to flash the chip or de-soldering and re-soldering it the only way?
Thank you very much for your work !!
-DM

You can try to use this sketch with library:
https://github.com/mightymos/OnbrightFlasher
The sketch is intended to be run on the built in ESP8265.
But you'll have to use an external Arduino board.
This is because the RESET pin functionality is probably disabled on Sonoff (set to GPIO) but handshake needs to occur at microcontroller startup.
If you power the whole board up both microcontroller and ESP8265 will start up but ESP8265 startup is slower and so handshake will miss the microcontroller.
Instead you can have the separate Arduino powered, and have I2C pins connected to the Sonoff microcontroller.
The Arduino will be constantly trying to handshake while powered.
Then apply power to the Sonoff and handshake should occur.
If it does not complete handshake, will need to power cycle Sonoff until it does.
Then you'll need to erase chip to unprotect it.
Then can finally write hex file line by line to microcontroller.
The sketch does not easily set configuration bytes now.
So that will need to be added eventually to make this whole process easier (to use built in ESP8265 to flash).
Also some script on PC side will be needed to make sending hex file lines easier.
Do you have an Arduino board around, maybe something like an ESP32?
I can help with hardware hookup but need to know what you have first.
Possibly will try on my side first too to make sure it can work.

@mightymos thanks for reaching out.

A step by step guide + a picture of the pins on how the wiring to the ESP32 board etc need to be wired will help a lot.

I have been able to erase the microcontroller with an external ESP32 board.
I am working on setting the configuration bytes so the built in ESP8265 can be used afterward because I think that will be easier.
I will respond once I have made progress.

@mightymos can you write the instructions to erase the micro-controller with an external ESP32 board so I can test if I can get that working?

You can follow the usage instructions here now:
https://github.com/mightymos/OnbrightFlasher/blob/main/usage.txt
However, if something is unclear please ask me questions.
It is best to power both boards up from separate 3.3V supplies.
Do you have a couple usb to serial adapter boards with 3.3V output?

@mightymos can you explain how I'm suppose to connect the pins ?
the picture doesnt really explain it
from which pins on the d1 to which pins on the rf bridge ?

You need to install the SoftWire library in the Arduino IDE.
You might also need to install esp8266 board support:
https://randomnerdtutorials.com/how-to-install-esp8266-board-arduino-ide/
I am assuming this matches your D1 board, let me know if it does not:
https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/
So the D1 board is, I assume, connected to computer by USB to upload.
Then GPIO4 SDA (pin D2) on D1 board is connected to SDA pin on Sonoff (J3 connector).
Also GPIO4 SCL (pin D1) on D1 board is connected to SCL pin on Sonoff.
On Sonoff, you can have ground connected to your separate power supply.
Once you are ready to try handshake, you can apply 3.3V to Sonoff 3.3V pin (any one should work, but might make sense to just use J3 connector).

@mightymos did this work properly ?

It looks like the commands might have worked, except the chip read should be 'A' for this microcontroller.
You will have to redo handshake with powerup and see if it displays 'A'.
Also, you did not write any hex to microcontroller?
You can try sending all lines from blink.ihx once you see chip read 'A'.

ok so after a bunch of fiddling I managed to flash it and get the red led to blink.
now what ?

That's great.
The  project hex file is too big for this type of manual flashing right now.
Because it includes a much of other stuff besides pass through mode.
Let me create a simpler version and we can try to flash that.

I wonder if we can modify the flasher program to flash the hex automatically rather then pasting line by line.
It can help a lot

That is true.
I see two ways:
[1] Send file line by line with a script on computer side
[2] Modify or replace sketch with ability to handle an entire file sent over serial port
Either approach would be helpful long term but I could not do either quickly.
I will try to make a simpler version of the pass through mode first.

I created a branch that tracks the simpler pass through mode firmware.
Hopefully in the future the source code can be better organized.
And/or the flashing can be made easier.
In either case, I have attached a simple pass through mode hex.
I have also attached my ESPHome yaml which demonstrated pass through is working.
RF-Bridge-OB38S003_SimplePassThrough_01-14-2024.zip
sonoff_bridge.zip
Are you using ESPHome?

I'm going to try and flash it sometime today and report back.
I have two rf bridges and the one I used to try to flash the rf chip's firmware has Tasmota but I'm going to flash it with esphome since that is my preferred custom firmware.
Either way thank you very much for all the support you've given me.
Once I get everything working I'll try to write documentation on how to flash the firmware and contribute it to the repo.

@mightymos  I was able to flash the code and get ESPHome going.
Does pass-through mode also works for transmitting or only receiving ?
I added this code to my ESPHome config and It doesnt turn on the device I want it to turn on.
switch:
  - platform: template
    name: RF Power Button
    optimistic: true
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '10111100110001100101010110101'
          protocol: 1
          repeat:
            times: 1
            wait_time: 0s

Are you using Home Assistant to toggle switch?
If so you might want to remove device from Home Assistant and re-add.
I did change the switch name to RF Transmit, so in my case RF Power would no longer exist.
I have done transmission from OB38S003 previously but it was not very thorough.
The firmware when in serial mode does not really yet support transmission.
I am not sure about other suggestions.
We can keep trying to exchange ideas until it works.

I did want to comment that my receiver with Tasmota is a Sonoff R2 v1.0 (black box) running Portisch firmware.

If I understand you correctly the firmware  in serial mode (pass through) doesn't support transmitting yet.
I think it will be great to add that feature.
Once that feature is added this firmware should be as good as the direct hack just without the hard work of soldering/cutting traces etc.
Either way amazing work!!

Do you have an oscilloscope or logic analyzer?

Do you have an oscilloscope or logic analyzer?

I do not.

You might be able to use something like this to inspect the transmit pin with another of your D1 boards:
https://github.com/aster94/logic-analyzer
There are also logic analyzers that work with pulseview for about $20 USD.
That would at least indicate if the transmit pin is toggling or not.

What is the transmit pin on the j3 connector that I need to monitor?
On Thu, Jan 18, 2024, 8:39 AM Jonathan Armstrong @.***>
wrote:

You might be able to use something like this to inspect the transmit pin
with another of your D1 boards:
https://github.com/aster94/logic-analyzer
There are also logic analyzers that work with pulseview for about $20 USD.
That would at least indicate if the transmit pin is toggling or not.
—
Reply to this email directly, view it on GitHub
https://github.com/mightymos/RF-Bridge-OB38S003/issues/4#issuecomment-1897890007,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACVK2JT3SYG3RGT66FEXSPTYPC7RJAVCNFSM6AAAAABBUUSZV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJXHA4TAMBQG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Nevermind about the sending issue I was able to confirm that sending works.

Nevermind about the sending issue I was able to confirm that sending works.

That's great, was it something simple, how were you able to confirm?

I'm tinkering with all kinds of RF devices since I'm trying to control my Rf fans.
So I got all kinds of devices from aliexpress in order to try and reverse engineer the remote.
One of them is the cc1101 transponder that arrived a few days ago and I was able to set it up today and I could see the rf signals coming in from the sonoff rf bridge with the serial pass through firmware.
Your excellent work makes it very easy to modify the device without too much Hassel and no soldering requirments.

For future reference here are pin descriptions that can be further notated:
https://github.com/mightymos/RF-Bridge-OB38S003/blob/main/notes/sonoff_r2v2.2_connector_pinouts_fv1.txt
That's great you saw some radio activity.
Keep testing and do let me know how things go.

@mightymos
First of all thanks for the hard work on this!
I don't have a spear ESP32 board for flashing the MCU, so I am going to buy a SyncMOS MSM9066 MCU Programmer MCU. Could you share the procedure and pinout when using this method.

@syepes i highly recommend you buy a nodemcu or a esp8266 d1 mini
They are much cheaper and easier to flash
Also I recommend you get a serial flasher that has 3.3v output or a 3.3v battery to power the chip for during flashing.
Also header pins helped a lot during flashing and they prevent you from needing to solder anything

Thanks I am receiving a esp8266 d1 mini this week and I already have the series flasher.
It would be appreciated the procedure on what need to be flashed on the D1 and than where are the last hex lines that I need to flash.
I also have two Sonoff R2 one with the direct hack + esphome and one unmodified that I'll be testing with this method

You'll need to upload the OnbrightFlasher sketch to the ESP8266 D1 mini or similar board.
You could actually have used one of the Sonoff ESP8265 to flash the microcontroller on another board.
But having the separate mini is probably convenient.
You can go to the Releases page of this repository to get the PassthroughMode hex file for the microcontroller.
There are instructions in the readme and a usage.txt at the OnbrightFlasher repository.
They probably should be combined and edited.
If something is not clear just ask for help.
If you did for some reason want to use the official MSM9066 programmer, here is a picture of pins:

Here are the SMAP AC settings for the MSM9066 official programmer:

@mightymos
I have finally gone with the ESP8266 D1 board, but I am seeing these error when powering the Sonoff.

This is the pin connection:

GPIO4 SCL (pin D1) on D1 board is connected to SCL pin on Sonoff
GPIO4 SDA (pin D2) on D1 board is connected to SDA pin on Sonoff

Do you know what could be wrong?

The software I2C library is probably taking too long to time out (if nothing is connected to bus) and then the software watchdog is thinking the program is stuck so it forces a reset. I probably need to improve the sketch so this does not happen.
I think you can make it work.
Have ground connected on the target but 3.3V disconnected on target.
Upload the sketch to the D1 board.
Then immediately change to serial monitor and type "handshake".
Then apply 3.3V to target board.
I think target should then detect handshake and other instructions can be followed.

Thanks for the pointers, but I have been trying for 1h and could not get it to display Connected...
I can not figure out whats wrong, I have double checked the pins and they look correct, I have also tried different timings when applying the power but no luck :-(

It looks correct...it is always a possibility that without soldering in headers you have a loose connection(s).
I think you should try it by leaving the 3.3 V Power Supply plugged into USB but leave the VCC pin on the target end disconnected.
Then when you are ready to apply power touch and leave 3.3V pin touching.
If you cannot get it to work we can investigate further.

What output are you seeing in serial monitor?

I pushed changes to the OnbrightFlasher repo.
I shortened the softwire i2c timeout so that the watchdog on the processor should no longer reset while waiting in handshake state.
I get this output in the serial monitor now:
Ready.
Entering [idle] state.
Type [handshake] to attempt connection to target.
Type [idle] and then [handshake] to start from the beginning
handshake
Reset to handshake

Chip failed to read
Can try command [signature] over serial port to see if Chip read: A
signature
Read chip type...Chip read: A

Thanks for the update, I am still having the same issue. I never see the Connected... string message in the monitor. I have also tried another D1 board :-(
Question, when powering the Bridge on VCC do we need to press the reset button or something else that I am missing?

You should not need to hold the reset button on the bridge during power up.
The reset button is only used to place the ESP8265 in boot mode.
With the fixes now, you should just need to upload sketch to D1 board once.
Just leave it running and can issue commands.
Type [idle] to start over, followed by [handshake] if retrying handshake.
Then apply power to target bridge.
As you can see in my output above, for some reason now the chip read is failing during handshake.
However handshake must have worked because I am able to issue [signature] command and read a hex "A" which is correct for the chip type.
What serial output do you get when you try?

I've updated OnbrightFlasher and the handshake seems to be reliable now.
Appreciate anyone that can test on D1 board.

I would like to test it but i just have a esp32 s3 mini

I've updated OnbrightFlasher and the handshake seems to be reliable now.
Appreciate anyone that can test on D1 board.

I'll try to so some testing tonight

@matlab22 I added support for ESP32 which works on my ESP-WROOM-32. But I need to know exactly what gpio pins are available on your board. Can you provide a link to the actual board you purchased?
@syepes I realized the instructions were unclear in readme to say the least...one potential problem is in Arduino IDE you need to set serial monitor to "Both NL & CR" at 115200 baud. Otherwise the command parsing will never work. I have gotten ESP8265 to sonoff target and ESP32 to sonoff target working reliably and others are testing.
@the-mentor Thanks, appreciate the help for syepes.

I have a yd-esp32-23 hosting an esp32-s3-wroom-1.
https://mischianti.org/vcc-gnd-studio-yd-esp32-s3-devkitc-1-clone-high-resolution-pinout-and-specs/

I just use the esp32s3.name=ESP32S3 Dev Module

I just use the esp32s3.name=ESP32S3 Dev Module

Ok, I added support for the ESP32S3 and arbitrarily used gpio4 and gpio5 for SDA and SCL pins.

I just use the esp32s3.name=ESP32S3 Dev Module

Ok, I added support for the ESP32S3 and arbitrarily used gpio4 and gpio5 for SDA and SCL pins.

Perfect thank you 👍 I guess then I have to pass the 23 lines from https://github.com/mightymos/RF-Bridge-OB38S003/releases/download/v0.2.0/RF-Bridge-OB38S003_PassthroughMode.hex
the 192 from the serial mode are a bit to much. Doing it by hand. I might make a python script handling it or do you have already something?

I just use the esp32s3.name=ESP32S3 Dev Module

Ok, I added support for the ESP32S3 and arbitrarily used gpio4 and gpio5 for SDA and SCL pins.

Perfect thank you 👍 I guess then I have to pass the 23 lines from https://github.com/mightymos/RF-Bridge-OB38S003/releases/download/v0.2.0/RF-Bridge-OB38S003_PassthroughMode.hex the 192 from the serial mode are a bit to much. Doing it by hand. I might make a python script handling it or do you have already something?

I do not know any python so have no script unfortunately.
You are right, manual copying is tiresome.
Fortunately, if the passthrough flashing works the first time then it only needs to be done once.
However, for the long term a script or way to upload the entire hex would be preferred.

I got around to testing the updated flasher and it seems like it was much easier this time around

I got around to testing the updated flasher and it seems like it was much easier this time around

With the ESP32 module I have I seem to get write errors during hex flash. Then I have to repeat sending hex lines.
With the ESP8265 in sonoff used to flash another target sonoff I do not get errors while writing.
I am not sure what is going on with the errors on ESP32.

I tried to use ChatGPT to find a way to add a command to the Arduino code to flash all the lines one after another but my C++ skills are terrible.
I also tried to write a python script that uses serial but because of all the back and forth between reading and writing I also failed to make the process easier :(

I tried to use ChatGPT to find a way to add a command to the Arduino code to flash all the lines one after another but my C++ skills are terrible.
I also tried to write a python script that uses serial but because of all the back and forth between reading and writing I also failed to make the process easier :(

Thanks for looking into it, there would be a learning curve for sure.

Thanks for the pointers, but I have been trying for 1h and could not get it to display Connected... I can not figure out whats wrong, I have double checked the pins and they look correct, I have also tried different timings when applying the power but no luck :-(

@the-mentor Did you have to do something special with the D1 flashing?

It looks like your setup is missing a common gnd.

Thanks for the pointers, but I have been trying for 1h and could not get it to display Connected... I can not figure out whats wrong, I have double checked the pins and they look correct, I have also tried different timings when applying the power but no luck :-(

@the-mentor Did you have to do something special with the D1 flashing?

It looks like your setup is missing a common gnd.

That's a valid observation but the ground through the USB connector on both devices should I think be common. It could be tested with multimeter by attaching one lead to ground on USB connector at PC side and seeing if voltage can be measured on each device (e.g. 3.3 V).

I had a lot of error messages, turned out I had to read the instructions fully before i succeeded:
:1D01CF0002C290AF09A291E433F509EFB5090280D7E5096004D28780CFC28780CB2B
Wrote 29 bytes

:06003500E478FFF6D8FD9F
Wrote 6 bytes

:200013007900E94400601B7A009001EC780175A000E493F2A308B8000205A0D9F4DAF275A6
Wrote 32 bytes

:02003300A0FF2C
Wrote 2 bytes

:20003B007800E84400600A790175A000E4F309D8FC7800E84400600C7900900001E4F0A3C3
Wrote 32 bytes

:04005B00D8FCD9FAFA
Wrote 4 bytes

:0D00060075810912014FE5826003020003BD
Wrote 13 bytes

:00000001FF

mcureset
MCU reset...

I will make a python script to write the hex files and post it here.

make a new function reset_mcu where you send mcureset and the respons should be mcureset new line
MCU reset...

Here is the script I made: (https://github.com/mightymos/OnbrightFlasher/pull/1)

@matlab22 very cool script.
I will test it out when I get a chance and provide feedback

@matlab22 the script worked great.
I think you can add a step to do the setfuse 18 249 every time since it dosen't cause any issues if you do it every time.

Ideally for a general purpose flasher, we need to read the fuse setting, modify only the bits that should be changed, and then write the fuse byte back.
I might also need wrapper functions that only do specific changes like set reset pin to gpio or set reset pin to reset function.
That is instead of encouraging user to modify raw bytes.
However, I'm not sure when I'll get to that, but can keep it in mind.
I'm working on allowing both SoftWire or Wire libraries to be used for I2C.
Will get that tested and uploaded first.

I was often seeing errors with SoftWire on my ESP32-WROOM board.
This required repeated sending of hex lines.
Wire library is now available to use which allows hardware I2C.
I no longer see errors with ESP32 board.

I have problem flashing the chip. Actually I don't have spare ESP boards so I tried flashing with Arduino Mega 2560 board and that didn't work so I also tried to write my own python code with smbus library to flash it using raspberry pi, but that failed too. Both seems to be same as https://github.com/mightymos/msm9066_capture/blob/main/erasecode_bench_supplies3.3V_turnedon_08-22-2023.sr when checking with logic analyzer. It gives ACK for the reset 0x7c but it gets NACK from writing "read config byte" 0x09. Do you have any idea what might be the problem?

I have problem flashing the chip. Actually I don't have spare ESP boards so I tried flashing with Arduino Mega 2560 board and that didn't work so I also tried to write my own python code with smbus library to flash it using raspberry pi, but that failed too. Both seems to be same as https://github.com/mightymos/msm9066_capture/blob/main/erasecode_bench_supplies3.3V_turnedon_08-22-2023.sr when checking with logic analyzer. It gives ACK for the reset 0x7c but it gets NACK from writing "read config byte" 0x09. Do you have any idea what might be the problem?

Sorry, there are multiple places that use the reset chip 0x7c and read config byte 0x09, so I do not know which sequence you are referring to.
As you say during handshake, a reset chip 0x7c is written in a loop after device address has been written. Reset chip is repeatedly written until an ack is received in order to continue handshake. The loop can also stop after say ten nacks and exit handshake. Note that this does not reset chip, to actually reset microcontroller 0x7c must be read from. After ack is received during handshake additional bytes are written as part of the handshake sequence.
To read a config byte you must write device address, command 0x09, data address to read, and then request read. So reading configuration byte at address 0 should be 0xA which is the chip type.
It looks like the Arduino Mega 2560 rev3 board has pins D20 (sda) and D21 (scl) for I2C communication. How did you modify the sketch to try flashing? What output did you see in the serial monitor?

As you say during handshake, a reset chip 0x7c is written in a loop after device address has been written. Reset chip is repeatedly written until an ack is received in order to continue handshake. The loop can also stop after say ten nacks and exit handshake. Note that this does not reset chip, to actually reset microcontroller 0x7c must be read from. After ack is received during handshake additional bytes are written as part of the handshake sequence.

Writing the reset register 0x7c in a loop gets acked so it continues from that. 0x7d and 0x2d after that get nacked, but I think that it is doing the same for you.  Then it waits 120ms and tries to write 0x09 and 0x00 to address 0x7e, but it fails as it gets NACK for writing the first byte 0x09. It does the same with Arduino Mega and my python script on raspberry pi.

It looks like the Arduino Mega 2560 rev3 board has pins D20 (sda) and D21 (scl) for I2C communication. How did you modify the sketch to try flashing? What output did you see in the serial monitor?

I added int sdaPin = 20; and int sclPin = 21; and changed Wire.begin(sdaPin, sclPin); to Wire.begin(); when using wire library. It seems that both Wire and SoftWire does the same thing. Here is serial monitor output:
Ready.
Entering [idle] state.
Type [handshake] to attempt connection to target.
Type [idle] and then [handshake] to start from the beginning
handshake
State changing to handshake
cycle power to target (start with power off and then turn on)

Handshake succeeded
Status: 3
NACK on transmit of data
Chip read type FAILED
Chip type reported was: 0xD5
Can try command [signature] or [idle] then [handshake] to retry

Sometimes I also get this on the esp32 Chip type reported was: 0xD5 the latest python script has a retry and for me this works. Have you tried the script? Is your Status: 3 persistent?

Have you tried the script? Is your Status: 3 persistent?

I hadn't tried the script before, but I tried it now. Status: 3 is persistent and happens every time also when using the script. Maybe I need to order some spare ESP board and maybe couple more rf bridges. Do you have recommendations about compatible ESP boards?

@otsoni I guess that board has 10kohm pull ups on those lines, but I think logic is 5V. I do not know if the OBS38003 is tolerant of 5V. The other possible issue is that internal pull ups on either flasher or target are also enabled which could be out of range. I will try to figure out more.

That's true, Arduino Mega has logic level 5V so it might be problem for OBS38003 if I2C SDA and SCL are pulled to 5V. But I think that it hasn't fried the chip as it is still acking the first reset. But Raspberry Pi has 3.3V logic level and it is not working there either. But that is running my own horrible python script and I think that smbus library is using I2C one byte per millisecond (frequency is 100kHz, but separate bytes are sent just one per millisecond) and that might be problem there. Maybe I need to try to do it without smbus library and maybe using C, but I'm not fluent in it.
Anyway, I'm ordering couple more RF Bridges and some separate ESP boards so I can get it fixed.

@otsoni There is at least one more thing to try. I now include support for the SoftwareWire library, another software i2c library that supports AVR (only avr I think). It should work with your board but I cannot try it myself. You'll need to uncomment just the softwarewire line in projectDefs.h. The pins use the macros PIN_WIRE_SDA and PIN_WIRE_SCL.

There seems to be something wrong with my setup as I am unable to flash it with D1 mini and ESP32 too. Is there need for some kind of hardware mod and does it matter what is running on the esp chip on rf bridge? I have two boards and other is running original sonoff firmware on esp and other is running blank esphome but neither seem to work. Maybe I need to do some more testing and try to figure out what is wrong

@otsoni It seemed like others had the most success with the D1 mini. I do not have one but may need to order.
There should not be any hardware modification required except installing header pins.
It should not matter if the ESP8285 on the rf bridge is erased, however it should not hurt especially if you plan to erase anyway.
It might help if you post a photo of your setup.
Otherwise just a pinout would also be helpful.
This is an example of my ESP32 serial monitor output, what are you seeing?
ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13964
load:0x40080400,len:3600
entry 0x400805f0
Ready.
Entering [idle] state.
Type [handshake] to attempt connection to target.
Type [idle] and then [handshake] to start from the beginning
handshake
State changing to handshake
cycle power to target (start with power off and then turn on)

Handshake succeeded
Status: 0
Success
Chip read: 0xA
Connected...
Returning to idle state...

Here is a photo of my setup:

So pinout is following:
Breadboard plus and minus powered with 3.3V
D1 mini GND to breadboard minus
D1 mini SDA to rf bridge SDA on J3
D1 mini SCL to rf bridge SCL on J3
Breadboard minus to rf bridge GND on J3
Breadboard plus to rf bridge 3V3 on J3
USB between computer and D1 mini for data and power for D1 mini.
Maybe I still check with oscilloscope if my 3.3V power supply is dropping voltage on startup or something, but otherwise I have no idea what to do next.

By the way, it seems that in some photo (https://user-images.githubusercontent.com/3618442/190150761-00fe2fa4-8e04-437a-8155-1d3f154ed732.jpeg) the marking on the OB38S003 chip is 8R08A1 L51CN1 and in my chip the marking seems to be 8R08A1 L53CN1 so the 51 has changed to 53. Can somebody confirm their marking on known working chip?

This Can you post the log from the terminal?
Don't mind the marking. Only the first line is relevant the rest are production specific numbers. Probably: Factory code, production date, yield ...

;ld��|�l�|�l�c|����s�c�c��nn�dno���cp��l{d{dx�g��d��co�|���c��gg�l��l`�ggl`'s���ncd�lp�o�r������cn�|�c��oo�l`�ggd`n{���oc��`{��gb��`��{�dd`��o�d����g�r��g|�l�d`c��|{�l�o��o�l`��s�l�l��Ready.
Entering [idle] state.
Type [handshake] to attempt connection to target.
Type [idle] and then [handshake] to start from the beginning
handshake
State changing to handshake
cycle power to target (start with power off and then turn on)

Handshake succeeded
Status: 3
NACK on transmit of data
Chip read type FAILED
Chip type reported was: 0x20
Can try command [signature] or [idle] then [handshake] to retry

It seems that the board is sending info on baud rate of 74880 on reset so that is the first line. Here is the same with correct baud rate:
 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3424, room 16
tail 0
chksum 0x2e
load 0x3fff20b8, len 40, room 8
tail 0
chksum 0x2b
csum 0x2b
v00045890
~ld
rf cal sector: 1020
freq trace enable 0
rf[112] : 0�

it looks like something with your D1 board is of. Can you try the serial prompt reset cycle without anything attached?

I rewoke it looks like the bootloader is printing out on 74880 and the application on 115200. So far so good.
Can you check the I2C signals? logic analyzer or scope?

I have combined scope and logic analyzer, but it's kinda vintage so I just upload images as it is kinda hard to get data out. And it has just 8K memory so I can't fit everything to one timing sample and need second trigger for getting sample of things happening after 120ms waiting.
Here is the scope signal for 3.3V for rf bridge when connecting to voltage. Green marker is 3.3V and yellow marker is 3.0V. Other power supplies I tried are worse than this

Here is the handshake part on logic analyzer. Everything seems fine for me.

Same on power supply on scope:

This is the part for reading the chip info after 120ms waiting and here it is failing. It seems that it is acking the address, but it is nacking the data, both bytes:

I checked the voltage on power supply here too, but forgot to take photo. It was really near 3.3V at that time.

@otsoni I just tried powering the Sonoff target with my ESP32 board directly.
It will only work if I first erase the ESP8285 on target.
This is likely because if the ESP8285 is connecting to Wifi it can be drawing too much current and/or drawing current too quickly and this produces a voltage glitch on either the flasher board or the target which interferes with a clean startup.
Could you try erasing your ESP8285 and connect your Lolin module directly to target (leave target 3.3V pin unconnected until after issuing handshake command)?
If you have the Lolin D1 mini v4.0.0 it seems to contain a ME6211C33 voltage regulator which can provide 500mA:
https://www.wemos.cc/en/latest/d1/d1_mini.html
https://datasheet.lcsc.com/lcsc/Nanjing-Micro-One-Elec-ME6211C33M5G-N_C82942.pdf
One of my Sonoff bridge microcontrollers contains the marking M08CN1.
Unfortunately I do not think the datasheet for the OB38S003 explains what these second markings mean.
So I am not sure what your different markings mean.
Hopefully it is just a manufacturing date and does not change the functioning of the chip.
I will try to look into it further, especially if it somehow changes the flash procedure.
Apparently, the 8R08A1 M08CN1 is present in other Sonoff devices as well:
https://github.com/arendst/Tasmota/issues/17944

@mightymos erasing rf bridge chip didn't fix it. It seems that for some reason powering the rf bridge with my Lolin D1 mini does something strange and it kinda resets the serial (disconnects and connects it back). Maybe it is doing it because it is drawing too much power or something, I don't know. It seems that my nodeMcu works better and it doesn't do that reset thing, but it's still not working, same thing for my esp32 board, except that on esp32 board Wire library is not working at all

@otsoni
Ok, I am ordering a Lolin D1 mini v4 to try myself in the future.
You erased rf bridge esp8285 with esptool?
What specific nodemcu and ESP32 boards do you have?
I may just need to try Lolin board myself and see if I can reproduce problems.

You erased rf bridge esp8285 with esptool?

Yes, I erased the rf bridge esp8285 with esptool and at least it's not showing any led activity anymore.

What specific nodemcu and ESP32 boards do you have?

I have board that says to be LoLin new NodeMcu V3, but it might be clone. ESP32 board that I have seems to be clone of DOIT ESP32 DEVKIT V1, at least it doesn't have DOIT logo printed. I'm not sure if the D1 mini V4 that I have is also clone or not.

Okay, the DOIT board is the most similar to what I have at the moment so we can stick to that board for now.
The pinout I see here shows that sda and scl pins are GPIO21 and GPIO22 respectively:
https://www.circuitstate.com/pinouts/doit-esp32-devkit-v1-wifi-development-board-pinout-diagram-and-reference/
So in the sketch under CONFIG_IDF_TARGET_ESP32 you'll need to change to:
  int sdaPin = 21;
  int sclPin = 22;

In projectDefs.h you can uncomment only USE_WIRE_LIBRARY at first.
You can then connect those pins to respective pins on target.
Also connect ground to target (pin 2 next to BOOT push button).
And finally connect 3.3V to target after typing "handshake".
If you need to retry handshake, just disconnect 3.3V pin from target.
Then type "idle" and then "handshake".
Then connect 3.3V pin again and handshake should be attempted again.
What do you get in serial monitor?

I tried it but it's not working. Here is serial monitor output:
Type [handshake] to attempt connection to target.
Type [idle] and then [handshake] to start from the beginning
handshake
State changing to handshake
cycle power to target (start with power off and then turn on)
Handshake succeeded
Status: 2
NACK on transmit of address
Chip read type FAILED
Chip type reported was: 0x7C
Can try command [signature] or [idle] then [handshake] to retry

idle
State changing to idle

handshake
State changing to handshake
cycle power to target (start with power off and then turn on)
Handshake succeeded
Status: 2
NACK on transmit of address
Chip read type FAILED
Chip type reported was: 0x44
Can try command [signature] or [idle] then [handshake] to retry

It seems that SDA and SCL are not pulled up if I have connected it to both boards, but only ESP32 devkit is powered. When powering also rf bridge, it seems to pull those pins up. Is it normal? I also tried to add pullup resistors myself, but it caused strange problems because rf bridge is somehow pulling those pins down and cousing garbage, even when it's not powered.
I also found something interesting when checking with logic analyzer. It seems to be kinda same than yours here https://github.com/mightymos/msm9066_capture/blob/main/erasecode_bench_supplies3.3V_turnedon_08-22-2023.sr, but mine is keeping sda high when reading address 0x7e here https://github.com/mightymos/OnbrightFlasher/blob/main/onbrightFlasher.cpp#L70. Here is photo of that on logic analyzer:

I also found that I have some activity on i2c just after waiting the read operation and your is just getting both sda and scl up. Here is photo from my scope:

@otsoni I need more time to consider the pull up situation, I looked and the Sonoff bridge certainly does not have any external pull ups on the board. The idle state of the i2c bus should be high as I recall.
I am not sure where the ESP32 wire library implementation enables pull ups, it seems it cannot be disabled/specified when initializing.
I did notice in your picture that some of your jumper wires are at an angle when plugged into female receptacles. In other words, they look like diamond orientation compared to square receptacles as though the pin can rotate.
Are the pins rounded or square?
Are you sure your connections are good?
The flasher has to try driving the i2c bus even when the target is unpowered to look for handshake response. There can be an errant response if a pin is floating, but I think it should be okay as long as there is a ground connection. If ground is floating it can appear you are getting i2c activity but it is just junk.

@otsoni Also I will use logic analyzer on OnbrightFlasher so it can be compared with stock flasher captures as soon as I can. Maybe that will reveal something.

Are the pins rounded or square?
Are you sure your connections are good?

I don't really have the best soldering skills, but otherwise the connections should be good. The pins kinda can rotate there. I got a espressif ESP32 DevKitC V4 from my friend at it's also not working. I have three separate rf bridges and they are not working. Is it possible that I have rf bridges from some kind of batch that is not programmable or something. I really don't know what might be wrong. But if you get logic analyzer capture using OnbrightFlasher it might reveal something.

I got it working! I have no idea why, but after running this (https://github.com/mightymos/msm9066_capture/blob/07dd621cb97439575ee9e3cdefc33042d49ead45/esp32_i2c_onbright_flasher.ino) one time it allowed me to run the current OnbrightFlasher too! So now I have one board that works and still two boards that doesn't work if I need to get a LA capture from the old flashing procedure to check what has changed or something

@otsoni That is great news. I hope to improve reliability as time goes on and will update the readme.

@otsoni I just noticed there was a bug in the Atmega2560 board pin definitions, the sda and scl pins were being assigned to the same pin which was clearly not correct. I am now relying on PIN_WIRE_SDA and PIN_WIRE_SCL definitions for boards instead of manually specifying them myself.
I also tried the Lolin D1 mini v4.0.0 and it works well. However, on all the boards I have when I try to use the on board 3.3V regulator to power the target I get a lot of glitches as you have also observed. I am just using a separate bench top power supply to power the target right now. I have also had some okay luck with using a separate usb to serial converter just as a power source.
If you have managed to flash a hex to your Sonoff and get ESPHome/Tasmota working I would suggest leaving it alone. However, if you would like to retest the Atmega2560 board to see if handshake can work that could be helpful to others.

I tried to see what was the problem with my another rf bridge and it seems that the trick on the old script is that it erasing the chip regardless of the status of reading chip type. So it seems that reading chip type on my rf bridges isn't possible before erasing the chip. So now I have to rf bridges that have erased successfully and one rf bridge that is still protected if I need to do some more testing about it. I can try the Atmega2560 next for the erased boards to make sure if it works at all.

It seems that Atmega2560 has at least successful handshake and erase. I didn't try flashing, but I think it should work too. But still I wouldn't recommend using it as it has 5V logic level and OB38S003 has 3.3V logic level

@otsoni Do you mean that you CAN read the chip type after erasing the chip (but not before)? Or not?
If so, can you try to protect one of your rf bridge again (setfuse 18 0), then reset microcontroller, and try to read chip type?
It is a little annoying to relock chip but you should be able to unlock again as you have done previously.
But I understand if you would prefer to leave unlocked and use for smart home integration now.

@otsoni Good point on Atmega2560, I forgot about the voltage translation issue. Thank you for trying, I have updated the readme to help and warn others.

@mightymos Are you sure the protection command is setfuse 18 0? I found somewhere that the protection byte is 0x10 and used setfuse 16 0 and it made my rf bridge to fail handshake again, but I got it back to working again with erasing. It seems that maybe my rf bridges have something different then?
By the way, I have three rf bridges now and I'm using just one for smart home integration and I'm planning to do some development on the extra ones also. So if you want me to test anything, it is possible.

@otsoni You are correct, I was forgetting previous work. I have updated the readme to explain the expected behavior when handshaking/flashing a protected chip. I also started this wiki which will be needed if people eventually need to modify other fuse bits:
https://github.com/mightymos/OnbrightFlasher/wiki

My experience, if it helps anybody else (I tried 4 hours unsuccessfully and then this recipe worked):
Chip would not identify as 0xA until I ignored it and erased it successfully, it then identified as 0xA

Erase the esp
esptool.py --chip auto --port /dev/........
Using Arduino Serial Monitor I then did a handshake that gave the incorrect chip id, ignore that and do an
Very important for handshake, only connect power when handshake is waiting
erase
Then a
setfuse 18 249
Followed by signature
chip then identified as 0xA
Then from command line
python3 flashScript.py
The flash the esp

Example output from flashScript
2024-04-03 23:44:39,817 - INFO - State changing to handshake
2024-04-03 23:44:39,817 - INFO - cycle power to target (start with power off and then turn on)
2024-04-03 23:44:41,716 - INFO - Handshake succeeded
2024-04-03 23:44:41,837 - INFO - Status: 0
2024-04-03 23:44:41,837 - INFO - Success
2024-04-03 23:44:41,839 - INFO - Chip read: 0xA
2024-04-03 23:44:41,840 - INFO - Connected...
2024-04-03 23:44:41,843 - INFO - Returning to idle state...
2024-04-03 23:44:41,945 - INFO - erase
2024-04-03 23:44:42,448 - INFO - Erasing chip...
2024-04-03 23:44:42,449 - INFO - Status: 0
2024-04-03 23:44:42,449 - INFO - Success
2024-04-03 23:44:42,449 - INFO - Chip erase successful
2024-04-03 23:44:42,551 - INFO -
2024-04-03 23:44:43,052 - INFO - setfuse 18 249
2024-04-03 23:44:43,554 - INFO - Set configuration byte...
2024-04-03 23:44:43,554 - INFO - Status: 0
2024-04-03 23:44:43,555 - INFO - Success
2024-04-03 23:44:43,555 - INFO - Wrote configuration byte
2024-04-03 23:44:43,565 - INFO - :1000BB00AE82AF837C007D00C3EC9EED9F50147A23
2024-04-03 23:44:43,604 - INFO - Write successful
2024-04-03 23:44:43,606 - INFO - Wrote 16 bytes
2024-04-03 23:44:43,615 - INFO - :1000CB000B7B001ABAFF011BEA4B70F70CBC00E864
2024-04-03 23:44:43,652 - INFO - Write successful
2024-04-03 23:44:43,655 - INFO - Wrote 16 bytes
......
2024-04-03 23:45:00,798 - INFO - :0C15170075830022E280F7E49322E022BA
2024-04-03 23:45:00,829 - INFO - Write successful
2024-04-03 23:45:00,832 - INFO - Wrote 12 bytes
2024-04-03 23:45:00,837 - INFO - :00000001FF
2024-04-03 23:45:00,938 - INFO - mcureset
2024-04-03 23:45:01,444 - INFO - MCU reset...

hi @diepeterpan
I was able to flash my MCU following your guide and the OB38S003_PassthroughMode file.
Do you have any experiences using Tasmota as well?
I'm not receiving any data ;-(. I have to admit that I never tested my Sonoff bridge with a supported IR-transmitters before flashing. Do I need a custom build of Tasmota?

I've now tried with tasmota-sensors bin and RFrecv on every GPIO, because I only can find GPIO2,-4,-5,-12 and -14

I've tried with

hi @diepeterpan
I was able to flash my MCU following your guide and the OB38S003_PassthroughMode file. Do you have any experiences using Tasmota as well? I'm not receiving any data ;-(. I have to admit that I never tested my Sonoff bridge with a supported IR-transmitters before flashing. Do I need a custom build of Tasmota?

If you are using passthrough mode then ensure you are using tasmota-sensors.bin and configure Tasmota as GPIO1 (RFSend) and GPIO3 (RFRecv) , I initially used but then switched to ESPHOME.

Now I got it working with my low budget remote for sockets :-). But I do not receive anything from my other remotes. I've tried both passthrough and SerialMode.

I've tried with

hi @diepeterpan
I was able to flash my MCU following your guide and the OB38S003_PassthroughMode file. Do you have any experiences using Tasmota as well? I'm not receiving any data ;-(. I have to admit that I never tested my Sonoff bridge with a supported IR-transmitters before flashing. Do I need a custom build of Tasmota?

If you are using passthrough mode then ensure you are using tasmota-sensors.bin and configure Tasmota as GPIO1 (RFSend) and GPIO3 (RFRecv) , I initially used but then switched to ESPHOME.

Now I got it working with my low budget remote for sockets :-). But I do not receive anything from my other remotes. I've tried both passthrough and SerialMode.

As far as I understand SerialMode is not working on the new MCU - OB38S003, that's why I switched to ESPHOME so that I can get the raw messages.

@diepeterpan @Martimlin
Serial mode decoding and transmitting with RFRaw 0xA5 or 0xA8 commands should be working on both EFM8BB1 and OB38S003 board. However, I have not tried every protocol etc. But I am able to receive from a door sensor and transmit/receive between boards.
Nevertheless...it is probably most straightforward to use the passthrough mode along with ESPHome. If that is not even working I can try to help figure out why. I just end up having to reflash between Tasmota and ESPHome for various debugging reasons and that is getting a little annoying lol.

@mightymos How does one flash the new firmware directly on the sonoff without using a second controller?
I'm already running the old passthrough firmware and am looking to try the new decode version

@mightymos How does one flash the new firmware directly on the sonoff without using a second controller? I'm already running the old passthrough firmware and am looking to try the new decode version

The file [https://github.com/mightymos/OnbrightFlasher/blob/main/OnbrightFlasher.ino] has a note that says on the Sonoff ESP8285 pin 16 and pin 24 (gpio4 and gpio5) (or USBRXD and UXBTXD on J3 connector) need to be bridged to SDA and SCL pins.
Or it should say that. I'll try to remember to fix the comment.
Various pinouts for other modules are discussed here:
https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/
The datasheet contradicts this and I don't remember why (0a-esp8285_datasheet_en.pdf).
Of course first you would need to flash the sketch to the Sonoff ESP using the normal method.
Then afterward follow instructions to further flash the microcontroller.

Oh, I saw that comment in the sketch. So I would need to solder those pins. I'll just stick to using an external esp32.
Also, I'm trying to use the new onbrightflasher sketch to update the firmware but I keep getting errors with the wifi and web server setup. Since the network flash is an optional feature, can you tell me which all lines I can comment out so I can do the bog standard install that worked with the sketch a few months ago?

Oh, I saw that comment in the sketch. So I would need to solder those pins. I'll just stick to using an external esp32. Also, I'm trying to use the new onbrightflasher sketch to update the firmware but I keep getting errors with the wifi and web server setup. Since the network flash is an optional feature, can you tell me which all lines I can comment out so I can do the bog standard install that worked with the sketch a few months ago?

That's a good point, but what errors are you getting?
Maybe I can fix that faster and look into giving the option to omit web stuff later.

In file included from C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiSTA.h:29,
from C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFi.h:33,
from C:\Users\Chai\Downloads\OnbrightFlasher\OnbrightFlasher.ino:28:
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:44:25: error: 'network_event_handle_t' does not name a type; did you mean 'esp_event_handler_t'?
44 | #define wifi_event_id_t network_event_handle_t
|                         ^~~~~~~~~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:80:3: note: in expansion of macro 'wifi_event_id_t'
80 |   wifi_event_id_t onEvent(WiFiEventCb cbEvent, arduino_event_id_t event = ARDUINO_EVENT_MAX);
|   ^~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:44:25: error: 'network_event_handle_t' does not name a type; did you mean 'esp_event_handler_t'?
44 | #define wifi_event_id_t network_event_handle_t
|                         ^~~~~~~~~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:81:3: note: in expansion of macro 'wifi_event_id_t'
81 |   wifi_event_id_t onEvent(WiFiEventFuncCb cbEvent, arduino_event_id_t event = ARDUINO_EVENT_MAX);
|   ^~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:44:25: error: 'network_event_handle_t' does not name a type; did you mean 'esp_event_handler_t'?
44 | #define wifi_event_id_t network_event_handle_t
|                         ^~~~~~~~~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:82:3: note: in expansion of macro 'wifi_event_id_t'
82 |   wifi_event_id_t onEvent(WiFiEventSysCb cbEvent, arduino_event_id_t event = ARDUINO_EVENT_MAX);
|   ^~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:41:25: error: 'NetworkEventCb' has not been declared
41 | #define WiFiEventCb     NetworkEventCb
|                         ^~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:83:20: note: in expansion of macro 'WiFiEventCb'
83 |   void removeEvent(WiFiEventCb cbEvent, arduino_event_id_t event = ARDUINO_EVENT_MAX);
|                    ^~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:83:41: error: 'arduino_event_id_t' has not been declared
83 |   void removeEvent(WiFiEventCb cbEvent, arduino_event_id_t event = ARDUINO_EVENT_MAX);
|                                         ^~~~~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:43:25: error: 'NetworkEventSysCb' has not been declared
43 | #define WiFiEventSysCb  NetworkEventSysCb
|                         ^~~~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:84:20: note: in expansion of macro 'WiFiEventSysCb'
84 |   void removeEvent(WiFiEventSysCb cbEvent, arduino_event_id_t event = ARDUINO_EVENT_MAX);
|                    ^~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:84:44: error: 'arduino_event_id_t' has not been declared
84 |   void removeEvent(WiFiEventSysCb cbEvent, arduino_event_id_t event = ARDUINO_EVENT_MAX);
|                                            ^~~~~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:84:8: error: 'void WiFiGenericClass::removeEvent(int, int)' cannot be overloaded with 'void WiFiGenericClass::removeEvent(int, int)'
84 |   void removeEvent(WiFiEventSysCb cbEvent, arduino_event_id_t event = ARDUINO_EVENT_MAX);
|        ^~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:83:8: note: previous declaration 'void WiFiGenericClass::removeEvent(int, int)'
83 |   void removeEvent(WiFiEventCb cbEvent, arduino_event_id_t event = ARDUINO_EVENT_MAX);
|        ^~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:44:25: error: 'network_event_handle_t' has not been declared
44 | #define wifi_event_id_t network_event_handle_t
|                         ^~~~~~~~~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:85:20: note: in expansion of macro 'wifi_event_id_t'
85 |   void removeEvent(wifi_event_id_t id);
|                    ^~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:129:25: error: 'arduino_event_id_t' has not been declared
129 |   const char *eventName(arduino_event_id_t id);
|                         ^~~~~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:131:30: error: 'arduino_event_t' has not been declared
131 |   static void _eventCallback(arduino_event_t *event);
|                              ^~~~~~~~~~~~~~~
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:83:68: error: 'ARDUINO_EVENT_MAX' was not declared in this scope; did you mean 'WIFI_EVENT_MAX'?
83 |   void removeEvent(WiFiEventCb cbEvent, arduino_event_id_t event = ARDUINO_EVENT_MAX);
|                                                                    ^~~~~~~~~~~~~~~~~
|                                                                    WIFI_EVENT_MAX
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:84:71: error: 'ARDUINO_EVENT_MAX' was not declared in this scope; did you mean 'WIFI_EVENT_MAX'?
84 |   void removeEvent(WiFiEventSysCb cbEvent, arduino_event_id_t event = ARDUINO_EVENT_MAX);
|                                                                       ^~~~~~~~~~~~~~~~~
|                                                                       WIFI_EVENT_MAX
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiSTA.h:44:42: error: expected class-name before '{' token
44 | class STAClass : public NetworkInterface {
|                                          ^
In file included from C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFi.h:34:
C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiAP.h:39:41: error: expected class-name before '{' token
39 | class APClass : public NetworkInterface {
|                                         ^
In file included from C:\Users\Chai\Downloads\OnbrightFlasher\OnbrightFlasher.ino:37:
C:\Users\Chai\Downloads\OnbrightFlasher\Network.h:4:11: error: redefinition of 'IPAddress local_IP'
4 | IPAddress local_IP(192, 168, 0, 222); // Set your server's fixed IP address here
|           ^~~~~~~~
In file included from C:\Users\Chai\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.2\libraries\WiFi\src/WiFiGeneric.h:39:
C:\Users\Chai\Downloads\OnbrightFlasher/Network.h:4:11: note: 'IPAddress local_IP' previously declared here
4 | IPAddress local_IP(192, 168, 0, 222); // Set your server's fixed IP address here
|           ^~~~~~~~
C:\Users\Chai\Downloads\OnbrightFlasher\Network.h:5:11: error: redefinition of 'IPAddress gateway'
5 | IPAddress gateway(192, 168, 0, 1);    // Set your network Gateway usually your Router base address
|           ^~~~~~~
C:\Users\Chai\Downloads\OnbrightFlasher/Network.h:5:11: note: 'IPAddress gateway' previously declared here
5 | IPAddress gateway(192, 168, 0, 1);    // Set your network Gateway usually your Router base address
|           ^~~~~~~
C:\Users\Chai\Downloads\OnbrightFlasher\Network.h:6:11: error: redefinition of 'IPAddress subnet'
6 | IPAddress subnet(255, 255, 255, 0);   // Set your network sub-network mask here
|           ^~~~~~
C:\Users\Chai\Downloads\OnbrightFlasher/Network.h:6:11: note: 'IPAddress subnet' previously declared here
6 | IPAddress subnet(255, 255, 255, 0);   // Set your network sub-network mask here
|           ^~~~~~
C:\Users\Chai\Downloads\OnbrightFlasher\Network.h:7:11: error: redefinition of 'IPAddress dns'
7 | IPAddress dns(192,168,0,1);           // Set your network DNS usually your Router base address
|           ^~~
C:\Users\Chai\Downloads\OnbrightFlasher/Network.h:7:11: note: 'IPAddress dns' previously declared here
7 | IPAddress dns(192,168,0,1);           // Set your network DNS usually your Router base address
|           ^~~
exit status 1
Compilation error: redefinition of 'IPAddress local_IP'
This is the error I get. I created the secrets.h and also filled in my ip info in the networks.h file

Also, when trying the flashscript, i get a timeout error
2024-07-06 14:08:07,876 - INFO - Handshake failed (1355)
2024-07-06 14:08:07,877 - INFO - cycle power to target (start with power off and then turn on)
2024-07-06 14:08:08,146 - INFO - Handshake complete...
2024-07-06 14:08:08,168 - INFO - Chip read: 0xA
2024-07-06 14:08:08,169 - INFO - Connected...
2024-07-06 14:08:08,171 - INFO - Returning to idle state...
2024-07-06 14:08:27,324 - ERROR - Timeout reached. No valid response within 30 seconds. Last response was:
2024-07-06 14:08:27,324 - ERROR - State 4 failed. Returning to handshake state.
2024-07-06 14:08:28,434 - INFO - handshake
2024-07-06 14:08:28,434 - INFO - Reset to handshake
2024-07-06 14:08:28,434 - INFO - Handshake failed (1356)

I could not reproduce that error.
Do you have "esp32" by Espressif Systems installed in the board manager?
It would be version 3.0.2.
I also do not understand how you got a script output if the chip is compile and then flash?

Also, when trying the flashscript, i get a timeout error
2024-07-06 14:08:07,876 - INFO - Handshake failed (1355) 2024-07-06 14:08:07,877 - INFO - cycle power to target (start with power off and then turn on) 2024-07-06 14:08:08,146 - INFO - Handshake complete... 2024-07-06 14:08:08,168 - INFO - Chip read: 0xA 2024-07-06 14:08:08,169 - INFO - Connected... 2024-07-06 14:08:08,171 - INFO - Returning to idle state... 2024-07-06 14:08:27,324 - ERROR - Timeout reached. No valid response within 30 seconds. Last response was: 2024-07-06 14:08:27,324 - ERROR - State 4 failed. Returning to handshake state. 2024-07-06 14:08:28,434 - INFO - handshake 2024-07-06 14:08:28,434 - INFO - Reset to handshake 2024-07-06 14:08:28,434 - INFO - Handshake failed (1356)

I could not reproduce that compilation error.
Do you have "esp32" by Espressif Systems installed in the board manager?
It would be version 3.0.2.
I also do not understand how you got a script output if the chip is failing to compile and then flash?

I was using the esp32 dev module board but looks like I have the Wroom-32 model which is different.
I had a copy of an older version of the code without the wifi stuff, so I flashed that and used the flashscript.py to do the rest.
Old code runs fine and is able to do the handshake, erase and set fuse but I needed the flashscript.py to flash the firmware.

I am using the 3.0.2 board. I have an esp 32 c3 super mini. I had a copy of an older version of the code without the wifi stuff, so I flashed that and ran the flashscript.py to do the rest. Old code runs fine and is able to do the handshake, erase and set fuse but I needed the flashscript.py to flash the firmware.

I went ahead and removed the web upload stuff for now since it is interfering and probably unneeded.
I also changed the readme to better explain need for external flasher.
I tried the script and was able to flash the blink.ihx file.
If you flash the serial mode and try it out it would be helpful to know that it worked for you.

@fragpic
I was also able to flash  main_rcswitch_OB38S003.hex  with the script.
I am able to see decoding with Tasmota configured as Sonoff Bridge (25).
Recall should probably flash with tasmota-sensors.bin to support passthrough if used later.

Flash went perfectly now. Sketch compiled without any errors and script worked perfectly.
Do you have an example yaml for using serial mode with EspHome?

Thanks for the quick fix! Flash went perfectly now. Sketch compiled without any errors and script worked perfectly. Do you have an example yaml for using serial mode with EspHome?

No not at the moment.
If no one else contributes one I might make another yaml example but people seem to prefer passthrough mode generally.
I am trying to support everything but it is difficult to test all combinations myself.

I found this example, does it make sense to you?
https://www.irrgang.dev/how-to-flash-the-sonoff-rf-bridger2-with-esphome/
It's using the decoding from the stock MCU firmware.
I can test it and add it to the repo if you think this makes sense.
Thanks again for maintaining this project.

I found this example, does it make sense to you? https://www.irrgang.dev/how-to-flash-the-sonoff-rf-bridger2-with-esphome/ It's using the decoding from the stock MCU firmware. I can test it and add it to the repo if you think this makes sense. Thanks again for maintaining this project.

Yes, I think so. I didn't check it in detail but it looks like they are following this example:
https://esphome.io/components/rf_bridge.html

I found this example, does it make sense to you? https://www.irrgang.dev/how-to-flash-the-sonoff-rf-bridger2-with-esphome/ It's using the decoding from the stock MCU firmware. I can test it and add it to the repo if you think this makes sense. Thanks again for maintaining this project.

Yes, I think so. I didn't check it in detail but it looks like they are following this example: https://esphome.io/components/rf_bridge.html

Sounds good. Let me try that and report back.

I tried this but I dont see any output in HomeAssistant events. The code is meant for the older Sonoff bridge, do you know if the R2.2 version uses the same uart pins from the mcu?

I tried this but I dont see any output in HomeAssistant events. The code is meant for the older Sonoff bridge, do you know if the R2.2 version uses the same uart pins from the mcu?

I was sure the white box Sonoff was the newest one, not older, correct?
I do not know why they listed the board that way. You can see what I think is the proper board assignment here:
https://github.com/mightymos/RF-Bridge-OB38S003/blob/main/example_esphome_yaml/sonoff_bridge.yaml
Anyway, GPIO1 (U0TXD)(pin 26) is radio transmit and GPIO3 (U0RXD)(pin 25) is radio receiver on ESP8285.

I tried this but I dont see any output in HomeAssistant events. The code is meant for the older Sonoff bridge, do you know if the R2.2 version uses the same uart pins from the mcu?

I was sure the white box Sonoff was the newest one, not older, correct?
I do not know why they listed the board that way. You can see what I think is the proper board assignment here: https://github.com/mightymos/RF-Bridge-OB38S003/blob/main/example_esphome_yaml/sonoff_bridge.yaml
Anyway, GPIO1 (U0TXD)(pin 26) is radio transmit and GPIO3 (U0RXD)(pin 25) is radio receiver on ESP8285.

I was referring to the esphome code. That was for the black one with the older MCU.
When trying to use the same code with the OB38S003, it doesnt send any RF messages like it's supposed to.
I am using GPIO1 and 3 for UART. Is there a specific format in which the mcu sends data to the esp in the stock firmware?

I only support the 0xA5 and 0xA8 commands for sending, the Portisch commands are described here:
https://github.com/Portisch/RF-Bridge-EFM8BB1/wiki/Commands
RfSend command should work with Tasmota, see the example here:
https://tasmota.github.io/docs/Commands/#rf-bridge
How do you know if a radio message is received or not?
Does RfSend work for your device?

I only support the 0xA5 and 0xA8 commands for sending, the Portisch commands are described here: https://github.com/Portisch/RF-Bridge-EFM8BB1/wiki/Commands
RfSend command should work with Tasmota, see the example here: https://tasmota.github.io/docs/Commands/#rf-bridge
How do you know if a radio message is received or not? Does RfSend work for your device?

Ah okay, so you only support transmit on the serial mode. I'm trying to receive the code from the remote.
I guess I have to order an SDR and sniff it then. Pass through mode reads the raw signal but I'm unable to do much with that.

I also support receiving on serial mode.
It's difficult to know if there's another problem or if the remote is just an unsupported protocol.
Can you carefully open the remote and see what chip is inside?
Or try to capture with dump in passthrough mode on ESPHome?

Oh okay. Passthrough mode dumps the button click in a weird Pronto format.
It's a ceiling fan remote which has multiple things on it(color changing light, air filter and fan speec with direction) and I think it sends the full state on each press.

If you're seeing data it's good

So can the serial mode firmware decode this as raw?

So can the serial mode firmware decode this as raw?

From my experience decoding the fan remote signal should be done using universal radio hacker and not directly on the esp

Makes sense, just ordered an SDR. Thanks for all the help!

Hi @all
i‘ve successfully flashed Tasmota and done the GPIOs soldering.
when i now klick on „Firmware Upgrade“ to Upload the portisch.hex i get a error Message „File Upload failure code 210“
Do you have any ideas?
Best regards andy

Hi,
thank you for fast responding :)
I use Sonoff Bridge v2.2

thanks andy

Hi, thank you for fast responding :)
I use Sonoff Bridge v2.2
thanks andy

Ok, Portisch does not work on that hardware, it has a different microcontroller.
You will need to flash one of the firmwares provided in this repository.

okay crazy - i've bought it beacause of this video https://www.youtube.com/watch?v=k-FLN1cM4jk
now what do you think what i can do? which firmware do you mean exactly?
or do i have do buy a other bridge?

okay crazy - i've bought it beacause of this video https://www.youtube.com/watch?v=k-FLN1cM4jk
now what do you think what i can do? which firmware do you mean exactly? or do i have do buy a other bridge?

That video is explaining how to modify the hardware itself so the radio pins bypass the microcontroller and radio decoding is performed on the ESP8285 itself. Tasmota uses RCSwitch library.
Alternatively you can achieve a similar result by flashing the passthrough firmware from this repository.
However, you will either need an official flasher or an external Arduino board to act as the flasher.
You can read the instructions under "Flasher (Official)" and "Flasher (Open source)" here:
https://github.com/mightymos/RF-Bridge-OB38S003
You could also just leave the microcontroller with stock firmware and see if it can decode your radio devices without modification.

Okay,
could you please so good and tell me where to find passthrough firmware and which flasher will be needed?

Okay, could you please so good and tell me where to find passthrough firmware and which flasher will be needed?

You need to read everything at the link I provided previously and just be familiar with github layout.
The firmware files are listed under Releases.
Here is the open source flasher sketch and python script for Arduino:
https://github.com/mightymos/OnbrightFlasher
Again you need to read the repository, everything is explained there.

Hi,
Thank you - i've read all and think i am ready - two more questions just to be shure

this controller will work: https://shorturl.at/67CnX
Sonoff ZF bridge: i ve cut some lines as discribed in the video https://www.youtube.com/watch?v=k-FLN1cM4jk
do i have to buy a new one or will it still work with the Arduino Flash project?

thank you

Hi,
Thank you - i've read all and think i am ready - two more questions just to be shure
* this controller will work: https://shorturl.at/67CnX

* Sonoff ZF bridge: i ve cut some lines as discribed in the video https://www.youtube.com/watch?v=k-FLN1cM4jk
  do i have to buy a new one or will it still work with the Arduino Flash project?

thank you

If you have completed the hardware modification Tasmota should decode available radio protocols itself on the ESP8285.
Why do you not just use it that way (and skip flashing microcontroller)?
If you have modified the bridge, flashing the microcontroller will not work.
If the ESP on that module has I2C pins then it should work for flashing.

Hello,
The Sonoff RF bridge does not recognize my signals for rollershutter control and garage doors, so I want/have to flash and modify with your project.
That means I need a new RF bridge 2.2 to flash with Arduino, right because of modifing already?

Hello,
The Sonoff RF bridge does not recognize my signals for rollershutter control and garage doors, so I want/have to flash and modify with your project.
That means I need a new RF bridge 2.2 to flash with Arduino, right because of modifing already?

Assuming you performed the hardware modification correctly, flashing the passthrough firmware to the microcontroller will also not work. Both methods ultimately use the RCSwitch library in Tasmota for decoding.
It is possible you could try using ESPHome for decoding but without knowing the protocol that the roller shutter and garage doors use it is not possible to know beforehand if it will work or not.

Hi,
I want to Control A-OK Motors - what do you think will be the easiest Option?
Am 24.08.2024 um 19:46 schrieb Jonathan Armstrong @.***>:

Hello,
The Sonoff RF bridge does not recognize my signals for rollershutter control and garage doors, so I want/have to flash and modify with your project.
That means I need a new RF bridge 2.2 to flash with Arduino, right because of modifing already?
Assuming you performed the hardware modification correctly, flashing the passthrough firmware to the microcontroller will also not work. Both methods ultimately use the RCSwitch library in Tasmota for decoding.
It is possible you could try using ESPHome for decoding but without knowing the protocol that the roller shutter and garage doors use it is not possible to know beforehand if it will work or not.
—
Reply to this email directly, view it on GitHubhttps://github.com/mightymos/RF-Bridge-OB38S003/issues/4#issuecomment-2308469989, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARZMTQLQNUTYSFS5WKRVPELZTDBINAVCNFSM6AAAAABBUUSZV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGQ3DSOJYHE.
You are receiving this because you commented.Message ID: @.***>

A-OK Motors

You might be able to use a software defined radio RT-SDR to understand your device.
@the-mentor was helping people on Discord to do this, you might be able to talk to them.

Okay thank you,
but i can’t find a repositorie or e-mail to contact him… I despair ☹
Andreas Setzer
phone +34 635 017 887
e.mail @.***
Avinguda Blai Bonet 8
07180 Santa Ponsa, Calvia
Spain – Illes Baleares
[Titel: LinkedIn - Beschreibung: image of LinkedIn icon]http://linkedin.com/ [Titel: Twitter - Beschreibung: image of Twitter icon] http://twitter.com/  [Titel: google+ - Beschreibung: image of google+ icon] http://google.com/
Von: Jonathan Armstrong @.>
Gesendet: Sonntag, 25. August 2024 02:53
An: mightymos/RF-Bridge-OB38S003 @.>
Cc: Andreas Setzer @.>; Comment @.>
Betreff: Re: [mightymos/RF-Bridge-OB38S003] How to flash ? (Issue #4)
A-OK Motors
You might be able to use a software defined radio RT-SDR to understand your device.
@the-mentorhttps://github.com/the-mentor was helping people on Discord to do this, you might be able to talk to them.
—
Reply to this email directly, view it on GitHubhttps://github.com/mightymos/RF-Bridge-OB38S003/issues/4#issuecomment-2308599524, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARZMTQOI6L6WDZUMBGPFF73ZTETHDAVCNFSM6AAAAABBUUSZV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGU4TSNJSGQ.
You are receiving this because you commented.Message ID<EMAIL_ADDRESS>

@asetzeradmin you can join the discord channel via this link
https://discord.gg/QkD3VPw5


Ben/lmb 390 change person in mandataris table

Description
In the mandataris table in the prepare installatievergadering it is now possible to change to person by hovering on the first name and last name and clicking the edit icon.

How to test
Go to a verkiezingen/verkiezingsuitslag/prepare route, hover over a person and update the person.

loving how clean this turned out!


19 Sep 2024 - A11y Theme Builder Meeting Minutes

Date
2024-09-19 - 09:15am EDT
Zoom info

Meeting link: https://zoom.us/j/91013899295?pwd=Qnh5UVN1aUZ4ak9tODgvMVNLNUg5Zz09
Meeting id: 910 1389 9295
Password: 123225
Call-in: +1<PHONE_NUMBER> US (New York) (Check calendar for more options)

Untracked attendees

Fullname, Affiliation, (optional) GitHub username
...

Meeting notices

FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact<EMAIL_ADDRESS>with any questions.

FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

[x] Convene & roll call (5mins)
[x] Display FINOS Antitrust Policy summary slide
[x] Review Meeting Notices (see above)
[x] Approve past meeting minutes
[x] Community WG Update (@PaulaPaul)
[x] Keith's link is available (@aaronreed708 - https://www.youtube.com/watch?v=g9JVOudI5K8&list=PLmPXh6nBuhJvYfhZgdb3LqImhOn5r7Dp)
[x] Mentorship project update (@omesh-omg)
[ ] ...
[ ] AOB, Q&A & Adjourn (5mins)

Minutes

Decisions Made

[ ] Decision 1
[ ] Decision 2
[ ] ...

Action Items

[ ] (from last week) Lise to get Omesh and Aaron CSS and responsive breakpoints and behaviors for #820 design

will provide CSS for framework only for now

[ ] (from last week)Aaron and Evan need to break the Epic that will be worked on by the mentee into detailed and digestable issues
[ ] (from last week) Lise to work with Aaron to update video in mkdocs documentation
[ ] (from last week) Lise and Paula to meet re: Theme Builder at Grace Hopper Open Source Day
[ ] (from last week) Cody to look at pre-push hook
[ ] (from last week) Aaron to follow up with author of #1026

the 09/19 call was attended by:
Kathleen Burkhardt - Black Rock
Evan Kountouris - DFS
Aaron Reed - DFS
Omesh Kumawat

Approved in today's call


Tweak behaviors of build and release CI workflows

Hello! With this PR I've tweaked some settings that @xylar and I have determined work out better in CI workflows on other repos. I've made the same changes here. These changes include:

All references to mamba/mambaforge have been removed and/or changed to conda and Miniforge3
The timeout for the pre-commit job has been upped to 5 minutes

Updated template from @forsyth2:
Issue resolution

Equivalent to https://github.com/E3SM-Project/e3sm_diags/pull/847, https://github.com/E3SM-Project/zppy/pull/621

This pull request is a minor adjustment that does not affect functional code.
1. Does this do what we want it to do?
Objectives:

Run CI with Miniforge3 rather than mamabforge
Run CI with a longer timeout for pre-commit checks, to ensure enough running time for these checks to pass.
[Note: the cancel_others change present in the equivalent pull requests is not needed here, since here that parameter isn't in the file to begin with.]

Required:

[x] Product Management: I have confirmed with the stakeholders that the objectives above are correct and complete.
[ ] Testing: I have added at least one automated test. Every objective above is represented in at least one test.

The existing CI checks on GitHub check this.

[x] Testing: I have considered likely and/or severe edge cases and have included them in testing.

2. Are the implementation details accurate & efficient?
Required:

[x] Logic: I have visually inspected the entire pull request myself.

3. Is this well documented?
Required:

[ ] Documentation: by looking at the docs, a new user could easily understand the functionality introduced by this pull request.
This change does not require new documentation.

4. Is this code clean?
Required:

[x] Readability: The code is as simple as possible and well-commented, such that a new team member could understand what's happening.
[x] Pre-commit checks: All the pre-commits checks have passed.

I have inspected the code visually. I will merge this change. Thanks @altheaden.

Thanks @forsyth2!


how many pages counter

similar to this: http://wordstopages.com/
Also possibly a place where they can put in writing and it will tell them how many pages

Got a contractor working on this one


Color picker for colors with enumerated values

{
  "type": "string",
  "format": "color",
  "enum": ["#0000ff","#ff0000","#00ff00"]
}

This should render as a radio group with the colors shown in small squares.

It would be nice to integrate spectrum.js and this feature is what you want http://bgrins.github.io/spectrum/#options-showPalette

Incidentally I've used Spectrum with json-editor myself and demonstrated it here:
https://github.com/TrevorPage/jdorn-json-editor-android
This demonstration is for Android and in my situation I absolutely had to use Spectrum because the Android browser's native colour picker doesn't seem to work.
I'm afraid I've not done any integration with the json-editor library as such. I'm just using jQuery to substitute in Spectrum in place of selected text fields, after json-editor has rendered its HTML.

I create a spectrum-editor ^_^:
https://github.com/hellobugme/json-editor.zh-CN/tree/master/plugin/spectrum-editor


Test against Spark 1.6.0

#44
Since Spark 1.6.0 is released and this still stays as a third-party library, I think it would be better to test against Spark 1.6.0.
Fortunately, this looks testing fine with this version.

Current coverage is 85.37%

Merging #45 into master will not affect coverage as of 177a4d2

@@            master     #45   diff @@
======================================
  Files           12      12
  Stmts          506     506
  Branches        97      97
  Methods          0       0
======================================
  Hit            432     432
  Partial          0       0
  Missed          74      74

Review entire Coverage Diff as of 177a4d2

Powered by Codecov. Updated on successful CI builds.

I am going to merge this.


Fix bug 207

Rescinding this because of too many merge conflicts. Created a new branch off develop and added my fixes on top of that. Closing this.


Store wallet and user credentials on localStorage

I thought it would be enough to rely on browser history to access my LNbits wallets, but after creating a hundred wallets and deleting the database some times and creating wallets again I'm pretty sure I will never find the wallet I want ever again.
Since we already leak previously used wallets into the browser history, what if we also stored them on localStorage and presented the user with a list of previously used wallets at the homepage of LNbits?
If someone wants a temporary instawallet they really need to use private-browsing mode or something.
Or maybe this feature could be turned off by the server owner.

This would give access to wallets created at the browser by the user who created them only?  That may be implicit, but just wanted to be sure.
That being the case, and with my own management issues (greatly helped by the appearance of the Wallet name in the ) has improved ease of management a great deal.  I wonder then if adding the Wallet name to the URL might be another affordance worth considering.
TL;DR Ack lamation.

It would give access to the wallets to anyone using that same browser.

So that's the same risk as auto-login on a shared browser, which may be reasonably well understood.  Unless you're on a public or kiosk browser, not something that's common or impossible to avoid.  Is the localStorage protected by profile login, as in Firefox and others?
As you note there's private mode too.

It would not be adding any additional risk really.  In some ways making it more transparent that the risk already exists.
As fiatjaf mentioned, you can already access browser history to get into old wallets.  Users might not be aware of that.
Making it show the previously accessed wallets on the front page makes it more obvious.

Can this be closed? @fiatjaf ?