EV Connect developed and operates the industry’s most robust and flexible cloud-based platform for the management of the Electric Vehicle (EV) ecosystem

EV Connect

We shall create a Bot in which aware of Batch Presence change event. Slack Go Essentially we are going to build and run the example given here: . This tutorial give a more detailed actions of how to make it run, so that even a relatively new can follow this easily. https://github.com/nlopes/slack/blob/master/examples/connparams/connparams.go An examples of presence change event is when a member of the chat group changes their status from active into away. Slack provides an to their API for a more efficient presence change detection, by having it in a batch. This is in accordance to proliferation of groups with large members in Slack, where changes of presence could resulting in expensive handling of many events at a short period of time, or at the cost of missing some of the event. update In this tutorial we consider that a Golang has been installed. You can also refer to for such purpose. https://golang.org/doc/install For a more clear step by step activities, we can refer to commits of . https://github.com/suekto-andreas/tutorial-go/commits/TUT-001 How can this base code be expanded Out of the code created by following this tutorial, you can expand it into a more complex bot, one of the very preliminary extension can be happened at creating Handlers into the event. (This tutorial is just simply doing print.) Not too mention once you generates Handlers and creating a more complex business process / use cases, takes care of the package oriented design, provides automated unit testing. I personally prefer the concept of treating a Go project like a library, while the executable is grouped inside directory. cmd Create Slack Token First we need the token for accessing the API. Please refer to the following link to do so : https://get.slack.help/hc/en-us/articles/215770388-Create-and-regenerate-API-tokens Get the Dependencies We are using the following library to communicate with Slack : . Let’s go get it, run the following command in terminal https://github.com/nlopes/slack $ go get github.com/nlopes/slack Create our Project Directory For this purpose, as we simply create a command line to be executable, I structured this as following: this tutorial project structure When you are aiming for building a specific slack bot project, you might prefer a less hierarchy here, as the above structure is prepared for more tutorial codes to be put under 1 repository. An example would be that the become the root project directory, instead of . batchaware tutorial-go Write the Code Our code shall be a simple main function. First of all let’s instantiate a Slack object. Replace “YOUR TOKEN HERE” with the one we created in the previous step. (If you are considering a production code, ensure that token here is provided in a better way, not hard coded, put it for example as ENVIRONMENT variable.) package main import ("fmt""log""net/url""os" "github.com/nlopes/slack") func main() {api := slack.New("YOUR TOKEN HERE",slack.OptionDebug(true),slack.OptionLog(log.New(os.Stdout, "slack-bot: ",log.Lshortfile|log.LstdFlags)),)} Next is for us to establish an RTM (Real Time Messaging) connection with Slack. Here is we pass in the Option parameter that indicates our Bot is ready for batch presence aware. rtm := api.NewRTM(slack.RTMOptionConnParams(url.Values{"batch_presence_aware": {"1"}})) Let’s start the connection go rtm.ManageConnection() Afterward we can listen to even by looking at the IncomingEvents channel, using the following for loop for msg := range rtm.IncomingEvents {fmt.Print("Event Received: ")} We are going to send hello world to the channel where we want our bot to be listening to. We use the ConnectedEvent to do this, this is an internal event of the library, not a Slack event. Upon this event we SendMessage which indicates the corresponding Slack Channel ID, we want the Bot listening to. for msg := range rtm.IncomingEvents {fmt.Print("Event Received: ") switch ev := msg.Data.(type) {  
case \*slack.ConnectedEvent:  
    fmt.Println("Infos:", ev.Info)  
    fmt.Println("Connection counter:", ev.ConnectionCount)  
    // Replace ABCDEFGH with your Channel ID  
    rtm.SendMessage(  
        rtm.NewOutgoingMessage("Hello world", "ABCDEFGH"))

