@andriej
Hi, I had problem using the main branch mysensors/Raspberry, that because of the bit-field struct (header_s) in Sensor.h They will get packed in different order on the arduino compared to the RPi (at least with my compiler, gcc). In order to fix this I created the 1.4dev branch. It uses full bytes instead of the bit-fields, but you need (of cause) to compile both the sensors (arduino) and the gateway (RPi) using the 1.4dev branch.
We need to fix this in the main branch later on (and use the same files as in mysensors/Arduino/libraries/MySensors)
@sandorhoffmann I hope there is someone that can answer your question.
But, I really recommend using DHCP. In that way, you can control all of your IPaddresses in one place, your DHCP server (almost always, your router)
The huge advantage of ESP devices over Arduino is the WiFi. You don't need a big library. The MAC address is hard coded at the factory. I'm not sure that you can change it, which you would want to do if a device failed and you need an EXACT replacement.
The downside of ESP is also the WiFi. Most home routers can only handle 20-30 WiFi devices My Asus routers start dropping WiFi devices resulting in difficult reconnects. The network becomes unusable. Because I have many ESP devices, I employed a Ubiquity access point that can handle 300 WiFi devices. The routers can handle 254 (253?) IP assignments, though some only allow 64 DHCP assignments.
There is a discussion on this forum someplace on the number of clients there can be in a MySensors network. In theory 254 (253?) is the max, though I am unaware if anyone has tested it. I use an RPi as my gateway and haven't had problems with too many devices. If one is considering a very large number I would recommend starting each sensors one at a time because the gateway way will assign the NodeID which gets written into location 0 of the EEPROM. Or burn a NodeID into the Arduino EEPROM before running the actual code.
bottom line, you didn't do anything wrong, its the nature of the beast.
MySensors is an EXCELLENT project.
It allows for complete control over the various sensors.
It's extremely simple.
Its drawback is that it's open source, so it's unfunded and development is slow, but I don't think there are any better projects than this at the moment.
Are you still able to use the same analog phone plugged into the back of your modem? If so then it has to still use the same protocol, and I don't understand why the analog beacon wouldn't still work. It would just have to be on that same wire, not on the internet side of the modem. The modem is doing all of the translation in that case.
Or am I missing something? Did you have to get a new phone to use the new service?
@Tmaster I think it writes better code than a lot of code I've seen, and the documentation is a lot better. The latter, of course, is because most coders don't document.
some key elements:
good statement of work -- Purpose of the Code is key (did you write that? Good job!). This will guide the AI to write what you want.
descriptive variables
good documentation
code is independent of reading sensors up-to-down/down-to-up
I spent a couple hours analyzing, researching and writing and re-writing this and all I can say is that the AI didn't catch is, as far as I can see, if your sensors are too far apart or your magnet is too weak, you could get false readings.
You, being the author of AI directive, are responsible for for the code. The AI is just a tool.
I started my coding with assembly language, though at that time we still had to enter the binary on some machines (set 16 switches, then press commit). ForTran and COBOL were the first real high level languages and subsequent languages, pascal, c, java, etc. were improvements. AI is a quantum step. It's still coding, but you have to learn how to talk to the AI to get what you want.
Good project! Let us know how it turns out and if you had to tweak the code.
-OSD
