It looks like the version number is derived from the most recent git tag. That is current "v1.0". I'll have to check with Parallax to see how they want to change that for this new version. Maybe it should at least go to "v1.1 beta" or something like that.
I don't know why older versions won't build. Doesn't git restore old submodules when it checks out an older version of a repository? I'm not a git expert so I'm not sure how this is normally done.
I don't know why older versions won't build. Doesn't git restore old submodules when it checks out an older version of a repository? I'm not a git expert so I'm not sure how this is normally done.
I found that this is the process to go to a previous commit.
Do a git reset --hard <hash-or-ref>' and then git submodule init and git submodule update, then compile.
Just don't use that on anything you plant to commit.
I don't login to my git account when doing this kind of stuff. No way to mess the repo then.
It looks like the version number is derived from the most recent git tag. That is current "v1.0". I'll have to check with Parallax to see how they want to change that for this new version. Maybe it should at least go to "v1.1 beta" or something like that.
Cool. (I THINK I did find that the versioning is in the main folder Makefile.)
I dunno I have to try it.
I can at least change it for myself so I am not confused what version im running, since I am compiling a few different commits on the same day, for all this testing.
# 1. Tag the master with: git tag -a v1.1 then enter an annotation message (it's like a commit message)
# 2. The above snippet used v1.1 as example..... change that v number to whatever you need!
# 3. Then try: git describe to see what version is displayed
# 4. Then run make in usual way
VERSION=$(GIT_VERSION) ($(shell date "+%Y-%m-%d %H:%M:%S")$(GIT_COMMIT_HASH_SUFFIX))
#VERSION=1.1 ($(shell date "+%Y-%m-%d %H:%M:%S")$(GIT_COMMIT_HASH_SUFFIX))
I don't know why older versions won't build. Doesn't git restore old submodules when it checks out an older version of a repository? I'm not a git expert so I'm not sure how this is normally done.
I found that this is the process to go to a previous commit.
Do a git reset --hard <hash-or-ref>' and then git submodule init and git submodule update, then compile.
Just don't use that on anything you plant to commit.
I don't login to my git account when doing this kind of stuff. No way to mess the repo then.
Using 'checkout' didn't work for me.
Won't checkout work if you do it on a new repository clone?
It looks like the version number is derived from the most recent git tag. That is current "v1.0". I'll have to check with Parallax to see how they want to change that for this new version. Maybe it should at least go to "v1.1 beta" or something like that.
Cool. (I THINK I did find that the versioning is in the main folder Makefile.)
I dunno I have to try it.
I can at least change it for myself so I am not confused what version im running, since I am compiling a few different commits on the same day, for all this testing.
# 1. Tag the master with: git tag -a v1.1 then enter an annotation message (it's like a commit message)
# 2. The above snippet used v1.1 as example..... change that v number to whatever you need!
# 3. Then try: git describe to see what version is displayed
# 4. Then run make in usual way
VERSION=$(GIT_VERSION) ($(shell date "+%Y-%m-%d %H:%M:%S")$(GIT_COMMIT_HASH_SUFFIX))
#VERSION=1.1 ($(shell date "+%Y-%m-%d %H:%M:%S")$(GIT_COMMIT_HASH_SUFFIX))
Yes, that will work. Just don't submit a pull request with that change!
The version number comes from a git tag built into the make process.
Do: 'git tag -l' to see the tag v1.0
use: 'git tag -a v1.1' to create a annotated tag object
use 'git tag -v v1.0' to see the tag text
Mike
That is correct. I think I mentioned that above as well. I got email from Parallax saying they prefer that we go to "v2.0" since this version requires a different SDK and boot loader which are fairly big changes. I will probably tag the repository at "v2.0b1" since we're still working through the bugs introduced recently. We can go to "b2", "b3", etc and then move to just "v2.0" when we're ready to release an official version.
I got email from Parallax saying they prefer that we go to "v2.0" since this version requires a different SDK and boot loader which are fairly big changes. I will probably tag the repository at "v2.0b1" since we're still working through the bugs introduced recently. We can go to "b2", "b3", etc and then move to just "v2.0" when we're ready to release an official version.
Deluxe!
Its too bad that parallax only has the 2016 firmware on their support pages for this module, which doesn't have many of the enhanced features and bug fixes between 2016 and 2020, like updating the DNS with the HOSTNAME of the module, support for the BADGE, and the ability to choose the PIN NUMBER of the RESET LINE, and also the ability to enable/disable the DEBUG PIN, plus many more things, LOADER BAUD RATE...etc...
Would it be safe to say that the POST 2016 (everything from 2016 to 2020) firmware could be v1.5? I know its not official, but here's the problem. To provide the new v2.0b1 firmware for testing, the pre v2.0b1 firmware needs to be provided also so users can revert, but reverting to the 2016 release eliminates lots of functionality and bug fixes.
I would like to give users the instructions to compile all 3 "milestones" so they can test with any that they choose, but calling everything up to v2.0b1, v1.0 confuses many due to the version on the parallax support site (2016) is already v1.0 and has limited functionality. So it only seems logical to call everything in between v1.5.(unofficial)
Would you have a problem with that if I labeled it as such in my instructions? I would state that its not official and NOT in the repository, that this version is my own label.
Won't checkout work if you do it on a new repository clone?
Perhaps I did something wrong when I just did 'checkout' the build went ok, but after doing a full flash, the module failed to operate properly at all.
Yes, that will work. Just don't submit a pull request with that change!
No, never, when I work with a repository, I never login to github (thus cannot make changes) and I usually finish what I am doing, and then DELETE the entire copy I have, and re-get a new copy, when there are updates or if I want to work with it again. I have run into too many problems working with the same copy all the time.
I just created a new tag "v1.2" that should be right before the merge of @iseries pull request. This should have all of the changes prior to moving to the new SDK and boot loader. Please try it and let me know if it works for you. I didn't call it "v1.1" because I think @"Clock Loop" has used that version locally.
I just created a new tag "v1.2" that should be right before the merge of @iseries pull request. This should have all of the changes prior to moving to the new SDK and boot loader. Please try it and let me know if it works for you. I didn't call it "v1.1" because I think @"Clock Loop" has used that version locally.
Ok, GOOD, v1.2 it is! Glad that is sorted.
I didn't use that locally, even if I did, don't change official stuff because of my local junk, I can adjust to the cloud's official repository and its changes! (thanks for considering me tho)
I just created a new tag "v1.2" that should be right before the merge of @iseries pull request. This should have all of the changes prior to moving to the new SDK and boot loader. Please try it and let me know if it works for you. I didn't call it "v1.1" because I think @"Clock Loop" has used that version locally.
Ok, GOOD, v1.2 it is! Glad that is sorted.
I didn't use that locally, even if I did, don't change official stuff because of my local junk, I can adjust to the cloud's official repository and its changes! (thanks for considering me tho)
Well, you mentioned you might use v1.1 and it didn't hurt to go directly to v1.2. If you have time, please try it for me. This is the first time I've tried tagging a point in the past so I'd like to know whether it worked.
I think I will hold off on the v2.0b1 tag until we fix the current problems. Actually, I need to go back through this thread to see if I can make a list of the issues that haven't yet been resolved. We probably shouldn't tag a version that has known issues.
I think I will hold off on the v2.0b1 tag until we fix the current problems. Actually, I need to go back through this thread to see if I can make a list of the issues that haven't yet been resolved. We probably shouldn't tag a version that has known issues.
oh, i thought thats what the b1 is for? Most alphas ive used had obvious flaws, betas were closer to perfection... then when parallax likes the fixes, you change to just 2.0?
So technically would this be an alpha?
I don't know what they do in naming versions that are based off of working code but have major changes to its core like using a different sdk, etc.
Actually you might want to tag everything past 1.2 to something, because if you look at the most recent commit, it has the 1.2 tag.
So I guess the tags carry forward from the point at when you tagged it, not just that single commit.
This means when I download the latest commit (which is with the new sdk and one that needs testing, the home page on the module will still show 1.2.
(i have 3 esp's on my breadboard, one is v1.0, one is v1.2, and the third is... 2.0b1 (or whatever this one is called)
In the process of doing testing to see if one version has a bug versus the other, going to the home page of the esp will help the tester know they are not mixing up their versions and esp's.
It just means when I test a new commit, I will need to change the tag for my local copy before compile, or it will show the same version of my v1.2 test esp.
I guess there are ... UNEXPECTED CONSEQUENCES TO CHANGING THE TAG to anything above 1 ..
You will need to update proploader if you do go above 1 ..
(it works with 1.2)
ERROR: Unrecognized wi-fi module firmware
Version is v2.0b1 (2020-09-08 17:09:38 0-gae3b50e) but expected v1..
Recommended action: update firmware and/or PropLoader to latest version(s).
I will need to keep the latest test version under 2.
Ah, good thing you noticed that before I added a tag. Now I'm remembering that we decided that the major version number would only change when the protocol with the loader changed. We'll have to call the new version 1.5 or something like that.
Also, as far as everything being "v1.2" from now on, you'll n notice that anything other than the real "v1.2" has a hash value appended to it that indicates which commit it was derived from. That lets you distinguish a real numbered release and an alpha of the next release.
Also, as far as everything being "v1.2" from now on, you'll n notice that anything other than the real "v1.2" has a hash value appended to it that indicates which commit it was derived from. That lets you distinguish a real numbered release and an alpha of the next release.
Which commit is the real v1.2? (will the real commitSHADY please stand up?) Yea, i'll be here all week.
Also, as far as everything being "v1.2" from now on, you'll n notice that anything other than the real "v1.2" has a hash value appended to it that indicates which commit it was derived from. That lets you distinguish a real numbered release and an alpha of the next release.
Which commit is the real v1.2? (will the real commitSHADY please stand up?) Yea, i'll be here all week.
I'm not sure why you got a blank version number. I tried making a new repository clone and then checking out v1.2. When I built it I got this version string:
VERSION v1.2 (2020-09-09 21:13:16 15-gae3b50e)
However, I notice that this version string *does* have a hash tag after the date even though I said it wouldn't. I didn't load the resulting firmware into a module and look at the configuration page though. I suppose there could be something wrong with the HTML that displays the version string.
I'm not sure why you got a blank version number. I tried making a new repository clone and then checking out v1.2. When I built it I got this version string:
If you run this command, and compile it, you will probably get no version, and no hash like I did.
That is all I did differently.. (prior to that I used "checkout" and also "reset hard" and both those had a hash, and the version number)
I don't know if using branch is bad.. I just searched for a way to checkout a specific tag.
My bugs and errors are wierd, sometimes they happen sometimes they don't.
The wifi page doesn't restart the module, now that the UDP fix was merged... im only guessing that is why its not fully restarting the module.
Now it just does this the first time its accessed after power on.
The E:M messages.
I will test the code prior to the UDP fix to see if it still causes a full reboot.
985063> URL = /wifi/wifi.html
985064> Heatshrink compressed file; decode parms = b4
985325> Conn req from 192.168.4.2:62060, using pool slot 1
985325> Conn req from 192.168.4.2:62061, using pool slot 2
985342> URL = /wifi/style.css
985343> Heatshrink compressed file; decode parms = b4
985344> URL = /wifi/140medley.min.js
985345> Heatshrink compressed file; decode parms = b4
985349> E:M 2096
985350> E:M 1584
985352> E:M 1584
985353> E:M 1584
985355> E:M 1584
985356> E:M 1584
985358> E:M 1584
985359> E:M 1584
985361> E:M 1584
985363> Httpd: queuing 142 byte buffer
985739> Pool slot 1 is done. Closing.
985740> Pool slot 1: socket closed.
986688> Pool slot 0 is done. Closing.
986689> Pool slot 0: socket closed.
@"David Betz" Sorry to bug you again!
Did I find an undocumented "Reply?" from the WX module?
252007> [1252007] Reply: '=T,5,0'
What is a T reply? I cannot find it in the WX module API, and I do not know where to look in the c-code to figure out what it means
(even if i could find it, not sure if i'd understand the c-code)
Comments
I don't know why older versions won't build. Doesn't git restore old submodules when it checks out an older version of a repository? I'm not a git expert so I'm not sure how this is normally done.
I found that this is the process to go to a previous commit.
Do a git reset --hard <hash-or-ref>' and then git submodule init and git submodule update, then compile.
Just don't use that on anything you plant to commit.
I don't login to my git account when doing this kind of stuff. No way to mess the repo then.
Using 'checkout' didn't work for me.
Cool. (I THINK I did find that the versioning is in the main folder Makefile.)
I dunno I have to try it.
I can at least change it for myself so I am not confused what version im running, since I am compiling a few different commits on the same day, for all this testing.
Do: 'git tag -l' to see the tag v1.0
use: 'git tag -a v1.1' to create a annotated tag object
use 'git tag -v v1.0' to see the tag text
Mike
Deluxe!
Its too bad that parallax only has the 2016 firmware on their support pages for this module, which doesn't have many of the enhanced features and bug fixes between 2016 and 2020, like updating the DNS with the HOSTNAME of the module, support for the BADGE, and the ability to choose the PIN NUMBER of the RESET LINE, and also the ability to enable/disable the DEBUG PIN, plus many more things, LOADER BAUD RATE...etc...
Would it be safe to say that the POST 2016 (everything from 2016 to 2020) firmware could be v1.5? I know its not official, but here's the problem. To provide the new v2.0b1 firmware for testing, the pre v2.0b1 firmware needs to be provided also so users can revert, but reverting to the 2016 release eliminates lots of functionality and bug fixes.
I would like to give users the instructions to compile all 3 "milestones" so they can test with any that they choose, but calling everything up to v2.0b1, v1.0 confuses many due to the version on the parallax support site (2016) is already v1.0 and has limited functionality. So it only seems logical to call everything in between v1.5.(unofficial)
Would you have a problem with that if I labeled it as such in my instructions? I would state that its not official and NOT in the repository, that this version is my own label.
Perhaps I did something wrong when I just did 'checkout' the build went ok, but after doing a full flash, the module failed to operate properly at all.
No, never, when I work with a repository, I never login to github (thus cannot make changes) and I usually finish what I am doing, and then DELETE the entire copy I have, and re-get a new copy, when there are updates or if I want to work with it again. I have run into too many problems working with the same copy all the time.
Ok, GOOD, v1.2 it is! Glad that is sorted.
I didn't use that locally, even if I did, don't change official stuff because of my local junk, I can adjust to the cloud's official repository and its changes! (thanks for considering me tho)
I guess you can tag everything past that tag, to 2.0b1?
oh, i thought thats what the b1 is for? Most alphas ive used had obvious flaws, betas were closer to perfection... then when parallax likes the fixes, you change to just 2.0?
So technically would this be an alpha?
I don't know what they do in naming versions that are based off of working code but have major changes to its core like using a different sdk, etc.
https://en.wikipedia.org/wiki/Software_release_life_cycle
So I guess the tags carry forward from the point at when you tagged it, not just that single commit.
This means when I download the latest commit (which is with the new sdk and one that needs testing, the home page on the module will still show 1.2.
(i have 3 esp's on my breadboard, one is v1.0, one is v1.2, and the third is... 2.0b1 (or whatever this one is called)
In the process of doing testing to see if one version has a bug versus the other, going to the home page of the esp will help the tester know they are not mixing up their versions and esp's.
It just means when I test a new commit, I will need to change the tag for my local copy before compile, or it will show the same version of my v1.2 test esp.
I don't mind, what ever works for you!
You will need to update proploader if you do go above 1 ..
(it works with 1.2)
ERROR: Unrecognized wi-fi module firmware Version is v2.0b1 (2020-09-08 17:09:38 0-gae3b50e) but expected v1.. Recommended action: update firmware and/or PropLoader to latest version(s).I will need to keep the latest test version under 2.
Also, as far as everything being "v1.2" from now on, you'll n notice that anything other than the real "v1.2" has a hash value appended to it that indicates which commit it was derived from. That lets you distinguish a real numbered release and an alpha of the next release.
Which commit is the real v1.2? (will the real commitSHADY please stand up?) Yea, i'll be here all week.
It must be https://github.com/parallaxinc/Parallax-ESP/commit/a5bcb63560c3be18806231ba25700cf70a0f6f3a
But when i reset hard to that commit, it must do something. I will try to checkout again.
I think it makes a hash with reset hard.
I see what you are saying with v1.0 release from parallax's support page for the WX, no hash.
Do you mean I cannot compile "the real v1.2" ? (I will always have a hash?)
Im missing a tag?
Any idea why the version is missing? (at least I was able to get the version with no hash)
This git learning curve is nuts.
Nope, that did not work.
Is it perhaps because the tag was added much later than the commit, so I must add the tag myself?
notgonnawerklol
hmmm.
I see why you don't want to make a tag for the testing beta, it will make a release under releases? (yeah not good)
If you run this command, and compile it, you will probably get no version, and no hash like I did.
That is all I did differently.. (prior to that I used "checkout" and also "reset hard" and both those had a hash, and the version number)
I don't know if using branch is bad.. I just searched for a way to checkout a specific tag.
I tried running just the dynamic content to see if it was one of those elements and they all worked just fine.
It seems to be something in the web page itself.
Mike
The wifi page doesn't restart the module, now that the UDP fix was merged... im only guessing that is why its not fully restarting the module.
Now it just does this the first time its accessed after power on.
The E:M messages.
I will test the code prior to the UDP fix to see if it still causes a full reboot.
Did I find an undocumented "Reply?" from the WX module?
What is a T reply? I cannot find it in the WX module API, and I do not know where to look in the c-code to figure out what it means
(even if i could find it, not sure if i'd understand the c-code)
I am trying out the WX examples in the SIMPLE TOOLS LEARN folder.
Learn\Examples\Network\WiFi\Prop to Prop via WX (Client).side
Learn\Examples\Network\WiFi\Prop to Prop via WX (Host).side
https://github.com/parallaxinc/Simple-Libraries/releases
I did have to modify the examples to get them to run, for some reason simpleide isn't finding the functions.
https://forums.parallax.com/discussion/comment/1507476/#Comment_1507476
I am getting this output from the debug port on the wx module.
T - connect event
X - disconnect event
D - send data event
Mike