default:  
    // Ignore other events..  
    fmt.Printf("Unexpected: %v\\n", msg.Data) }} To activate presence change event we need to first subscribe for this event (it’s a mandatory step since Jan 2018.) We going to subscribe during HelloEvent, which is a Slack event when the Bot has successfully connected. For this step we need USER-IDs, a simple way to retrieve some of this can be done by following this step . (For a more automated way, the following could inspired you.) here link for msg := range rtm.IncomingEvents {fmt.Print("Event Received: ") switch ev := msg.Data.(type) {  
case \*slack.ConnectedEvent:  
    fmt.Println("Infos:", ev.Info)  
    fmt.Println("Connection counter:", ev.ConnectionCount)  
    // Replace ABCDEFGH with your Channel ID  
    rtm.SendMessage(  
        rtm.NewOutgoingMessage("Hello world", "ABCDEFGH"))

case \*slack.HelloEvent:  
    fmt.Printf("Hello: %v\\n", ev)  
    // Replace USER-ID-N here with your User IDs  
    rtm.SendMessage(rtm.NewSubscribeUserPresence(\[\]string{  
        "USER-ID-1",  
        "USER-ID-2",  
    }))

default:  
    // Ignore other events..  
    fmt.Printf("Unexpected: %v\\n", msg.Data)  
} } After all is set and done, we now shall listen to our main target in this article, the presence change event ! for msg := range rtm.IncomingEvents {fmt.Print("Event Received: ") switch ev := msg.Data.(type) {  
case \*slack.ConnectedEvent:  
    fmt.Println("Infos:", ev.Info)  
    fmt.Println("Connection counter:", ev.ConnectionCount)  
    // Replace ABCDEFGH with your Channel ID  
    rtm.SendMessage(  
        rtm.NewOutgoingMessage("Hello world", "ABCDEFGH"))

case \*slack.HelloEvent:  
    fmt.Printf("Hello: %v\\n", ev)  
    // Replace USER-ID-N here with your User IDs  
    rtm.SendMessage(rtm.NewSubscribeUserPresence(\[\]string{  
        "USER-ID-1",  
        "USER-ID-2",  
    }))  
  
case \*slack.PresenceChangeEvent:  
   fmt.Printf("Presence Change: %v\\n", ev)

default:  
    // Ignore other events..  
    fmt.Printf("Unexpected: %v\\n", msg.Data)  
} } Run the Bot To run the bot (given the directory structure as is in this tutorial) $ go run slacktut/batchaware/cmd/batchaware.go Then the bot shall start listening into the Slack Channel. Try by making a member in the channel to change its presence (like from active to away.) switch ev := msg.Data.(type) {case *slack.ConnectedEvent:fmt.Println("Infos:", ev.Info)fmt.Println("Connection counter:", ev.ConnectionCount)// Replace ABCDEFGH with your Channel IDrtm.SendMessage(rtm.NewOutgoingMessage("Hello world", "ABCDEFGH")) case *slack.HelloEvent:fmt.Printf("Hello: %v\n", ev)// Replace USER-ID-N here with your User IDsrtm.SendMessage(rtm.NewSubscribeUserPresence([]string{"USER-ID-1","USER-ID-2",})) default:// Ignore other events..fmt.Printf("Unexpected: %v\n", msg.Data)}}

Slack’n Go: Batch Presence Aware Bot

WebSockets are mainly used to create real-time applications, such as chat apps, collaboration platforms and streaming dashboards. These applications take advantage of two-way/bidirectional communication between a server and users’ browsers. Serverless is usually associated with FaaS, an isolated stateless function that is triggered by another service. Creating a Serverless Websocket application would require you to use AWS Lambda with WebSockets in API Gateway and DynamoDB to store connections. This is overly complicated. We’ll show you how to create something faster. Serverless iFaaS platforms don’t require initialization before the function executes so you don’t pay a price for waking up a container once it has been deployed. It’s technically always live. You also have access to a baked-in key/value store which means that you don’t end up losing state between subsequent invocations. I.e. you don’t have to start from a blank slate on every invocation. Hence the lack of need for an external database such as DynamoDB. The Plan We’ll demonstrate something very simple here by using a pre-made Websocket Trigger to connect and broadcast all messages to all connected clients. See the visual workflow below. You’ll need a free to set this up yourself. Lolo account If you want to get started right away you can simply copy the contents of and paste it into a new application in a blank graph in Lolo. Save and Run the application to deploy it. That’s 1 minute of work. this document Do follow along though if you want to understand how to use it or if you want to set this up from scratch. Create an Application and add a Trigger To begin, we need to set up a new WebSocket server that can handle inbound WebSocket requests from clients. We do this by first creating a new application in your and then adding the Trigger from the Functions Gallery on the left of the graph. Add in a path name, such as . You can also rename it. Lolo account Lolo/Websocket /socket Process the Incoming Request When you add this you get three output ports in the node called , and so you need to set up ways to process these requests. Add another inline Function (i.e. a custom function) and name it Remove the in port and instead add in three in ports called , and . WebSocket Trigger req message close ‘Process Request.’ req msg close Link the ports to the right in and out ports with the nodes, look below for an illustration on how to do this. We need a bit of code to do something here with the WebSocket connection. Copy and paste in the code from below. Open up the Process Request node and paste in the code below in the handler. const connections = {};

exports.handler = async (ev, ctx) => {
  const { route, input, inputs, log, emit } = ctx;
  const { sessionId } = ev;

  // check incoming port (i.e. req, message or close)
  switch (input) {

    // on first connection
    case inputs.req:
      connections[sessionId] = {
        send: body => emit('response', { body }),
        end: () => emit('response', { end: true }),
        info: ev.headers
      }
      ev.body = { connected: true, yourConnectionId: sessionId };
      // re-route data to 'req' output port
      route(ev, 'req');
      break;

    // on subsequent messages 
    case inputs.msg:
      // re-route data to 'msg' output port
      route({ connections, message: ev.message, sessionId }, 'msg')
      break;

    // when client disconnects 
    case inputs.close:
      log.info("client has disconnected");
      delete connections[sessionId];
      break;
  }
}; The code above is checking what ports the incoming data is routed through, giving us a way to handle a new connection by adding it to connections. We are also setting up how we want to handle subsequent messages and a disconnecting client by using the in ports, msg and close. This code above though is re-routing to other nodes via the route() method as well. As you can see we have two output routes here to ‘req’ and ‘msg.’ We thus need to add those two output ports as well. Send back a response Now we have two outports in the Function that needs to go somewhere, so we create another inline Function called and paste the code below. Process Request Affirm Connection All this does is signal the listener within the WebSocket Trigger to send a response to the client. We will route the req route to this node. exports.handler = async(ev, ctx) => {
  const { emit, log } = ctx;
  // Log to the console that a client has connected
  log.info("client has connected");
  // send response to the client
  emit('response', ev);
}; Along with this we also need a way to handle subsequent messages. In this case, we said we would broadcast all messages to all clients when someone sends something. So, create another inline Function (i.e. a custom function) and call it . Paste in the code below, and see the comments to understand what it does. Handle Messages exports.handler = async (ev, ctx) => {
  // extract connections, and current session id from the event data
  const { connections, sessionId } = ev;
  // send messages
  await broadcastToAll(ctx, connections, sessionId, ev);
};

const broadcastToAll = async ({ log }, connections, currentSessionId, ev) => {

  // loop through connections
  Object.keys(connections).forEach(sessionId => {
    try {
        // send message to everyone but the current sessionId
        if (currentSessionId !== sessionId) {
        connections[sessionId].send(`${sessionId} says: ${ev.message}`)
        } 
    } catch (e) {
      log.error(e)
    }
  });
}; You can remove the out ports for both of these new Functions. Now we also have to route the data visually from the Process Request node to the other two nodes we’ve created. See these steps in action below. Save and Deploy Alright, that was it. You can save and deploy. Look in the Logs for the message to see if it is ready to use. This may take a while. We are not using any NPM modules here so should be faster but if we did we would have to wait about a minute. ‘Listening to port 4000’ Now go into the WebSocket Trigger to collect the External URL. We are going to use it to connect to this Websocket. Open two terminals on your computer and then connect via wscat on both. wscat -c wss://eu-1.lolo.co/:appId/socket Remember to NPM install wscat -g (via your terminal) first if you don’t already have wscat installed. Now you should be able to talk via the different terminals. Say hi and what’s up in either terminal and see the response broadcasted to all connected clients. You can ask a friend to connect on a different computer and talk that way. It goes without saying that you can connect this via a frontend to build a quick chat app. Remember if you are having issues, just copy the contents of and paste it into an empty graph in a Lolo application to get the entire app set up for you. this document Your Lolo app in free tier should be able to handle a few thousand of events per second. If you need more than that you simply add replicas when you configure your deployment to handle the increased load. Let us know if you have any feedback. We’re keen to create better Serverless experiences. Also published . here

Get a Serverless WebSocket Application Up and Running with Lolo in 5 Minutes

It’s Tuesday at 8:32 a.m. Sarah, a facilities manager, is darting off to work. She offers a quick goodbye to her twelve-year-old daughter, who’s texting a friend and listening to music on her Bluetooth headphones. Sarah gets into her EV, which automatically connects to her phone, and begins playing a song from her 80’s playlist. Upon Sarah’s entry, the car adjusts the seats and steering column height according to her preferences. On the drive to work, she uses a virtual assistant to call her husband to remind him of a dinner commitment that night. Finally, Sarah gets to work and wants to run an energy consumption report for two of her buildings. However, her submeter app and her energy dashboard don’t connect natively. Frustrated, Sarah calls her integrator for help. They give her an estimate of a week. Most of us understand Sarah’s frustration. It’s almost absurd how much connectivity, personalization, and power we possess in our ordinary lives that isn’t translated to working with buildings. Like Sarah, we often think: “ is ” Why the hell is this so hard to do when using our personal devices so easy! There’s a reason why Sarah and many of us in the automated buildings industry have this experience. All our everyday gadgets and technology today use cloud-native architecture. Imagine if your building gave you as much power to connect, to manage, and to create as your smartphone did. In general, the automated buildings industry has been slow to adopt cloud-native technology, and our buildings and stakeholders like Sarah are paying the costs. But there’s a way for the industry to embrace the power of cloud-native and transform our properties into powerhouses of integration and automation. It’s the Interoperable Building Box or IBB from the Coalition for Smarter Buildings ( ). C4SB Why Do We Need an IBB? Today, the smart buildings industry is facing an onslaught of challenges and disruptions from multiple sides. Building information systems are getting increasingly complex—more sensors, more points, more systems, AI, and digital twins. We have a flood of information and streams of data, yet no single nozzle that will do the work of putting out the fire. We also have incredible applications that do wonderful things, but getting them to work and communicate with each other seems to always be a Herculean task. The amount of effort and time is a major pain point for folks like Sarah, who expect things to work as easily as everything else in their lives. For most, the benefits of integration outweigh the level of effort. This is the main reason for the slow adoption rate. only just The industry’s slow shift to cloud-native is revealing a serious skills gap. Cloud-native has been the standard architecture for IT departments for years now, and the onboarding of OT into the cloud-native space is beginning to blur the lines between the two. IT and OT are converging, and knowledge of both is becoming a prerequisite. Today, it’s difficult to find enough workers with the skills and knowledge level to tackle both. All these challenges hobble the goal of delivering smart technology at scale. Overcoming these obstacles requires technology that facilitates app integration while also improving the experience of industry stakeholders like Sarah. Instead of retooling our entire workforce, we can retool the way we interface with building systems. What is an Interoperable Building Box or IBB? Let’s start with a technical definition: The IBB (Interoperable Building Box) is orchestration software running on a physical or virtual machine that exists on-prem; the IBB acts as a standardized interface to connect a building’s local network to the . The IBB runs containerized cloud-native applications and services based on the Open Container Initiative ( ) standard. The IBB makes deploying and managing containerized software easier and more secure and provides an automated way for systems to discover and connect with systems having matching capabilities both within the IBB or in the Cloud in a plug-and-play manner. Internet Cloud OCI The purpose of the IBB is to make a building cloud native. That is, all its technologies and apps are built to work within (i.e., “native to”) a cloud environment. It must also support standard cloud functionalities like containerization, dockers, and orchestration (Kubernetes). By functioning like a standard cloud provider, the IBB allows the building to reap the advantages of localized control, namely better resiliency, security, and faster access. inherently Imagine “A Smartphone for Your Building” In a way, you can think of the IBB as a “smartphone for your building.” Consider all the ways your phone expands your capacity to do things. You can talk to anyone, anywhere, at any time. You can download, install, and run almost an unlimited number of apps. You can connect to the internet, access cloud storage, store local data, share files with your computer, and connect to wireless devices. In the same way, the IBB expands your building’s potential by providing it greater power to communicate and connect. Overall, your property becomes exponentially more efficient and productive. And because the IBB is located on-prem (i.e., in your building’s “pocket”), it can reliably deliver secure local storage of sensitive data and low latency times. For example, data from equipment sensors need not make the long round-trip to a cloud platform and back again. Data storage and computation are already . Such local processing makes storage of sensitive information more secure, while low latency times help protect critical systems and sensitive equipment, while the cloud connection automatically creates a copy of such data for backup and analysis in the cloud. This is analogous to taking a picture on your smartphone; you can see the image immediately, and it is also stored in your cloud photo album. in the building Parts of the IBB At the heart of IBB is containerization—a technology for packaging, distributing, and managing applications in a self-contained unit (i.e., “containers”). Containers house everything an app needs to run, and this isolation makes them lightweight, portable, and consistent. Since multiple containers can run on the same IBB, they share the required computing resources (CPU, memory, etc.). cloud-native The IBB consists of three main parts: , , and . These parts function together to make deploying and managing containerized apps easier and more secure. Operating System (OS) Administration IBB Apps (OS) Operating System Like a great deal of cloud-native computing environments, IBB runs on Linux, either on bare metal hardware or on a suitable Virtual Machine. The OS layer of the IBB also includes the open-source Kubernetes (often known as k8s) orchestration platform that manages IBB App containers. The OS layer of the IBB also includes other open-source software to further automate the management of IBB Apps. Administration The admin area of the IBB provides the tools for administrators to install and manage containerized applications. This includes software for the management of IBB Apps installed in the IBB, as well as user access and security policies and management. These admin tools provide admins access to the IBB remotely, using secure proxying mechanisms. IBB Apps These are the Apps and services provided by Independent Software Vendors (ISVs) that are installed in the IBB by admin users using the Admin tools provided. Each IBB App exists in its own container environment and thus operates separately from other containers (as if in its own hardware environment). Each IBB App communicates with other IBB Apps using IP networking with the help of IBB orchestration. Improving Stakeholder Experience IBB implementation improves the experience for all stakeholders because it simplifies the integration process. Currently, building owners and managers like Sarah need to employ capable folks with specialized knowledge to get things to work together. The process is complex, time-consuming, and expensive. The IBB takes the complexity out of the process by facilitating plug-and-play workflows. Let’s see how this works by following the process of installing and configuring an IBB using two different personas. IBB Installation Both HVAC and IT engineers can use familiar workflows and tools when installing and configuring an IBB. Here are the steps for installing an IBB for an HVAC Engineer and a DevOps: —Jake is tasked with installing a physical IBB device. He orders a suitably specified IBB-compatible device from his trusted vendor (CPU, memory, storage, etc.), takes it to the site, fastens it to a wall, connects it to the network, and on his browser, navigates to the IBB’s address and the IBB “Welcome” page. Jake (HVAC Engineer) —Mandy is tasked to install an IBB in a Virtual Machine on-prem. She navigates to the IBB repository on GitHub, looks over the IBB installation instructions, downloads the code, installs the IBB in the VM using her standard DevOps tools, and navigates to the IBB’s address and to the IBB “Welcome” page. Mandy (DevOps) Both Jake and Mandy were able to work in ways comfortable with their respective experience and skillset to achieve similar results; Jake through physical “box” installation that he was comfortable with, and Mandy used online “virtual” tools she uses daily. These flexible workflows and tools speed up the integration process. IBB Configuration Once installed, Jake and Mandy will need to configure the IBB to their specific needs for the building. On the IBB “Welcome” page, Jake/Mandy find a list of management platforms that support the IBB. They select the platform being used for their building project. In this example, they choose . Next, they login into the portal. The IBB is now installed and configured to the appropriate management platform. Acme X Cloud Acme X Cloud Acme X Cloud Now, let’s continue the configuration, considering Jake’s workflow. App Installation Once the configuration is complete, Jake can install and manage applications. He begins by choosing the “Install IBB App” option in the management platform (i.e., ). Next, he selects the app he wants to install. In this case, he wants to install a Haystack IDL (Independent Data Layer). Jake configures the app as necessary. The IDL app is installed, and Jake is presented with its UI. Acme X App Integration Next, Jake wants to install a dashboard required for the IDL. He uses the same IBB management system to install and configure the dashboard. The dashboard is then automatically connected to the IDL and runs the way Jake configured it. That is, the dashboard is running in the IBB, and it’s also connected to the IDL because they have compatible capabilities. Both Jake and Mandy can work efficiently and productively using their own skills and knowledge. Jake knows the apps he installed are compatible and already comply with IT policies. Mandy knows that the IBB is either a well-managed physical device or a virtual device she herself can oversee. More importantly, both engineers work within the purview of their own skill set. That is, they need not know anything about what the other does. In this way, the IBB helps ameliorate the industry’s skills gap. Instead of retooling our entire workforce, we can retool the way we interface with building systems. Vendors and End Users As was stated earlier, the idea of cloud-native architecture and containerization isn’t new; it’s only newly applied to the building automation industry. For years, app developers and the IT industry have built massive ecosystems that support and expand these technologies. Every time you use the Internet or your smartphone, you are using cloud-native. Everyone benefits, and now buildings can reap these benefits with the IBB. For example, mobile app developers follow common standards and protocols within both the iOS and Android platforms. The standards give developers dependable and consistent guidelines that make app deployment easy. Moreover, markets like Apple Store and Google Play ensure these standards are followed. Customers who download these apps can trust they are secure, reliable, and compatible with their devices. There’s no need to call someone to integrate your Instagram app to your iPhone. It just works. Now, contrast the above with today’s automation industry workflows, where thousands of vendors and developers create apps built with a disparate collection of proprietary standards, protocols, and guidelines that run on different platforms. Some are cloud-native, but most aren’t. With the support of vendors and the automation community, we can adopt the IBB and cloud-native architecture to create a collaborative ecosystem that would unleash the functionality and creativity of the entire industry. Conclusion The IBB not only holds the promise of streamlined integration and enhanced efficiency for the smart buildings industry, but it also addresses the very frustrations experienced by stakeholders like Sarah. For her, the dream of plug-and-play apps for her building is in reach. The IBB will result in a disruption to the entire industry by changing the way we develop, deploy, and manage our apps and data. Cloud-native offers the freedom and power our industry needs to leap forward and meet Sarah’s expectations. Moreover, the IBB’s benefits ultimately trickle down to the building’s users, tenants, and occupants. Also published . here

Introductory Guide to the Interoperable Building Box (IBB)

Electric vehicle chargers present a unique risk. With enough knowledge, threat actors could tamper with cars or even turn off sections of the power grid. Addressing these security concerns is crucial since they will only grow as demand increases. cybersecurity Why Are EV Chargers a Cybersecurity Risk? chargers are a cybersecurity risk because most are unsecured and highly interconnected. Often, the units receive few updates and little oversight, so the issue only grows as their number increases. EV As the attack surface expands, it becomes easier for hackers to find new vulnerabilities. In 2021, the United States announced to the existing 100,000 with a $15 billion investment. After a fivefold increase like this, the country’s cybersecurity risk will grow significantly. its goal to add 500,000 stations Who Is at Risk of a Cybersecurity Incident? Every person using EV chargers or operating on a connected network is prone to a cybersecurity incident. Arguably, everyone is at risk, considering hackers could affect the power grid if they wanted. Drivers using slow chargers may be more at risk because they spend more time connected to a potentially infected unit. Since , most choose to take their time to save money. Doing so may make them more prone to a cybersecurity incident. quick charging is more expensive How Are Charging Stations Vulnerable? Charging stations have a variety of vulnerabilities because of their weak security measures or external connections. For instance, manufacturers and installers often integrate stations into building automation or management systems to monitor and control charging. The attack surface broadens because of this, increasing the risk of a cybersecurity incident. These are some of the known vulnerabilities affecting EV chargers: Anyone can collect network keys and inject malicious data into network sessions. Malicious data injection: Hackers can use malware to falsify a display’s battery charge level. Faulty display: : Using software-defined radio of power, hackers can wirelessly abort a charging session from nearly 155 feet away. Charging session disruption running on less than 1 watt With home charging stations, attackers can leverage unsecured networks to exploit many of the same system vulnerabilities. WiFi tampering: The demand for EVs , meaning there are likely many more vulnerabilities the general public isn’t aware of. is incredibly high and only growing What Cybersecurity Risks Do EV Chargers Pose? Spoofing, data theft, session disruption, and system tampering are some of the main cybersecurity risks of EV chargers. Each vulnerability leads to significant adverse outcomes. These are some of the most potentially severe cybersecurity risks: Individuals can steal personally identifiable information — like credit card numbers — after exploiting the EV-to-charger connection. The absence of transport layer security on public stations makes them incredibly susceptible to side-channel attacks. Information theft: If a hacker systematically hijacks chargers with a DDoS attack, they could bring down the power grid. In 2019, researchers at New York University Tandon found they only needed to simultaneously to blackout entire sections of a city. Distributed denial-of-service attack: exploit 1,000 EV-to-charger connections With malicious data injection, a hacker could steal credentials to spoof an EV. They could hijack charging sessions or launch a masquerade attack with this method. Credential theft: Hackers can spoof the connection between the charger and the vehicle. At best, this could result in power theft. At worst, it involves falsifying malfunction errors to prevent the EV from charging or operating effectively. Man-in-the-middle attack: It’s possible to extract a vehicle’s GPS data to manipulate how the station views its location, disrupting the charging process with similar effects to a DDoS attack. Charging session disruption: With enough knowledge, someone could bring entire sections of the power grid down using only a few charging EVs. They could also engage in a mass identity theft campaign or disable cars from operating. Who Is to Blame for the Charger Vulnerabilities? If anyone is to blame for charger vulnerabilities, it’s the federal government and suppliers like Tesla and Electrify America. They’re among the biggest providers of public charging stations, meaning cybersecurity is primarily their responsibility. In January 2023, of an Electrify America public charging station using only his phone. The vulnerability was evident because the unit’s screen displayed what looked like the back end. He accessed its internal computer after only a few seconds. an individual took complete control He only tampered with it to show his followers the vulnerability, admitting someone with more knowledge could skim personally identifiable information. While Electrify America made a statement admonishing his actions — stating unauthorized access is potentially a serious crime — it didn’t immediately take action beyond making a vague statement about investigating. Is Anyone Addressing the Cybersecurity Concerns? While some governments and companies have taken steps to address the cybersecurity concerns of EV charging, there are no widespread requirements as of 2023. Since there is no standardized protocol to follow, it effectively weakens the integrity of all systems. Industry experts project EVs will make up by 2035, making nearly 50% of all passenger vehicles electric. Government incentives may increase this figure even further. Since more will soon be on the road, who will monitor them and ensure they’re secure? 45% of new automotive sales The United Kingdom is among the few countries that have taken steps to increase charging station cybersecurity. It , data encryption, and information deletion options. Service providers must also provide regular updates to minimize the chances of vulnerability exploitation. requires they have credential authentication As of 2023, the United States Federal Highway Administration and Department of Transportation have for projects the government funds. While the requirements are a step in the right direction, their applications are incredibly narrow. only established minimum cybersecurity standards To address the cybersecurity concerns of EV charging, the government must step in to mandate minimum security measures and consumer safety requirements. This approach is especially critical, given how many of these vehicles will be on the road by 2030. The Future of EV Charger Cybersecurity Most charging stations aren’t secure because companies, installers or the buildings they connect to are lenient with cybersecurity. If EVs are to be the future of consumer transportation, they must address concerns swiftly.

Do EV Chargers Present a Cybersecurity Risk?

Going by the number of countries that Tesla has got its footprints, it's beyond doubt that the electrification of vehicles is on a tremendous rise. Passenger EV sales have seen a staggering five-fold increase in the last five years and we're witnessing a movement that is growing slowly but steadily. As Li-ion battery pack prices dropped by in the past decade and policymakers are making the move for building better charging infrastructure, the EV share of total vehicle sales is projected to hit by 2040. 87% 58% Agreed that the future looks green and promising with reduced CO2 emissions and lower running costs of EVs prompting more people to consider owning EVs. But the sparse charging infrastructure and comparatively limited range of economical pure electric vehicles instill the gnawing sense of range anxiety ( ) in potential buyers. Yes, it's an actual thing! Until the number of charging stations catch up with those of fuel pumps, relying on optimal charging through EV routing schemes brings down anxiety levels. Apple an EV routing feature to eliminate range anxiety and is working with the likes of BMW to ease routing in its range of electric vehicles. launched Warning! Strange EV terms ahead Before we dive in and talk more about EV routing and how inbuilt GPS in EVs would put drivers' fears at bay, let’s take a quick look at a few EV - specific terms we’ll be using in this article. - The EV equivalent to the mileage of a petrol or diesel-powered vehicle; the range is the maximum distance traveled by an EV on a full charge. Range - Claimed to be the reason behind the birth of Tesla, it’s the fear of an EV driver that the vehicle would run out of charge before completing a trip. Over time, as one starts using an EV on a regular basis, the anxiety wanes but it’s seen as one of the biggest barriers to purchase an EV. Range anxiety (ICEV) - Vehicles, like your normal car or bike, are powered by the internal combustion of fuel like petrol or diesel. Internal Combustion Engine Vehicle (SoC) - The level of energy present in a battery relative to its full capacity. The available drive range is derived from the current SoC in an EV. State of Charge Now that we’ve got the terms covered, let’s dig into the specifics of EV routing. But first, how is EV routing any different from a usual vehicle routing problem? Isn't routing a common challenge for all automobiles? You still peep into GMaps to know the fastest route to reach your office. So how is it any different for an electric vehicle? Well, when an ICE vehicle is used to reach a certain destination, the driver would pick a route that saves time rather than a path that would cut back fuel consumption. Switch gears to the mind of an EV driver. Here are some questions that would pop up instantly - Will the charge stay till I get to the destination? How much energy will be consumed in this route? Are there charging stations en route? How much time would I lose if I’ve got to charge? Energy efficiency precedes the time factor for EV owners who are more concerned about the limited range of the vehicle and the lifespan of the battery. Studies that EV drivers would opt for a route that minimizes energy consumption and save the worry and time taken to charge, though it would take a tad longer to reach their destination. reveal EV routing algorithms to the rescue While normal vehicle routing algorithms decode the shortest path for ICE vehicles with time as the primary constraint, EV-specific routing algorithms need to weigh in a lot of additional constraints to arrive at an energy-efficient route. Cracking the optimal route, EV routing algorithms have to consider the following factors - - The range you can cover relies on the battery’s current state of charge (SOC) and the number of charging stops is forecasted based on SoC. Battery degradation or health also determines how effectively it can hold a charge. Battery characteristics - Pumping on those brakes and accelerators hard or hitting a new high by touching those speed limits? Fun fact: Even for ICEs fuel consumption can be cut down with a decent driving style. No doubt, when energy consumption is our main criteria, the way you zip and zap through the lanes has a big impact on routing. Driving style - Dodging those bumps on suburban roads or cruising through highways, real-time road topography and traffic affect energy drain. Traffic and Terrain - Till we have Superchargers around, a pit stop for EVs would be close to an hour with DC fast charging at a public charge point. So the waiting time and the detour (if needed) play a vital part while routing EVs, unlike ICEs that can be topped up anywhere on the go. Recharging time and schedule Attempts to address the electric vehicle routing problem (EVRP) began in 2010 when EV-specific constraints were observed, and modified algorithms were proposed. The contribution of every factor to the overall route scheme is still being studied extensively and workarounds are done by tweaking these algorithms. Integrated GPS the way forward for energy optimal routing Now that you clearly see why GMaps wouldn’t be enough to give an EV-specific energy optimal route, let’s turn to the other options in hand. Mobile apps for EV route planning are available in the market but have their own limitations of accuracy and usability. Critical data from the vehicle including current SoC, driving patterns, and vehicle load that immensely influence the route prediction can’t be sourced by the apps and have to be manually entered every time you plan a trip. These details also have to be updated every time you stop for a battery recharge. Independent routing apps also rely solely on your phone’s GPS which is prone to signal interruptions and could steer you in the wrong way. Ouch! Missed that turn did you? for electric vehicles comes along with the challenge of finding charging stations in the vicinity to bate charging worries of the driver. An inaccurate GPS could easily throw an EV driver off balance when charging points are unavailable in alternative routes suggested after a missed turn. Turn-by-turn navigation So how exactly does an integrated GPS help in smart EV routing? When a GPS sits ingrained in an electric vehicle, details such as battery SoC along with real-time and historical driving patterns are easily sensed and interleaved with traffic information to map out reliable routes. The high precision of built-in GPS comes from its ability to detect vehicle position, speed, direction, and altitude even when GPS signals are weak. This accurate positioning is achieved through techniques like that take the vehicle’s last known position that’s merged with your vehicle’s wheel tick, gyroscope, and accelerometer data to pinpoint the exact vehicle location thus compensating the loss in GPS signals. Interpreting signals from multiple satellite systems instead of relying on just one further improves the availability and accuracy of the positioning system. dead reckoning Since an integrated GPS holds data on the EV’s internals, driver stats like braking and accelerating patterns, and understands the lay of the land, it can put together an ideal driver profile to guide the driver. So the next time you go hard on the accelerator while running low charge, your navigator buddy would pop an alert reminding you to go easy on the pedal and save charge. EV drivers will have the option to choose between an energy-optimal route or a time-saving route and also alternate between the two during the journey. Given the accuracy of the vehicle integrated GPS, estimated arrival times will be on the dot and routes can be updated quickly along with the charging stops to reduce charging worries. Charging stations would also be listed with wait times based on the EV’s supported connector type and battery technology. Data sources for smart EV routing Final thoughts Innovative ideas are being implemented to break the barrier of range anxiety that prevents a vast majority of people from considering an EV. Take for example the on-route battery warm-up feature introduced by Tesla, where the EV inbuilt sat nav would sense that the vehicle is nearing a charge station and beginning heating up the battery so that the charge time is reduced. Pretty cool (or warm!), right? EVs sounded alien a decade back, just like Fords did when horses prevailed. But you know how history played out. Technology is growing leaps and bound with connected cars becoming mainstream and eco-friendly vehicles being adopted better as people embrace sustainability.

How Integrated GPS Works With Smart EV Routing

DePIN Tackles the World’s Most Entrenched Industries

DePIN বিশ্বের সবচেয়ে প্রবেশ করা শিল্পকে মোকাবেলা করে

DePIN nimmt sich der am stärksten verankerten Branchen der Welt an

DePIN aborda las industrias más arraigadas del mundo

DePIN s’attaque aux industries les plus implantées au monde

DePIN दुनिया के सबसे अधिक स्थापित उद्योगों से निपटता है

DePINは世界で最も定着している産業に取り組む

DePIN은 세계에서 가장 확고한 산업을 다루고 있습니다

DePIN aborda as indústrias mais arraigadas do mundo

DePIN решает проблемы самых укоренившихся в мире отраслей

DePIN Dünyanın En Köklü Endüstrileriyle Mücadele Ediyor

DePIN giải quyết các ngành công nghiệp cố thủ nhất thế giới

DePIN 应对全球最根深蒂固的行业

Hi There! So, I believe each of us has encountered a situation when, after modifying an entity in the database, it's necessary to notify other systems about this change. For example, upon accepting an order, we need to inform all related services and teams about the arrival of a new order. The first solution that comes to mind is straightforward: have each service or database polled at regular intervals to check for new orders or status updates. But what if the logic becomes too complex and needs to be segmented? This is where we turn to the event-driven approach, where we broadcast what happened with our objects. is an architectural pattern that allows systems to asynchronously exchange messages or events. The main advantage of EDA is its ability to increase system scalability and flexibility by minimizing direct dependencies between its components. Event-driven architecture (EDA) This facilitates easier adaptation to changes and growth, ensures higher resilience, and simplifies the integration of diverse services. However, a challenge arises in synchronizing data between the database and the messaging system. If we first record data about a new order in the database and then attempt to send a message to Kafka, we cannot guarantee that the message will be sent. A potential producer error could lead to the loss of critical notifications. actually Attempting to wrap these operations in a single transaction (writing to the database and sending to Kafka, followed by a transaction commit) faces fundamental difficulties, as Kafka operates outside the transaction context of databases. This necessitates an alternative solution that ensures atomicity and delivery guarantees for messages without compromising the system's performance and reliability. Here is where the comes to the rescue. Outbox pattern https://microservices.io/patterns/data/transactional-outbox.html?embedable=true The Outbox pattern involves creating a special table (outbox) in the database, where an event intended for the messaging system is recorded within the same transaction as the main data changes. Thus, both operations - changing the state in the main table and creating an event in the outbox table - are guaranteed to be executed together. Subsequently, a dedicated connector (e.g., Kafka Connect) asynchronously reads data from the outbox table and sends it to Kafka, thereby ensuring the delivery of events to the end recipients. This approach achieves high reliability and data consistency without adding undue complexity to the system's architecture or compromising its performance. Let’s review it. The Problem ACID is an acronym describing key transaction properties in databases: A transaction is either executed in full or not executed at all. Atomicity: A transaction transitions the database from one consistent state to another. Consistency: The execution of one transaction doesn't impact the execution of others. Isolation: Completed transactions persist in the database, even in case of system failures. Durability: In distributed systems, the requirement to synchronize data across multiple services is a common challenge. The conventional Two-Phase Commit (2PC) approach is often deemed suboptimal due to its sluggish and blocking nature. Moreover, dealing with data integrity recovery in the event of a system failure poses significant difficulties. The Outbox Pattern emerges as a remedy to address the need for atomicity in writing operations to the database and dispatching messages to a message queue. The core of this solution involves incorporating an additional table within the service's database, referred to as the "Outbox." This table acts as a buffer, storing messages destined for dispatch to a message queue. How the Outbox Pattern Works: Local Transaction: When performing a business operation, data changes are written to the respective database tables. A message intended for other services is placed in the Outbox table within the same transaction. Message Publication: Pollers periodically scan the Outbox table for new messages. Each message from the Outbox table is published to the corresponding message queue. After successful publication, the message is either deleted from the Outbox table or marked as sent. Let’s Code Let's break down this process step by step with a simple example, utilizing Go. You can find the source code and additional materials at the following . link Step 1: Setting Up the Order Service We'll start by creating a service for handling orders. This service will be responsible for receiving orders and recording them in the database. A key component will be implementing the "Outbox" pattern to ensure that every change in order status is reliably transmitted to Kafka. For our case, we need to create only one method: curl -X POST
  http://localhost:8080/api/v1/create-order
  -H 'Content-Type: application/json'
  -d '{
    "name": "John",
    "surname": "Doe",
    "details": {
      "code": 123,
      "operation_code": 456,
      "transaction_code": "sdfsdfsdfs"
    }
  }' The core concept of this service involves writing to both the orders table and the outbox table within a single transaction. For instance, in Go, this would be implemented as follows: func (r *OrderRepository) CreateOrder(userUUID string, order domain.Order) (*int32, error) {
	det := order.Details
	var id int32

	tx, err := r.db.Begin()
	if err != nil {
		return nil, err
	}

	err = tx.QueryRow(
		query,
		order.Name, order.Surname, det.Code, det.OperationCode, det.TransactionCode, StatusCreated).Scan(&id)

	if err != nil {
		tx.Rollback()
		return nil, err
	}

	// Save to outbox
	err = r.createOutbox(userUUID, order)
	if err != nil {
		tx.Rollback()
		return nil, err
	}

	return &id, tx.Commit()
} As a result, we’ll expect messages like this: Step 2: Configuring Kafka JDBC Connector Next, we'll set up the Kafka JDBC Connector to automatically transfer messages from the outbox table to Kafka. This allows other services to subscribe to these events and react to changes in order statuses in real-time. For the Kafka connector, I'll be using the JDBC connector. Find a good way for you to install it: https://docs.confluent.io/kafka-connectors/jdbc/current/source-connector/overview.html?embedable=true#install-the-jdbc-sink-connector After installation, just call connector API: curl http://localhost:8083/connector-plugins We’ll expect to see: [{"class":"io.confluent.connect.jdbc.JdbcSinkConnector","type":"sink","version":"10.7.5"},
{"class":"io.confluent.connect.jdbc.JdbcSourceConnector","type":"source","version":"10.7.5"},
{"class":"org.apache.kafka.connect.mirror.MirrorCheckpointConnector","type":"source","version":"7.6.0-ccs"},
{"class":"org.apache.kafka.connect.mirror.MirrorHeartbeatConnector","type":"source","version":"7.6.0-ccs"},
{"class":"org.apache.kafka.connect.mirror.MirrorSourceConnector","type":"source","version":"7.6.0-ccs"}] Next, we need to create settings for the source. Be careful at this stage, as we are providing credentials for our connector. I recommend creating separate credentials with read-only permissions for the outbox table so that this service can only observe changes. Overall, there are plenty of best practices in this regard, but we won't delve into them here. {
  "name": "jdbc-source-connector",
  "config": {
    "connector.class": "io.confluent.connect.jdbc.JdbcSourceConnector",
    "connection.url": "jdbc:postgresql://postgres:5432/postgres",
    "connection.user": "postgres",
    "connection.password": "postgres",
    "topic.prefix": "microshop.order-",
    "mode": "incrementing",
    "incrementing.column.name": "id",
    "table.whitelist": "outbox",
    "poll.interval.ms": "5000",
    "value.converter": "org.apache.kafka.connect.json.JsonConverter",
    "key.converter": "org.apache.kafka.connect.storage.StringConverter",
    "key.converter.schemas.enable": "false",
    "transforms": "createKey",
    "transforms.createKey.type": "org.apache.kafka.connect.transforms.ValueToKey",
    "transforms.createKey.fields": "user_id"
  }
} Set - our table. "table.whitelist": "outbox" Set - our topic. "topic.prefix": "microshop.order-" Set - our message key. "transforms.createKey.fields": "user_id" More about settings and fields: … here And send it. curl -X POST -H "Content-Type: application/json" --data @jdbc-source-config.json http://localhost:8083/connectors And that's it! Now, you just need to create an order, and check if everything is working and if messages are being recorded in the tables. To view what we have in Kafka, I use Kafka UI for such tasks, which allows us to quickly see what we wrote there and if it's working. Step 3: Creating the Background Processing Service We'll create a background service that listens for messages from Kafka and executes the appropriate processing logic. For instance, this service might be responsible for updating order statuses or initiating delivery processes. Full schema: The last service is a background (order-background-service). In our case, it’s just a simple service that can consume messages from Kafka. ...
	err = c.SubscribeTopics([]string{"microshop.order-outbox"}, nil)
	if err != nil {
		fmt.Fprintf(os.Stderr, "Failed to subscribe to topics: %s\n", err)
		os.Exit(1)
	}

