Tracer-RS485-Modbus-Blynk
Tracer-RS485-Modbus-Blynk copied to clipboard
jaminNZx
Code fixes and some new features
Love you work mate. Downright annoying stuff couldn't be moved to a second UART so modbus could have it's own dedicated channel. Do you think it's worth moving the 'debug' messages to UART2, since there is a TX there, and the missing RX doesn't matter as it would only be used for debug messages anyway?
btw... DE and RE are interconnected with a jumper and then connected do eighter pin D1 or D2 in the readme.md should be DE and RE are interconnected with a jumper and then connected to either pin D1 or D2 ?
Thank you. Yes that's a typo, I'm not a native english speaker. You can choose whether to connect to D1 or D2. About the UART2 thing, gosh, I spent enormous amount of time getting that to work - ended up in rewriting ESP8266 base libs. Then I realized that's not going to be the way to go. :smile:
If you want, you can try it, but anyway, when you flash the device for the first time and everything goes right, you should be able to re-flash it over the air with OTA updates.
I have such feeling, that all the UART2 madness that I've got into might be caused by the way the NodeMCU works. Look at schematics... You wouldn't get any debug messages from UART2 after swapping UARTs because there is no connection to the USB TTL chip (CH340x / CP210x / etc.). But that's just a guess.
For me, it was really annoying getting it to work and failed!
I've also tried SoftwareSerial, with no success.
I literally tried everything you could imagine.
ESP32 is the way to go for this project, but that would, of course, needed a lot of additional research.
Anyway, thank you for your comment, it makes me happy that this project is useful for somebody. :smiley:
Serial.swap() should move the Serial endpoint to GPIO15, GPIO13, which as you say, are not connected to the USB TTL chip, meaning that communication with those pins won't overlap. But, there is the added issue that GPIO15 should not be held high at boot (which it appears the RS485 adapter is doing), so it looks like it's not suitable :( It may be worth trying Serial.set_tx(2) to move the Serial TX to GPIO2, but that pin has the problem of that it shouldn't be held LOW at boot. And Serial1 can only use the TX pin, since the RX pin is shared with the onboard flash chip... so that can't be used for the RS485 link either! :( It would only be good for a debug link with an external USB UART.
So it looks like we'll just live with the current state of affairs! ;) I 'socketed' my NodeMCU board so it can get pulled if OTA programming plays up and I need to resort to the serial programmer. I'm in the middle of making it so ALL the registers are pulled into five structures, which can be displayed (and eventually configured) on a web server the ESP8266 is running. The dashboard I have running at the moment works great, using an AJAX call to keep updating the data every 5 seconds.
That's awesome! Have you pushed the code for the web interface already? I would really like to see it.
Let me know when you're finished with your project, it really sounds great. 👍
Sure... I just pushed it onto github as I already have it on my local git server. You can see a screenshot of the current dashboard... the code is still mostly based on jaminNZx's work, plus some of yours, then with the web-server wrapped around it. The registry data structs are still a WIP... still working out suitable data types for each. Will start migrating the realtime data over first I think, since it's already being gathered.
https://github.com/pfeerick/tracerWebserver
Wow, I've looked at the code, and I really like it. You've done a lot of work on the webserver. What I would do being you is to add a JS graphing lib and save history of PV to SPIFFS. Then you could generate pretty useful stats, like Blynk does on my branch. Then we would just get rid of the Blynk stuff and just forward port on the router and there ya go. 🙂
Thanks. :smile: Logging will happen (was actually one of the main reasons I wanted to tap into the Tracer RS485 bus), although I'm tempted to do it to a microSD card... not sure just yet. And some graphing is definitely planned, but will happen when/if I can work on it ;)
Logging to SD card would need additional hardware and wiring. You might keep this just only for necessary peripherals, especially when you have other options. I would prefer SPIFFS, when you would log in binary format, let's say once per 2-3 minutes, 3MB SPIFFS should be enough for at least a week of history data, (I don't know how long history you want - if you want to view all-year graphs, then SD or SPI FLASH is the only way). BTW I also have this "insufficient spare time problem". 😄
Indeed. That will be a long term goal, with define flags to enable it ;)
I've now got all the rated data, realtime data and statistical data being read and viewable... although will need to change the timings on that... don't need to read the rated data more than once after boot, and don't need to read the statistical data that frequently... maybe hourly at most.
I wanted to get the realtime-status, but it seems to be giving me a consistent '7' for charging equipment status... which I don't think is right. Will probably ignore that and carry on to reading settings and then coil / discrete input... And I've seen a javascript dials / chart 'thing' that might do the job :)
Awesome, good luck with that my friend! If there is something I could help you with, let me know. I might for example fork your repository, add that SD card logging and then we could merge it. Just let me know! I'm anyways going to work on this project in the near future, cause I've changed my router few days ago, now I have different SSID & password, so my Blynk Modbus ESP8266 (which is on the balcony, LOL) lost access to internet, it doesn't have any connection. I will have to do the update quick via USB (can't do OTA), it's winter here, sunny parts of day are short, and outside is like -10 deg. C. Brrrrr.
Hi @jaminNZx and @pfeerick ! What's up, guys? Just wanted to say that from the time when I was writing this project a lot happened. Now there wouldn't be such problems as with ESP8266 anymore, since we have ESP32-S3 and other fine devices :) I want to know, if you're still using EPEVER devices for your solar systems? I gave up after 3 devices in a row were destoryed by storms thoughouht the summer that time (they were LIGHT storms, anyway the devices stopped working). So I abandoned EPEVER totally, and now I'm using these little beasts Victron Energy MPPT 75/15! Yes, they are more expensive. Yes, they are much better. I have them running since the storms incident and they work great, without any issues, have serial output with open protocol, but also BLE & Android/iOS apps, from which I can control and monitor them. What about you guys? Are you still using EPEVER? :)