https://toitlang.org/ logo
Powered by
Problem dhtxx and new version v2.0.0-alpha.182
# help
f
Hi, I,ve just updated to the new version and I,m having the "EXCEPTION error. insufficient signals from DHT" since the update, and don,t find a way to downgrade to the functional version i had before that was the .175
f
Which platform are you on? If you install an older version you should be able to run again. Maybe you need to downgrade your packages again too, but that isn't hard either.
f
I use windows, but I dont find info on how to downgrade to .175 version
f
In the worst case just use the Windows installer
f
I tried winget but always get the latest version
f
Winget probably doesn't (easily) allow that.
But winget is just using the installer.
And good to know for the DHT exceptions.
I will investigate. We upgraded to the new esp-idf APIs. Everything should still work, but who knows... 🤷‍♂️
That said: have you tried updating the dhtxx package?
f
yes
f
too bad. I would have hoped that the new pkg with the new API would be stable.
I will try to find some time to investigate.
f
I'm using toit-dhtxx 1.8.0
f
Yes. That one should work with the new API. (It's literally the only commit for that release)
I guess it's not working as well as I hoped... 😦
k
😢 I agree - have the same problem with the new version. (update from v2.0.0-alpha.180 to v2.0.0-alpha.182 without application change)
f
Good to know. Thanks.
Is it sometimes working or never?
k
Now I don't get any dhtxx data.
f
interesting.
We have the dhtxx as part of our tests, and there it seems to work.
Could you download the dhtxx package and use a local version of it?
I would have a few lines that I could add to (maybe) help debugging it.
k
previously i had only problems with the first read.
f
That said: I'm currently debugging the ultrasound sensor. So maybe I will find something there.
I think I figured out why the first read wasn't working.
Let me try to fix the ultrasound sensor first. If I find a more general problem, it might fix the dhtxx.
if not, I will do a bit more experiments with my dhtxx sensors.
If I can't reproduce I will probably need your help, but let's start on my side.
k
ok - gerne.
👨🏻‍🏭 uninstalling and installing the dhtxx pkg removed the problem ! 🗣️ The sensors data are available again.
f
On the new version or the old one?
k
Jaguar version: Version: v1.52.0 SDK version: v2.0.0-alpha.182
f
nice.
f
this did not work in my case
f
I'm still debugging my ultrasound sensor. Currently stumped by the behavior. And will upgrade to a newer esp-idf version, to see if the device behaves the same there. Would be stupid to debug an esp-idf issue that has already been fixed. (Wouldn't be the first time...)
@Fernan so far I can't reproduce. Can you give me/us more information on your setup? Feel free to send me your code to florian@toit.io (I will delete it after debugging). I'm also interested in how things are connected.
f
This is a prototipe that takes a temperaure meassure with dht22 and sends to an end point, it was workin fine until the ugrade
****************************************************************************** Decoding by 
jag
, device has version ****************************************************************************** EXCEPTION error. insufficient signals from DHT 0: Driver.read-data-no-catch_ \driver_.toit:129:7 1: Driver.read-data_.... \driver_.toit:93:20 2: Driver.read-data_... \driver_.toit:91:32 3: Task_.with-deadline_. \core\task.toit:223:16 4: Task_.with-deadline_ \core\task.toit:217:3 5: with-timeout \core\utils.toit:189:24 6: with-timeout \core\utils.toit:181:10 7: Driver.read-data_.. \driver_.toit:91:9 8: catch. \core\exceptions.toit:124:10 9: catch \core\exceptions.toit:122:1 10: catch \core\exceptions.toit:73:10 11: Driver.read-data_. \driver_.toit:90:7 12: SmallInteger_.repeat \core\numbers.toit:1288:3 13: Driver.read-data_ \driver_.toit:89:14 14: Driver.read \driver_.toit:59:13 15: main. temp_ibi_t1.toit:23:20 16: Duration.of \core\time.toit:221:10 17: Duration.periodic \core\time.toit:276:19 18: main temp_ibi_t1.toit:20:20 ******************************************************************************
k
try to catch the first read error.
f
it caches the same error "insufficient signals from DHT"
k
🤔 strange
f
@Fernan do you feel comfortable changing the dhtxx package to add some debug lines?
f
go ahead please
how can I donload the jaguar v1.48.0 version for windows?
f
Use the installer, or the tar.gz.
The latest Jaguar release uses Toit 184.
k
I use in windows power shell: - winget install --id=Toit.Jaguar -e
- jag setup
- jag firmware update -d
f
but it takes me to the latest release I need to downgrade to v1.48.0
k
winget install --id=Toit.Jaguar -e -v 1.48.0
f
The releases page has all existing releases.
Even better. Nice.
f
I downgraded everything (a nightmare) but now is working as before
f
Eventually we should figure out why newer versions fail with your setup.
But good to hear that you are back up and running
f
it was a good experience, I've learned a lot, what i dont understand is the difference between Toit and Jaguar, they have to work together ? can i use just one of them?
f
Jaguar uses Toit underneath. For simplicity it just downloads a specific version.
The latest Jaguar now has a way to use the downloaded toit: 
jag toit ...
If you don't develop for the esp32, then Jaguar is not necessary and just installing Toit is enough.
f
but Toit is designed just to develop esp32 or what else can I do with it?
f
It's a general purpose language as well.
Artemis, for example, is entirely written in Toit.
And a big chunk of 
toit
itself is written in Toit.
You can either run programs with 
toit foo.toit
, or compile them to executables: 
toit -o foo.exe foo.toit
.
When developing for the desktop you often want to import 
host
, and/or 
cli
.
f
I've tryed to debug and reformulate with AI but I receive a lot of hallucinations and mixes with python
f
Yes. LLMs are still learning. My brother told me that the latest claude.ai is getting much better at Toit.
And the more code is out there, the better all of them will get.
f
Eventually we will get there
f
It would probably also be helpful to come up with a good "header prompt" that reminds the LLM of Toit properties. What are blocks, how does the syntax look, ...
f
could you with your experience provide some example promt?
maybe build an exclusive RAG with Toit data
f
I thought about it, but it's not yet high enough on my (way too long) TODO list.
f
is there a remote way to install a container when the esp32 is in sleep mode?
f
Not with Jaguar
With Artemis the service regularly checks for new firmware and eventually updates itself when it goes out of sleep.
f
so I have to program some kind of time window to install the new container when in deep sleep mode?
f
When the device is in deep sleep it is basically turned off. Something needs to tell the device that it needs to wake/boot up again. Jaguar doesn't do that at all. Artemis uses the max-offline to determine how long it can sleep (at most)
f
I remember when Toit started that early days that it had a web console that checked when esp32 woked up from sleep and it updated the new container
f
It also had a max-offline. Same as Artemis
With Artemis if you install a container it will get installed once the device goes online again
f
so I should change to Artemis to do that?
f
Jaguar is the convenient development environment. Artemis is more professional. With some cost for that. If you have devices "out there" that need updates, then Artemis is for you. If you have only a single device then it's not clear. Could go either way.
With "cost" I mean; "updating the device might require several commands" (but then you have a binary diff that can be applied to many devices...) And more setup.
@Fernan I just realized that you are using the DHT22. So far I only tested the DHT11 with the new API. Will try to find a DHT22 and test with that one later today (in the hope I will find some time).
k
f
Since it used to work, it's unlikely the issue.
And for the ESP32 I wouldn't use 5V.
But agreed: external pull-ups can sometimes be necessary.
It's a bit strange that the RMT doesn't have support for it.
(at least not easily)
k
I got a good advice from you to open/read/close for each measurement. That works fine if several DHT's are used.
f
I just found my dht22, and I can reproduce. Will debug it soon. The oscilloscope shows the response from the DHT, so not completely clear yet what's going wrong, but likely a slower response from the DHT
k
Using AM2320 and AM2302 (DHT22) on same ESP32-C3 without problems ! Even hot swapping of the devices works.
f
interesting.
hmm. Doesn't help that the DHT can enter a bad state. Didn't realize that... A lot of my testing was useless, as the sensor just went into a bad state...
k
did you apply a pullup ?
f
Didn't even need to.
I think the RMT does that automatically when in open-drain mode.
However, I think I found an issue: - when the RMT is started, it currently seems to pull down the output line. I think that's a bug in the ESP-IDF. Unfortunately, that looks to the DHT as if the device wants to read the data. If we don't wait a bit after creating the driver object, we are asking for a new conversation while the old transmission is still in progress. I was able to get my setup working by simply adding a 
sleep --ms=1000
after creating the driver object. @Fernan could you try to do the same and see if that works for you? Independently: In theory the driver needs to be powered up by at least 1s before we are allowed to interact with it. The driver assumes that the instantiation time is when the sensor is powered on, and is supposed to wait if the second wasn't elapsed yet. However, due to an inverted '<', that never triggered. I think I will remove that code, since the sensor is most of the time powered up independently of the esp32. I will add a warning somewhere, though.
k
example: only the 1st sample is missing.
Copy code
import dhtxx
import gpio

