|
|
||
Right now I'm adapting the code to work with Nibe S series and also make it compatible with NibeGW, making it more adaptable. My goal is to release one or two docker images. One with a very simple nibepi image just forwarding to mqtt. With one config file for all settings. And another image with the whole nibepi setup, backend and frontend. Both of them compatible with S series and NibeGW. 1 |
||
|
||
Support for NibeGW: does this mean you could have an Arduino with NibeGW and NibePi as UDP endpoint for it? |
||
|
||
Yes! NibePi will receive and transmit the UDP data instead of it's own core. I got it working, just optimizing the code now. |
||
|
||
Do you have a list of the supported Modbus-Addresses for the S1155? We only got this list so far: https://up.picr.de/38821944lh.pdf Thats way less, than for the "F" series. Is the "S" series really that limited on Modbus? Or is our list just incomplete?! |
||
|
||
I got the same list. From what I've heard the list is not complete yet. My guesses are that they rushed the release of the S series and down prioritized Modbus. The integration is working however, when I get a better list it's just to add registers to a list and it's done. Actually NibePi supports adding unknown registers for testing (without factor) . Many registers are working and I have find a few more for System 2 for example. |
||
|
||
|
sounds great, thank you for your work :) ||
|
||
I have run in to some issues. I can't get my docker container to receive the UDP communication with NibeGW. All ports are open as they should in my docker-compose file. Anyone have any experience and can help me get further? |
||
|
||
According to [1] and [2], try to run the container with the --network=host parameter: docker run --network=host <CONTAINER> [1] https://stackoverflow.com/questions/54360408/docker-container-udp-communication-with-other-hosts [2] https://stackoverflow.com/questions/42422406/receive-udp-multicast-in-docker-container |
||
|
||
Thanks, I have tried that. dont really understand why it cant work. It works outside the container. Here is the docker-compose file. I will read through your links more careful later and double check a few things. Maybe I got my own code wrong.. |
||
|
||
Had similar experiences too when trying to connect a simple nodered node (within docker) to my fronius symo.. Didn't dig into this further, but for me the findings were: - per default the docker container can reach the internet (so the host networks gateway and dns are in use) - on linux, iptable rules are automatically added to restrict the access to the host network (even if you are using sth like ufw that adds a layer on top of iptables) - --network=host did not work for me - macvlan could be of interest here - in general my next steps would be trying to understand the networking details of docker and then manually creating an appropriate network. But that will take me some time (due to lack of spare time... ) Regards Andi |
||
|
||
Thanks for your help, good information and that made me realize that it must be my code that is wrong. And so it was. My UDP listners was started before the right IP address had been set. Now it all works as intended. Just some more fine adjustment and I'm gonna set up a page with information. 2 |
||
|
||
Great! According to my experiences with F1155, I would just scan all possible addresses and compare the output to both F-addresses as well as known data from user interface. This way, I found the heat meter for passive cooling... this one is even not available in Uplink... |
||
|
||
Unfortunally the registers or ID dosent seem to add up at all, for example. outdoor temp is 30001 (or 40001 depending how you interpret them). And BT6 and BT7 is also very different. But som registers I can guess, heatcurve for system 1 is documented as 40026, but system 2 heatcurve is not documented, but following the F series sorting the heatcurve S2 is at 40025. I have access to a S1255 for testing but havent gone any further to search for more registers right now. A lot of work for something that Nibe might release just anyday, who knows.. |
||
|
||
I have a question about the bypass air recirculation function. With 48902 I can set a temperature difference. but 48970 Outdoor Air Mixing is always 1, and 43096 Mixing Value State is always 0. can I see the position of the bypass valve? Hartmut |
||
|
||
Guten Abend, 454 Beiträge, 30 Autoren! Wir sind weit entfernt von Plug and Play 😀 |
||
|
||
Deswegen heißt es auch DIY im Titel Und es werden auch verschiedene Lösungen inkl. deren Entwicklung hier diskutiert. Da ist einiges Off-Topic dabei. Ich glaube aber, dass vor allem die NibePi Lösung durchaus in Richtung PnP gehen kann, wenn alles auf einem vorkonfigurierten Image kommt. 1 |
||
|
||
Die alte Version war ja schon als Image verfügbar, damit hält sich der Aufwand in Grenzen (die v1.10 ist ja noch nicht raus) Wer sich 800€ für das Modbus Modul oder jährlich Uplink sparen will (und dazu noch eine bessere Lösung erhält) kann schon mal ein wenig basteln :) Was hier der Entwickler und alle beteiligten leisten ist echt top! |
||
|
||
Working all the time with this. German and english translation is in progress by a very nice german fella :D Docker images is being tested and the release of 1.1 is getting close by. It will be a PnP solution with an SD-card image or Docker container. 2 |
||
|
||
It would be great if anyone could test out my basic docker image. More information can be found under the offical docker hub page. https://hub.docker.com/r/anerdins/nibepi-base All the information needed should be there. If there are something missing please let me know. I have only tested it with the NibeGW gateway. If anyone could test it with serial connection, that would be great. The image was built on a x86 computer, i'm not sure that it will work on a raspberry pi. Please let me know. 1 |
||
|
||
The workaround for this is by building the image manually. Do like this. git clone https://github.com/anerdins/nibepi cd nibepi/docker docker-compose up This will start to build the image on the platform that is running. Note that my instructions are for docker-compose which is needed. But it's the best tool around for docker. |
||
|
||
Sounds great, thank you! So the base image either does the modbus communication ("serial"), or the udp based communication with nibegw and then forwards everything to the configured broker...? Some questions (just to get it right.. ;) - is there still an embedded broker started if no external is provided? - advantage of nibeGW: if the base image application is not running, the handshakes towards the nibe are correctly handled (no errors..)..? - advantage of the base imae app: no further rpi/arduino needed (but of course the modbus adapter), but the app has to be running all the time (or how does the nibe react if there if no one responds)? - any dependencies to nodered in the base image? - docker compose only needed for the things mentioned (host network, volumes, serial device,...), or is there another reason for its requirement? Regards |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]