device_id and psk at 0x10000

Hi, I'm trying to compile from source add the 0x10000.bin created with mkid.py . Python script generate correct bin file, but when I flash with esptool I don't find my created ID and PSK. How can I recall this credentials? Andre

Comments

  • SergeySergey Dublin, Ireland

    Why don't you use mos tool for building and flashing?

  • Because we are developing a device with your fw and we need a simple and fast way to put our univocal id inside a lot of esp8266. We think that if we use a script that call mkid.py every time we flash a new device, we can leave our build from source intact, and add every time only the 0x10000.bin file. We are next for 5000pz, after a confirm of this , we will contact you for a commercial license. Now we are in development so we are trying various solution. I'm trying to call with Sys.conf , but also if build successful, I don't find the device_id.
  • I always use the mos tool, for debug, flash new compiled fw, upload file, ecc. I don't know how a big factory could flash a lot of esp, maybe esptool is not the better way, but if I could give them the zip with the bin file and also a possibility to put the univocal id in another bin file ready to flash, I think this should be a simple solution.
  • SergeySergey Dublin, Ireland
    edited January 30

    Thanks @wasabi !

    You're describing the exact use case we already handle with our configuration subsystem. Our customers asked for that - and we provided a so called "vendor layer". Please take a look at:

    https://mongoose-iot.com/docs/#/configuration/

    If you read it until the section that describes layers, you'll get the idea. Our customers use that to do one-time, after-factory device configuration, to set unique device parameters. They configure the ACL to make it impossible to change, unless a full reflash is done.

    Could you review the mechanism and see whether it suits you, please?

  • rojerrojer Dublin, Ireland
    edited January 30

    if need be, we could add this way of customizing devices, but it's kind of ad-hoc and requires reserving a sector on the device. mos put conf_vendor.json should not take much more time (basically, just waiting a couple seconds for device to boot up) and already works today.

  • I understand the vendor layer and I think it's a great way but for a limited number of device, in terms of time . there' s another way to pass this file? In your link say ' upload e.g. with POST' , but I have to connect the device and make an upload of the file, or give a command, or connect to AP and upload . each of these provides for the connection and then the upload , but before I have to flash. If I can pass this file during flash is not necessary to make a connection with the device and just now the upload. I'm looking for a solution for mass production, where should be a very high number of device with a univocal id and if I can make simply one flash , the device could be defined 'ready for first installation ' . In your file 'flashing.md' in the /fw/platforms/esp8266 , there is still the description for generate id with mkid.py at 0x10000.bin with the possibility to use it . Is still true? The Python script generate a 'key':'value' , ready to use. Only clubby can use it? I thought to find it with a Sys.conf command . Thanks for your answer.
  • rojerrojer Dublin, Ireland

    you can upload with post, but you don't have to. mos put --port=/dev/ttyUSB0 conf_vendor.json will do it. it will use the same serial connection that has just been used for flashing, so it will not need to wait for wifi or anything. it will only add a couple seconds to your programming time.

  • rojerrojer Dublin, Ireland
    edited January 31

    you can also slipstream the file into the filesystem image before programming using SPIFFS tools here: you'll need to unspiffs files into directory and then mkspiffs again. but really, in the scheme of things, flashing will take about 10 seconds anyway, so 2-3 for mos put will not make a difference.

    i just tested: with mos flash and mos put back to back, the latter takes 1.7-1.9 seconds to establish a connection and upload a small file.

  • OK, thank you.
    Soon We will talk with the pcb printer to understand how they can perform mass programming.
    I will try.

  • Hi , please, let me understand.

    When you say:

    it's kind of ad-hoc and requires reserving a sector on the device.

    I immagine that the mkid.py generate an id and psk but I can't use it.

    In older version was easy to use this id, but now I dont't find any reference.

    Why you write about this possibility and now is not possible? Older version have had the reserved sector?

    In that file ('flashing.md') there's a clear reference to esptool, bin file, MFT.

    Maybe you will change soon, but this programming mode is still valid.

    Another question please: the vendor file isn't present by default, I have to write it from zero, right?

    thank you.

  • SergeySergey Dublin, Ireland
    edited February 2

    Yes, vendor file should be written from scratch.
    Here's an example:

    https://github.com/cesanta/mongoose-os/tree/master/fw/examples/c_heater/fs

    Could you describe your product in detail, in order to get a clear idea about this ID/PSK use case you're talking about?

  • Hi, We have a high number of client that must have a default univocal id and they send at least one POST every 12 h to say 'I'm alive' . We have developed a system to register every single device for every user, naturally every user could have more device. Our system give user the possibility to select ,server side, where send data (given URL and port) and select wifi (his id and psw) without make configuration one by one in factory . So every user could configure his devices without physically connect every device. We need a simple and fast way to give a univocal id to every client but the problem is that this project is started with older version of your fw and now we are next to realize more than 2000 pz and we can't spend other time to pass all our work to your new version of fw. We have decided to solve this fw side, we are working on it. now we must work in this way, if the project goes ahead we could work on the next iteration of firmware( your new) and hardware ( some changing). Thanks
  • rojerrojer Dublin, Ireland
    edited February 2

    the fact that you're working with old code complicates the situation a bit, as there have been a lot of changes.
    nevertheless, if you tell us exactly at what point you made the copy, we should be able to better suggest the best approach. assuming you used Git to clone the repo, you just need to tell us the latest commit id (at the top of git log output).

Sign In or Register to comment.