Jump to content

wimvb

Members
  • Posts

    8,947
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by wimvb

  1. Välkommen till SGL. Generally, you will get better answers to any questions you may have, but I also can’t help you with your question. A great welcome to you! (But are you sure you’re on the right forum? 😉)
  2. If I strip the text from the published message, I get a graph
  3. The general idea is that if you have a client that posts messages to a topic, you will see more than just the broker IP address and $SYS
  4. This is how mine looks now Topic is 'hall' Message is 'Magnetic field strength: xx.xxx' Plus a code snippet (python): while True: try: client.check_msg() if (time.time() - last_message) > message_interval: msg = b'Magnetic field strength: {0:.3f}'.format(esp32.hall_sensor()) client.publish(topic_pub, msg) # print('message' + msg + 'published to topic' + topic_pub) last_message = time.time() counter += 1 except OSError as e: restart_and_reconnect()
  5. If you mean mqtt-broker, I only installed it on a windows laptop and put an icon on the desktop. Don't know how that works with Linux Mint.
  6. I believe you can use mqtt-explorer on another machine, if you point it to your broker. As far as I remember, mqtt-explorer lets you see all topics and subscribe to them. This allows you monitor the broker. Then clients can subscribe to the topics they need, and post messages in those topics. Mqtt-explorer is good to have while you experiment. As a further test, set up an esp32 to post internal hall sensor values to a topic. It only requires an esp, without additional hardware.
  7. Absolutely so. Systems that catch on generally evolve into well supported, stable systems. But this takes time. When I started with INDI, a new version could break things that worked before. Then, when Jasem Mutlaq decided to divide versions into stable and nightly builds, this was a leap forward in general stability. something similar happened with the Rock64 sbc. My point is rather that tutorials show proof of concept, and that more investigation is generally required in order to get to a stable system/setup. This is not unique for the maker community. But the abundance of tutorials and examples makes it very obvious here. Oh, @Gina, this is absolutely no criticism to what you post here. I enjoy your threads, and have learned much that has helped me in my diy projects.
  8. Finally success!! So far, I couldn't get my anemometer to talk to the ESP32. It worked fine when connected to my laptop through an RS485 - USB dongle, but wouldn't work at all with RS485 - TTL adaptors, not even with a bare chip MAX485. The only difference was that the TTL adaptor needed a write enable signal. There are several ways to generate such a signal, but none would work with my anemometer. Finally I found a new RS485 - TTL chip that doesn't need this write enable signal. I bought this https://www.amazon.co.uk/gp/product/B07B667STP/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1 Hooked it up and now it just works with simple microPython code: main.py The next step will be to combine the anemometer code with the code for the other sensors. Then, when I have my gear out of summer storage, I will hook it up to INDI Weather Watcher.
  9. The general problem in the maker society is that many tutorials and code are proof of concept, but still far away from stable ”production” versions. Software solutions may work in a specific configuration, but not generally.
  10. It may run, but I wonder how stable it will be. Running an esp32 as web server may cause memory leakage. Memory management seems a must.
  11. I did a test with mqtt, where I used my ESP32 sky quality meter and published that to a Raspberry Pi MQTT broker. These micropython files did the trick. Since the sensors all use i2c, changing the code so that it will work with a weather station shouldn't be too difficult. The randsomnerdstutorials site should provide the necessary information for changing the code to arduino ide/c++. You should also find information there on how to set up mqtt on the RPi. I used MQTT Explorer on my windows laptop to monitor the messaging to and from the RPi. boot_git.py main.py tsl2591.py umqttsimple.py
  12. I’ll do some digging in my code repository tonight.
  13. Clients do the job. In INDI language, clients are as indi-drivers/hardware devices and indi-clients, whereas the broker is like the indi-server. The broker handles communication and message (data) storage. Clients supply the messages (data) and receive the data. Clients then take the appropriate actions. That’s why esp32 (and arduino?) can be clients and a raspberry pi can be broker.
  14. My experience is that even with guide exposures of 3-4 seconds, rms varies with seeing. I hope that with multi-star guiding, there will be somewhat less variation. Every 0.1” counts.
  15. With 1.5"/p, your guiding rms should "in theory" be 0.75" or better. But as sky conditions (seeing) usually limit the resolution that we can achieve, I think you're safe if you can keep the rms around 1".
  16. As in your weather station thread, I believe that mqtt can handle this. A weather station and the roof controller are clients. A raspberry pi is the server (broker in mqtt language), which sends data received from one client (the weather station) to another (roof controller), or even several others (+ a display unit?). Definitely worth looking into, imo.
  17. In all fairness, if you want to go this route with two way tcp/ip communication, you might want to look into MQTT as an alternative, unless you already have php and mysql running. @jiberjaber and @tekkydave suggested this a while ago. As I mentioned before, I played some with MQTT, and found it quite straightforward to set up.
  18. With a budget of about £200, and your current setup, I would start looking at processing software. Test the ones available, PS, PI, APP, startools, then go for the one that suits you and your hardware best. I found PS subscription model to become too expensive in the long run. PI offered all I needed; startools and app were not an option at that time, but are so nowadays.
  19. So, in your colour coded image, in stead of having 4 sensor in a row, inside to outside, you have those rotated 90 degrees. This means that the coresponding colour sections have to be rotated with them, to preserve the coding. Then, as you say, red and black will coincide, green needs to be rotated 180 degrees, which leaves it the same. Blue needs to be rotated 270 degrees, which also leaves it the same. Am I correct in this?
  20. SSE and N have the same code. As do SE and NNE. Again, there’s symmetry along the vertical line. This is your previous design, but inside out. You need to add a ridge going from the 12 o’clock position to the 6 o’clock one. In your latest design nearest the centre.
  21. This omission made the print design symmetrical along a vertical line in the images you posted. I saw that just now.
  22. In your print design, you forgot the red section ... of your earlier colour chart.
  23. You probably have a lot of moisture coming from the woods around the observatory. Ventilation won't help then. But you can always have the dewheaters at a low power so as not to get any fungus on your glass.
  24. That's a very nice setup you have. But looking at the condition of the wood, you seem to have problems with high humidity. Won't that affect your gear as well?
  25. 3D printed with aluminium tape on top? Could be used in transmission or reflection mode. I have no idea how age resistant aluminium tape is, though.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.