RPi Home Automation Software

I really find that hard to believe. I looked and (for instance) there is no integration listed in the Domoticz docs for a Levoit Humidifier. True, the integration didn’t work in HA immediately for what I needed, but I added to a PR and now it does (although I am using a custom integration and overriding the core integration for various reasons - which I see as an advantage).

It may be surprising but it seems that almost everything is an add-on/integration/whatever in HA (and many of them seem to need patching and/or overriding like the one you used). Plus, there seem to be multiple competing options for many things, often with little documentation and devs that are a bit abrupt, to put it mildly (and I’m far from a diplomat, after all, so if I think that when reading their replies to users…)

I meant specific to deploying as a container (in my case on the RPi running EmonCMS) but actually let me also correct that I haven’t found anything I couldn’t do with the container deployment, it might just take some extra steps (not the standard path).

Fair enough. Just for reference, my ubuntu machine is running on a ± 10 year old Intel Core i5 consumes <100Watts (and that is in part because of the spinning hard drives) But for sure more than any Rpi.

I did the self install for Google Assistant integration (without Nabu Casa subscription) It requires quite a few steps, but it ain’t rocket science either. I did it for both my setups. One with reverse proxy one without. Both with let’s encrypt for HTTPS with duckdns.

I agree that automations have a steep learning curve, and this is one of the biggest hurdles IMO for Home Assistant adoption by a wider audience. For example you probably won’t use “Device” as a trigger but you’ll want to use “States” instead, similarly for most actions you’d use “Call service” and not “device”. Not to mention the way the logic operators like “and”/“or” work. This is not intuitive for first time users.

I have hit 1 breaking change, clearly release noted, where the credentials of my integration had moved from the yaml to the UI, as the integration now supported this. But yes this risk does define how I adopt (or skip) integrations.

In my experience it is possible to use Home Assistant without too much maintenance trouble if you stay on the beaten path and steer away from the bleeding edge and random github addons that haven’t been updated for 2 years.

For me personally, the key benefits I get using home assistant:

  • I can integrate with virtually any smart home component (from Sonoff to IKEA to full DIY ESP32), over wifi, zigbee zwave, 433Mhz etc. (nowadays I first check integration availability before I buy any smart home electro )
  • Usually I can do so with only local access (bypassing some unreliable and obscure cloud service) ideally without having to flash the device
  • very powerful automation capabilities of which I probably only use 10%
  • active development with large community (although perhaps not as nice as this one :wink: )

good luck!

2 Likes

dietpi not very small base image - example image at 117 meg for an zeropi, with openwrt it is a 7 megs base image. to configure for base operation it size is usually grows to about 30 megs image after adding in python and other base software. then after that any secondary software I stack on top ie database or zigbee2mqtt. and really I have tested alot of different linux flavors and openwrt as a Base OS for small devices, while not really a full fledged OS it is the most stable and uses the least amount of resources to do stuff… where other linux based stuff is stalling out because the resources ran out. openwrt happily spits it out and keeps on chugging along .

BUT, I admit working with openwrt can be daunting for most, especially building a toolchain to compile software for it and the primary build taking up to 24hrs or more to set up and compile the base toolchain for your specific hardware . but after that compiling pretty quick for most software.

Domoticz supports alot of harware, and what not supported can easily added in with relative ease . but hey to each their own

Personally, …

  • Started with smartthings years ago - had great support, flexiblity, zwave zigbee IP etc etc
    But it started to get more limited and their direction changed with some pros and cons

  • Moved to hubitat - ok, flexible, but also things I dont like

  • Have Domiticz as well - so so, good at some things, not at others

  • Have HA more recently - started to use a bit, but feels rather ‘hard to get in to’ so far

  • All this combined with webmin, nodered (and dashboards), mqtt, webmin, containers, s3, shinobi, grafana, emoncms, iotawatt, lots of API integration etc etc

  • And many many gadgets from RPIs, cctv, plenty of relays/switches, plugs, alexas/google, sensors, garage door, lights, curtains/blinds, heating, EV integration, EV charger integration, vacs, smartmeter and modbus integration, xlights etc with both out of the box integrations as well as custom integrations (drivers and also m5sticks and the like)

