@crumble and @Paul Thornton
Switching on 'show hidden devices' in the Device manager (Windows 7) did not reveal anything new. Only COM1, Dell COM3 and Dell COM5 showed up (see screenprint in earlier post).
What finally worked to solve my problem is to install the driver file pycom.inf downloaded from https://github.com/pycom/pycom-micropython-sigfox/blob/master/docs/pycom_esp32/tutorial/includes/downloads/pycom.inf from within the device manager (Action >> Add Legacy Hardware >> Search for and install the hardware automatically >> Ports (COM & LPT) >> Have disk >> Browse to pycom.inf file). I installed the 'Expansion 3' option. That installed the expansion board 3 driver, but it showed an error in the device manager (device cannot start). But when I next connected an expansion board V3.1 (with lopy4) to the laptop with usb, a new COM port ('Expansion 3 COM 19') appeared in the device manager, and this one allows me to connect from Atom. Also an Expansion board V2.1A with a lopy can now be connected.
So problem solved. Although I still do not know what caused the connection problem. Auto connect does still not work because the working driver is at the bottom of the serial devices list, and the auto-connect takes the first one in the list, that one does not work. But anyway, PROBLEM SOLVED, I can connect manually by selecting the right COM port. Thanks for all the help!
Thanx, clear to me now.
And there are different micropythons ( board specific ), most differences hardware related.
When you use libraries, you don't have to upload them immediately to the board, using the 'run' button.
By "See the pycom docs" you mean docs.pycom.io I suppose.
The problem I have ( and I also had with finding hardware info ), when starting with Google to find a topic, I am sometimes directed to other older documentation ( also by pycom ). So I sometimes get lost between the versions.
Most will run over http/https. but the payload format can change. from things like XML for soap. to Json/Xml for Rest some more modern ones may even be using protocol buffers or similar to encode payloads.
Was there a specific webservice did you have in mind?
@martinnn Found the issue with your firmware updater. If you would want to update to a dev version, you need to download the development version of the firmware updater (here). They will release it as stable soon, but not until then, use this dev version.
@nervencid With autoconnect to false, it indeed tries to connect to the address 192.168.4.1, so the output you posted is as expected. To connect you can either:
connect to the devices wifi and klik connect again, or:
change the auto_connect setting to true, or:
set the address setting to the correct comport (you can find it using the 'list serialports' command)
@John-Baird@Martinnn the feature that might help you both is 'autoconnect'. If enabled (in global settings), Pymakr connects to any board you plug in to the usb within 2 seconds. If you plugin multiple boards, it connects to the first one in the ports list.
The feature @John-Baird is suggesting is also a good thing we could implement, to have a list with addresses to connect to. Autoconnect doesn't work ideal if you have multiple boards connected over USB, or if you connect over wifi and have a list of IP's from your devices. It's definitely on the tasklist to look at.
when you click run just the single file your editing it sent to the board its literally as if you typed each line into the Repl. this is fine if its just your main.py script. but when libs need updating they dont get sent as you have discovered.
The reason for the reset being required is to force micropython to reload its previously loaded and cached copies of libraries There are work arounds for hot reloading code, but its way easier to just reset the board during development