...

	ev := c.Poll(cfg.Poll)
	if ev == nil {
	  continue
	}

	switch e := ev.(type) {
		case *kafka.Message:

		// Create an instance of Outbox to store the unmarshaled data
		var outbox domain.Outbox

		// Unmarshal the JSON message into the Outbox struct
		err := json.Unmarshal(e.Value, &outbox)
		if err != nil {
			fmt.Println("Error decoding message:", err)
			return
		}
		fmt.Println("Payload:", outbox.Payload)

		_, err = c.CommitMessage(e)
		if err != nil {	
			fmt.Printf("Failed to commit message: %v\n", err)
		} Be Careful! It is essential to pause here and reflect on the following: as we can observe, entries are now being recorded in tables atomically, ensuring ACID compliance. However, our pipeline has been expanded to include both a Kafka connector and Kafka itself. It is crucial to remember the delivery guarantees that Kafka promises. Apache Kafka offers developers various levels of message delivery guarantees, enabling a balance between performance and reliability according to application requirements. These guarantees are based on the concepts of atomicity, durability, and isolation. Here are the primary delivery guarantees provided by Kafka: : This foundational guarantee ensures a message is delivered at least once. It implies that, in the event of failures or retries, a message may be delivered or processed more than once. This guarantee is facilitated by retry mechanisms in case of errors and acknowledgments from consumers. At Least Once : In this mode, messages can be lost but will not be delivered more than once. This is the fastest and least reliable mode, as it does not account for retries in case of errors. This approach may be acceptable for scenarios where the loss of some messages is not critical. At Most Once : This is the most complex and desirable guarantee, ensuring that each message is delivered and processed “exactly once”, eliminating duplication or loss. Kafka has supported "exactly once" delivery since version 0.11, using a combination of techniques such as idempotent producers and transactions to ensure atomicity across various topics and consumers. Exactly Once The choice among these guarantees depends on your application's requirements for reliability and performance. If you need more information about it just let me know. In conclusion, implementing an Outbox pattern alongside a reliable Kafka connector like the JDBC connector offers a robust solution for orchestrating data changes across microservices. This approach ensures atomicity and consistency when updating multiple systems, significantly reducing the chances of data inconsistencies. This method serves as a crucial first step toward an Event-Driven Architecture (EDA). By introducing a reliable messaging system, like Kafka, and seamlessly integrating it with a transactional database, we establish a foundation for distributing events across the microservices landscape. This approach becomes particularly valuable when considering the need for analytics, as all relevant events are readily available for consumption. Analytics teams can effortlessly retrieve and process these events, contributing to the generation of valuable insights and reports. In essence, the Outbox pattern, coupled with Kafka integration, not only addresses immediate concerns of data consistency but also lays the groundwork for a scalable, event-driven ecosystem that is essential for modern microservices architectures. This facilitates the seamless flow of information between services, unlocking the potential for enhanced analytics and real-time decision-making. If you're interested in learning more about advanced topics such as managing deletions from the Outbox table and further insights into working with this setup, consider subscribing for future updates. Your subscription will help gauge the interest in this topic and guide the direction of upcoming articles. Stay tuned for more in-depth explorations into the intricacies of microservices architectures and event-driven systems! Useful Links Kafka UI: click here Kafka JDBC connector: click here Outbox pattern: click here

Unlocking Microservices Reliability With ACID and the Outbox Pattern

At the International Builders Show 2024 in Las Vegas, it's evident that the future of homebuilding is here, and it's smarter than ever. Amidst the innovative showcases and tech-forward exhibits, one name stands out: , a division of , which is setting new standards for smart home integration and consumer satisfaction in the housing industry. Cox Communities Cox Communications Smart Homes for Everyone The concept of smart homes has transcended the realm of luxury and become a staple in the modern housing market. With an estimated 75.4 billion gadgets expected to connect to the internet by 2025, the demand for homes that are not only built with but also built for technology is skyrocketing. Cox Communities is at the forefront of this evolving digital reality, delivering pre-enabled fiber-powered broadband that’s fast, reliable and able to support their increasingly connected lives. "At Cox Communities, we envision a future where every home is built with connectivity at its core," says Guillermo Rivas, a spokesperson for Cox Communications. "This isn't just about access to the internet. It's about crafting homes that anticipate and fulfill the digital and lifestyle needs of tomorrow's homeowners, making smart living accessible to all." Christopher Phelan from echoes this sentiment, highlighting the industry's move towards integrated smart technologies in multifamily and senior living spaces. CSI Construction "The ability for a community to manage properties efficiently while offering residents advanced control and security over their living spaces is the next frontier in residential construction," Phelan notes. Stress-Free Moves with Pre-Enabled Homes Imagine moving into a new home and, with the flip of a switch, having all your connected technology work seamlessly from day one without needing to make countless phone calls to order equipment and schedule installation. Cox Communities makes this a reality by integrating Cox’s fiber-powered network into homes from the get-go. This approach not only caters to the 70% of home buyers looking for a turnkey move-in experience but also addresses the growing preference among Gen Z buyers for newly constructed homes equipped with smart features. The Rise of Build-to-Rent Homes The housing market is witnessing a significant shift towards build-to-rent (BTR) single-family homes. This trend caters to those hesitant to buy or looking for an upgrade from apartment living. Cox Communities recognizes the importance of technology in making these properties attractive to renters, ensuring that each home is enabled with the connectivity and smart tech tools necessary for a modern lifestyle. The Importance of a Trusted Internet Provider Having a reliable and fast internet provider is crucial. Cox Communities not only promises speed and reliability, backed by the Cox network, but also a commitment to growth and agility, ensuring that their network can support the ever-increasing number of connected devices in our homes. Pioneering Electrification in Smart Homes The future is not just about connectivity but also about sustainability and efficiency. An exemplary showcase of this forward-thinking approach comes from Siemens, a global brand of electrical engineering and smart home technology. Tim Curtis from Siemens shared insights into how their innovations are setting the stage for a more electrified and efficient future. “We displayed Inhab, as the market is looking to electrify and do more with less we are helping to enable that for customers. It starts with knowing your power,” Curtis stated. This perspective underscores a critical shift towards energy awareness and efficiency in the smart home sector, aligning perfectly with Cox Communities' vision of homes that are not only connected but also intelligently powered. Siemens is addressing a common hurdle for many homeowners looking to adopt electric vehicles (EVs) with a groundbreaking solution. “For people looking to buy EV chargers that don’t have space in their panel, we have a new product coming out this year that allows you to avoid panel upgrades so you can continue to use your existing panels and avoid $5,000 to $20,000 of unnecessary material and labor charges,” Curtis revealed. This innovation exemplifies the kind of smart solutions that are making sustainable living more accessible to the average homeowner. Additionally, Siemens is gearing up to introduce a Smart Breaker, compatible with existing Siemens equipment. This product promises to be a game-changer in home energy management, offering homeowners unprecedented control over their power consumption. “We also have a Smart Breaker coming out, it’s something we are excited to showcase,” Curtis added. This aligns with the broader industry movement towards homes that not only connect to the internet but also intelligently manage their energy use, reflecting Cox Communities' commitment to supporting homes that are prepared for the future. Cox Communities is a leading resource for builders and developers, guiding them through the complexities of modern home construction. By pre-enabling homes with Cox Fiber, they remove one of the major stress points of moving, significantly improving customer satisfaction. Their consultation services help builders attract buyers more efficiently, with homes pre-equipped with smart technology selling at a higher price. The Future Is Connected The future of housing lies in smart, connected homes. Cox Communities is leading the charge, transforming the way we think about living spaces and setting new benchmarks for the industry. With their expertise and innovative solutions, they are doing more than just bringing powerful broadband to new homes; they are creating the foundations for a more connected and convenient future.

EV CONNECT

evconnect.com

-- employees

Since n.d.

COMPANY RANKING

EV CONNECT

EVERGREEN INDEX #191

Representing this company? Click here to claim and customize this page!

EV Connect WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

EV CONNECT

evconnect.com

-- employees

Since n.d.

COMPANY RANKING

EV CONNECT

EVERGREEN INDEX #191

RELATED COMPANIESRANK

STORIES ABOUT EV CONNECT

Representing this company? Click here to claim and customize this page!

EV Connect WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!