GPIO-PIN-NUM ::= 20

main:
  pin := gpio.Pin GPIO-PIN-NUM
  driver := dhtxx.Dht22 pin

  count := 0
  while true:
    ++count
    e := catch :
      print "$(count): "+ driver.read.stringify
    if e:
      print "$(count): "
    sleep --ms=250
f
OK
f
For me the DHT22 could get into a bad state, so maybe there are batches where reading in a loop won't recover. Either way: at the moment adding a sleep after instantiating the driver is a good idea. That should also make the first sample work again.
I filed an issue: https://github.com/espressif/esp-idf/issues/16068 For now the best way to avoid any issues is to sleep for 300ms.
fwiw, I ended up adding a pullup (using the 3.3V). Not completely sure if it was necessary, but my DHT22 didn't have a builtin. In theory it should be possible to use the ESP32's builtin pull-up, but there is currently no way to configure that (easily).
@Fernan I also looked again at your code. You already have a loop with a 500ms delay if it doesn't work. Unless the sensor enters a bad state that should be enough to recover. So you might also need the pull-up that @kaxori was mentioning. It could be that older versions automatically pulled the pin high, whereas the current ESP-IDF doesn't anymore. If your DHT22 has 4 pins, then it most likely doesn't have any pull-up.
k
In my plant germination monitoring, the pullups have proven to be advantageous for sensors with long leads.
f
my sensor has 3 pins and is working good on version alpha.175, I'll try again upgrading with your recomendation
f
Alpha 175 is using the old deprecated ESP-IDF API. It could be that the old ESP-IDF API automatically pulled the pin high, and the newer API doesn't. But let's hope that a simple 300ms sleep will be enough to fix things.
that said: I got the impression that wasn't active. Will investigate when upgrading to the newest ESP-IDF.
PreviousNext
Powered by