And of course emoncms

I find they all still have plenty of limitations and take a lot of investment to make something sophisticated - still way way off any nirvana of decent experience

1 Like

Compared to most distros it is very small :laughing:

I wasn’t suggesting it is smaller than OpenWRT, but if you want a small easy to use distro, DietPi is hard to beat.

It sounds like what you are achieving here is “control”, not “automation”. Whilst you haven’t shared the details, I suspect that using time as a parameter for your formula on this device is not ideal, except with perhaps the exception of defining a work / home / sleep pattern. The other factors are probably best served with external temperature monitoring and a feed of energy prices if they vary that much throughout the day. Using time to predict when energy rates are high (assuming you are on a tariff that changes by the hour) and also that it will be warmer in an afternoon will be flawed. As for having to adjust a formula, you should only need to do this once maybe with some fine tuning until you get it right. The point being, you are probably having to adjust your schedule approach regularly based upon seasonal change, energy price pattern changes, an automation formula would have this built in and could be left alone to take care of the variations throughout the days / weather / seasons.

In short, using your approach and time scheduling is based upon how “you” want to “control” the system, not defining an “automation” for the “system” to work out how you control devices to meet your parameters. With the automation, it really doesn’t matter if the system has to re-evaluate the heating control every time there is an energy price change or external temperature change, that’s exactly what we have computers for.

I didn’t say on GitHub? But in any case, I think suggestions / requests are supposed to go in a forum called “What the Heck” or something, a bit un-orthodox, but it’s their way of allowing the HA community to dump their ideas and have voting. I think this month is in fact the month that they review… Not entirely sure.

Yeah, just one automation! :person_facepalming: :slightly_smiling_face:

With regards to underestimating scheduling I refer to my earlier comment about “control” vs “automation”. Yes there is still a place for scheduling, but no more than anything else. In fact, for my own requirements, I can only think of needing a schedule for my economy 7 electricity pricing (it’s specifically driven by time) and a pattern for being home / away / sleep (which I don’t actually have a use for currently).

I get mixed messages from reading your posts, you have advocated that as a platform HA is regularly broken and unstable, yet you’ve not experienced this for yourself, or actually spent any significant time using it.

It seems you’re intimating that you have a mission-critical requirement (by way of you inferring that mine isn’t) but expect to have this served by something that is both free and built to your purpose without bugs or much user effort. To this end, you either need to buy into something significant and spend a lot of money having someone customise it to do exactly what you want (completely against your “free” requirements) or work at it yourself (against your “built to purpose” requirement) IMO.

In my view, non professional home automation is still in it’s infancy, it’s firmly in the “Gadget” arena, no one “needs” their lights to turn on as soon as they walk into a room, we’ve always had switches by the doors for that reason, but with the continual shift in our lives to be technology driven, more people are intrigued by the possibilities of them just turning on when you walk in if it’s dark enough to warrant it (as an example).

That includes me, my C4 solution works, but it’s slow, limited and costs money every time I want to do anything with it. Thus far, HA is the only platform that’s showing promise in being able to address those issues. With it, comes a huge expansion in what I can control versus C4 for an acceptable amount of input from me (to avoid paying) and once I get over the multi-room AV distribution issues, I will replace C4 entirely with it instead of using it side-by-side with it as we do today.

I think it’s fair to say we have different opinions on this, so I’ll wish you good luck in a hunt for your solution, but if you want to tease out anything further on HA I’d be happy to try and help, although I’m by no means an expert on it!

That is a really interesting distinction.

I combine scheduling and automation; so if my daughter is home (automated via a sensor), I schedule the target temperature in her room and thus the heating. A combination of automation and control :slight_smile:

What you need I’d suggest, is an automation, that takes sunset and adjusts when the heating and therefore the HP come on. That cannot be done simply by a timer, but is simple enough in HA.

1 Like

