[Sara Damiano]

I also responded on GitHub (https://github.com/EnviroDIY/SensorModbusMaster/issues/25), but the endian-ness of your sensor simulator is not compatible. You simulator seems to be sending CDAB mixed-endian.  SensorModbusMaster only supports ABCD or DCBA.

[Sara Damiano]

The WoFpy end-point should be usable.  Can you give an example URL that you’re trying?

Are you setting up a system to regularly poll Monitor My Watershed?  If this is something you plan do to automatically and frequently, please email help@monitormywatershed.org so we can talk directly with to make sure you’re using the most efficient endpoint possible.

[Sara Damiano]

Can you explain what issues you’re having?

Are you trying to use the library or to modify it?  The instructions you linked are for making changes to the library itself.

[Sara Damiano]

There’s an example of using an Arduino as an SDI-12 slave in the Arduino SDI-12 library.

[Sara Damiano]

The a-la-carte example isn’t usable as written any more. It got to be too big so I filled it up ugly pre-processor conditionals and snippet markers to use for continuous integration and documentation.

There are virtual functions all over the library, which definitely are eating up memory. I think almost the entire inheritance chain for sensors, modems, and variables could be re-written to use static, compile-time polymorphism (CRTP). But that’s a lot of refactoring.

[Sara Damiano]

If the communication works sporadically, it’s more likely to be an electrical issue than a code issue.  Coding issues *usually* cause it to not work at all.

The -9999 is the library’s value for a failed reading.  When you get in in SDI-12, it most often means the sensor didn’t respond or the response was garbled.  Because the Mayfly’s voltage (and thus serial communication) range is only 3.3V, it doesn’t take much electrical noise to garble things up.

[Sara Damiano]

The instructions for manual installation on the https://www.arduino.cc/en/Guide/Libraries are telling you how to find the right location to put the unzipped folder.  Once you have the right folder, you cut and past the files.  That’s it.

To update libraries, the easiest way is to delete everything in the library folder and re-download.

Can you clarify what you mean by “stuck” by posting screen shots of what you’ve done and the errors you’re getting?

[Sara Damiano]

Changing the address via the Yosemitech library is not hard.  I would strongly recommend you do that rather than mess with two adapters and two serial lines.  No matter what, I’m positive that the default addresses are not 0x04 or 0x0B as you have them coded.  Those are just my favorite addresses for them.

If you really want two separate connections, here’s NeoSWSerial and the neutered version of SoftwareSerial that you need to use to work with ModularSensors.  Also, read the docs!

[Sara Damiano]

There’s no enable pin broken out, so it must have automatic flow control.  That’s what you want.  This one, right:  https://www.amazon.com/ALMOCN-Adapter-Module-Converter-Indicator/dp/B09998FY4X?th=1

You said:

Currently the RS485 wires connected to the Y510-B into the mayfly are as follows: GND to GND, RXD to D11, TXD to D8, and VCC to sv5.

If the Vcc of the adapter is hooked to the 5V of the Mayfly; it’s powered at 5V and has 5V TTL and you’re risking frying you’re Mayfly’s processor.  Don’t do that.  Use 3.3V or 3.3V switched for the adapter.  Use >5V for the sensor.

On their website, Yosemitech still lists the DO sensor as 6-12V and turbidity at 5-12V.  So their range mostly overlaps.  In real life, I remember the DO sensor actually responding at only 5V.   Both would be very happy with either 6V or 12V supply.  If you’re going to try to power everything through boost converters off the Mayfly, you should start with the 3.3V instead of using the Mayfly to boost from 3.3V to 5V and then another stepper to move from 5V to 6 or 12V.

Here’s a really ugly drawing:

 

Attachments:

1. 

   Yosemitech-Connection.png
   

[Sara Damiano]

Sorry, I coded up the ThingSpeak publisher ages ago only to prove to myself that I could get an MQTT publisher working. I’ve never used it beyond that. I don’t have a paid account so after the trial period I was locked out and I’m not willing to do much testing on an account tied to my personal email.

Anyway, the code for ThingSpeak is in the ThingSpeak publisher in the publishers folder. It’s using PubSubClient under the hood. The outgoing message is formatted based on whatever the required structure was at the time. If that’s changed, then the whole formatting step will need to be rewritten.

I wouldn’t guess the restructuring of the json or whatever ThingSpeak wants would be too hard, but I don’t have time to look at it right now. If ThingSpeak now requires a secure connection (SSL, etc) or if they more want more metadata then there might need to be more tweaking for that.

[Author]

Posts