Evok Does Not Recon Any Devices
knebb last edited by
As statet: Only way seems to be to use the image and NEVER, EVER do updates....
It's a problem caused by the new version of Tornado and the kernel, unfortunately it's not easy to solve, ultimately with the packaging we do an equivalent to the commands above.
I can't give a firm date when the package system will be ready. We already have it running internally, but we need to upgrade all of our images to use it first.
dgajic last edited by
I don't mind using your image, but looking at dates it seems latest one is from March, I assume corresponding version of Evok API on it is also from March? I don't know how to check version of API on the image itself.
Would be an option to build new image after each release of Evok API?
It's not really simple unfortunately, the images are built via booting from ethernet and copying over to an empty card, to ensure that they are as clean as possible, and the process takes a while.
I'll see if we can't come up with a better way of managing EVOK versioning.
I don't really care which version of Raspbian I have, I just wanted to get the latest EVOK sw for any bugfixes before sending them out to clients. Should I use an image of Raspbian before Stretch? I'm using Stretch Lite atm
Please start a new topic or reply in the other one, thanks
It shouldn't matter which version of Raspbian you use.
@TomasKnot can you point me to the other topic. If you mean my other question about the extension, that is a different case.
I have the same issue @dgajic was point out, clean install of Stretch lite doesn't seem to work.
I believe that @dgajic was asking about updating UniPian as opposed to Raspbian in this topic.
Anyhow - here's an answer to you. All of EVOK installations done since yesterday are broken as of right now, as a recent update of the pymodbus https://pypi.org/project/pymodbus/1.5.2/#history (~3 days ago) library broke the installation. UniPian does not have this issue.
It does not matter which version of EVOK or Raspbian you use, this is an issue with the library breaking the compatibility. We will get it fixed within today, but you will have to perform a new install afterwards.
I have only found this out now, through the issues you are having, and so thank you for the bug report.
We will have a look at figuring out a way to package the libraries with EVOK, but it's not a simple process since python libraries are distributed as source code under various licenses.
@TomasKnot that is awesome news! Thanks !
I think it is just bad luck that I started to update the software at the time this bug arised :)
Will be patient ...
@TomasKnot because you said it was an issue with PyModbus, I removed it from the system and installed 1.5.0 => still same issue. Then I just went back a lot more and installed 1.3.2 (via sudo pip install pymodbus==1.3.2 )
Now it seems to work (haven't tested thoroughly, but the test webpage loads and I can toggle the switches succesfully!)
That's exactly what I did in the recent commit on Github. Glad to hear it works now. I believe the version 1.4.0 should work as well. I am slightly surprised it took so long before this came up, since it seems even 1.5.0 is broken.
I am testing it now and will have a new release out soon. But it does seem like the issue. UniPian has EVOK and all the libraries pre-installed, which is why it does not have the problem.
I have now released version 2.0.5c (hotfix) which should have the pymodbus library version forced to 1.4. The changes are big enough that it would not be trivial to port EVOK to the newer version, though we'll have a look at it in the future.
Boy Lenssen last edited by Boy Lenssen
@TomasKnot Great work! I'll update my production version SD-card soon to test it
edit: updated the card (originally running EVOK from around may 2017 (I think it was alpha) and the 2.0.5c installation gave no issues
dgajic last edited by
I can confirm 2.0.5e works on latest raspbian stretch lite (2018-04-18), clean install.
knebb last edited by
Does it still work after you did an "apt upgrade"?
Or will it break whenever a new kernel will be released?
We use a modified kernel. You can use the commands
apt-mark hold raspberrypi-bootloader apt-mark hold python-tornado apt-mark hold raspberrypi-kernel
to prevent it being broken (also true for the Tornado webserver).
As a side note you should generally not do apt-get upgrade regularly on a non-desktop Linux system. 90%+ servers in the world do not do so to avoid precisely such issues. The same goes with any custom software. It's really only "safe" to do on a desktop with only standard packages, and even then it can sometimes break things. This is in fact the reason why Linux keeps older versions of packages in the repositories in the first place.
We plan to release packages, but all the above will still apply, functionally the differences will be
a) possibility to update UniPi software via apt
b) not needing to use the above commands manually (they will be instead done by the packages during installation)
You are of course welcome to compile the kernel yourself against any version which you wish, it's openly available in our repository.