I too started out by thinking that a smart home / automation was about getting control of devices electronically through an app of some form. But in essence, this is “control”, personally I see scheduling as a “control” also, but control of time.

Automation I see as a bringing together of control elements to systemically, in a smart fashion, perform functions that you would otherwise need to do manually. Scheduling can be part of this, but where possible I prefer to use something with more flexibility as scheduling is typically more fixed rather than smart.

Agreed, or better still, since it could be a really cold day but sunset hasn’t yet occurred, add an external ambient temperature monitor and use this, thus capitalising on any time period where it is warmer outside regardless of time of day. Obviously requires additional hardware as the sunset sensor is free.

1 Like

Just on the scheduling front…

Did you see the new scheduling feature added in 2022.9?

Not sure if it’s sufficient for your needs or not.

If aimed at me, then yes. The reception has been a bit lukewarm. I doubt it will replace my use of Schedy as that can be based on so many different scenarios.

I had, I tried it on a test system, and referred to it above: it’s more limited than contrib schedulers (or other apps) and still only feeds into automations.

It also currently has a practical problem for my application, where it would run on the same Rpi as emoncms, not my test system: recent HA requires a later python (3.9?) than on emonSD (3.7), but upgrading would bring a later php (8.1 I think) than emoncms is fully tested on. Not insoluble, but still another problem.

An external sensor reading is another input to the target temperature calculation. The timer-ed input is the part only depending on time (including sunset) that can be precooked to simplify the scripted calculation.

Hello I’m new on the Community. A friend of mine gave me a not used “EMONPI” (the aluminum chassis with display, shield and stuffs) I added a RPI, a power sensor and I’m playing with it.

I’m a Domoticz user, I use it since years ago and I use it for whatever I can in my home automation and I’m trying to use Emonpi for energy meter.
At the moment I’m able to read voltage and power usage (I had to correct scale in emonhub.conf) and it seems it’s ok,
I’m reading data with MQTT and I’m updating Domoticz via curl/json with a crontab script.

It works, but it’s a workaround: reading via MQTT takes seconds, crontab script is not realtime, so I’d like to write these data directly in my Domoticz (using MQTT or json).
I think the way is reading /dev/ttyAMA but… I was not able to understand HOW the data are calculated… I tried to understand the output but… no way, looking for info I just became more confused… is there anyone can give me some suggestion? I’d like to understand protocol to write code directly reading ttyAMA output and not reading it via MQTT.
What I get with (for example minicom) is:
OK 5 145 0 0 0 145 0 193 85 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)

my “scale” is:
scales = 1.3,1,1.3,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1

but I’m stuck…

thanks a lot for any support, Leo

1 Like

Welcome, Leo, to the OEM forum.

I can’t help you with MQTT or Domoticz, but I can tell you how to decode

It is a string of bytes with the value given as a decimal number. But you need some more information to know what the bytes represent. Your emonHub configuration file will tell you (look in emonCMS → Setup → Emonhub → Edit config) and find Node 5. It starts “[[5]]”

It might be like mine

[[5]]
    nodename = emonpi
    [[[rx]]]
        names = power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulse1count,pulse2count,E1,E2
        datacodes = h, h, h, h, h, h, h, h, h, h, L, L, l, l
        scales = 1,1,1, 0.01, 0.01,0.01,0.01,0.01,0.01,0.01, 1, 1, 1, 1
        units = W,W,W, V, C,C,C,C,C,C, p, p, Wh,Wh

My guess is you won’t have pulse2count, E1 & E2.

All the numbers match 1:1 left to right, so the first element is power1, the datacode is h, the scale factor is 1, and the units are w.
The full list of datacodes is here: emonhub/configuration.md at emon-pi · openenergymonitor/emonhub · GitHub

The part you need to look at is datacodes =
h is a signed int16_t (2 bytes), L is an uint32_t and l is an int32_t (both 4 bytes)

You decode your data like this:
OK - no checksum error
5 - the node ID the data comes from
145 0 - power1, 2 bytes, value = 145 + 0×256, this is then multiplied by the scale factor 1.3 (why? - it should not be necessary, do you have a different c.t. or a.c. adapter to our ‘standard’ ones?)
0 0 - power2, 2 bytes, value = 0 + 0×256, this is then multiplied by the scale factor 1
etc.
The pseudo-code to decode the bytes is

for extracting signed integer

  x= ([1st byte] + ( [2nd byte] * 2^8) ) 
    if x > (2^15)
        x = (x - (2^16)) 
    return x  
or
  x= ([byte 1] + ( [byte 2] * 2^8) + ( [byte 3] * 2^16) + ( [byte 4] * 2^24)  ) 
    if x > (2^31)
        x = (x - (2^32)) 
    return x  

and for an unsigned integer, ignore if x >

Hi Robert and thanks a lot for clearing me up on this!
I didn’t consider TWO bytes for power, now I can understand it :slight_smile:

for pulsecount you mean an AC/AC adapter connected to the Emonpi? I connected an old 9V AC power supply, maybe is not working well… I have to check it.

I’m in Italy and the “device” providerd by my energy supplier has a display and I can see power usage (Watts) in realtime. The value on device was always 1.3 bigger so setting the “scale” factor I always have the correct value on Emoncms too.

Maybe with a good AC/AC adapter for pulsecount I don’t need this?

The other strange thing is: the VRMS I can read on serial is 193, but EmonCMS shows the correct value between 220 and 230V…

regards, Leo

18 posts were split to a new topic: Getting data from EmonPi to Domoticz

No, I mean the input on the RJ45 connector labelled “RJ45 I/O” that’s NOT the Ethernet one for counting pulses either with S0 contacts or the optical pulse sensor.

The a.c. adapter measures the mains supply voltage. You need that plus current transformers to accurately read real power. If you need to multiply by 1.3, it means either or both are now giving the output we expect. The a.c. adapter and the c.t. always give you the power reading at worst 10 s old. You can only know the average power from a pulse count after you have received a pulse - so it is always history.

I think your friend must have changed something inside emonCMS to calibrate it. If you look at the Input processing, you might find they multiplied the number coming from the “emon” part (the numbers you see in the emonhub log) by 220 / 193. The “193” is wrong because the wrong voltage comes from your a.c. adapter - but it does not matter, you calibrate the emonPi to make it correct.

No, I didn’t connect anything yet… I have to read documentation, I though was not important to me.

it’s a very old one, imagine it’s marked U.S. Robotics, it was the power supply of an old 14.400 modem I guess :smiley:

I rebuild SD downloading the img file, the Emonpi I got was without RPi, so I put one of mine inside it

yes but… the EmonCMS shows the voltage accurately, the problem is ONLY on the ttyAMA output… this is very strange for me…

For one i use my EmonPi as sole home automation engine.
I live in an old farm off-grid with only 6 PV panels. I have to drive my power consumption harshly in winter time…
I have 1 EmonTx and 4 EmonTh in the house.
I do write glue scripts in bash as mqtt publishers or suscribers and publish whatever I want to store as mqtt topics to be picked by EmonCMS.
On the Pi, I’m running GitHub - jchdel/weewx: WeeWX code repository to publish weather data.
I use GitHub - jchdel/mpp-solar: Python package to communicate to MPP Solar PIP-4048MS inverters (and similar) to publish inverter data.
I wrote a small 1-wire2mqtt script also for a couple of sensors (should publish in my github).
I have a wifi2mqtt relay.
Plan to introduce zigbee2mqtt next week, with a couple of smart-plugs and Utility meter reader to start with.
The script to pilot my 23 years old dumb fuel heater via the relay is about 60 lines of bash and takes quite a lot of parameters fetched from EmonCMS via it’s API into account.
The whole point to me for home automation is automation. Therefore I do not need an interface to pilot the house. Just some dashboards and a way to visualize timeserie values. That’s perfectly done by the OEM team so I do not have to reinvent the wheel as a geek :wink: and I, as a geek I’m, just dump a couple of bash lines on top of an already complete infrastructure!
Thanks guys!

1 Like